Build hexagon-builtins for baremetal

[quic-k]

Adding a function to build hexagon builtins for baremetal target
we might have to decide on a common location for the install path of archive
or we can keep it separate for different target triples

This seems like a common path to install compiler-rt bits : <install_path>/lib/clang/<version>/lib/<target-triple>/

[quic-k]

@quic-akaryaki
@androm3da

[androm3da]

If the builtins library we're building is the same one that we've already built for linux, we can just add a symlink instead of building it again. We can add a symlink to this library for each hexagon triple we want to support.

[androm3da]

If the builtins library we're building is the same one that we've already built for linux, we can just add a symlink instead of building it again. We can add a symlink to this library for each hexagon triple we want to support.

While we're doing this change -- why not build the picolibc fork too? That way we can have a release that works for experimenting w/picolibc.

[quic-akaryaki]

@androm3da we don't know if the builtins will be always built in the same way for linux and baremetal. For example, baremetal builtins may not need PIC.
I also think that the directory structure can be switched to a be triple-based / multilib style instead of hardcoded "linux" and "baremetal" directories. In that case, linux can be symlinked to hexagon-linux-musl or whatever for backwards compatibility.
I guess this will also involve the clang driver to use new scheme.

[quic-k]

If the builtins library we're building is the same one that we've already built for linux, we can just add a symlink instead of building it again. We can add a symlink to this library for each hexagon triple we want to support.

While we're doing this change -- why not build the picolibc fork too? That way we can have a release that works for experimenting w/picolibc.

that would be nice, but currently the PR to upstream Hexagon patches in Picolibc is open
we will need the toolchain release first to build Picolibc in CI to merge the PR
I am not sure if we should use the fork as its still undergoing changes as requested by upstream

[androm3da]

@androm3da we don't know if the builtins will be always built in the same way for linux and baremetal. For example, baremetal builtins may not need PIC. I also think that the directory structure can be switched to a be triple-based / multilib style instead

It is this way now, so whatever the normalized baremetal triple is, that's the path that we should be installing into.

[androm3da]

If the builtins library we're building is the same one that we've already built for linux, we can just add a symlink instead of building it again. We can add a symlink to this library for each hexagon triple we want to support.

While we're doing this change -- why not build the picolibc fork too? That way we can have a release that works for experimenting w/picolibc.

that would be nice, but currently the PR to upstream Hexagon patches in Picolibc is open we will need the toolchain release first to build Picolibc in CI to merge the PR I am not sure if we should use the fork as its still undergoing changes as requested by upstream

If you think it "works" (for some definition of "works") then IMO it's good to include it. We don't know how long the upstreaming will take and this toolchain repo has routinely used downstream forks while we're working on upstreaming.

I mean, if you can run programs built against your picolibc fork in both hexagon-sim and QEMU, with semihosting, then we should include it here because that's a significant step forward. Whatever changes upstream picolibc demands will only make things better but in the meantime people can experiment with this new functionality.

[androm3da]

Most of these belong in a cmake cache file.

Can you contribute them -- ideally to the llvm-project monorepo? Adding cmake cache files like this is noncontroversial and is just a mechanism to publicize our build configuration for other developers. This makes use cases for LLVM toolchain builds clear to people who want to understand how the toolchain is used -- for example, when making changes to cmake functions/modules.

[androm3da]

Ah - my mistake -- I said elsewhere that the triple is used, but that's not quite right. The C library gets installed to target/${normalized-triple}/ but you're right that the builtins get installed here. Hmm -- will this one conflict with the builtins for linux?

[androm3da]

@quic-k or @quic-akaryaki are you planning to make changes to the compiler driver to support this?

[quic-k]

I mean, if you can run programs built against your picolibc fork in both hexagon-sim and QEMU, with semihosting, then we should include it here because that's a significant step forward. Whatever changes upstream picolibc demands will only make things better but in the meantime people can experiment with this new functionality.

yes, we can run programs built against Picolibc fork with both hexagon-sim and QEMU with semihosting
sounds good