-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emit position dependent code for embedded targets #15174
Conversation
Do you have some references we could look up on this topic? |
Position independent code is code which can be loaded and ran at any address, this is accomplished by making the code and data refer to each other using relative address offsets, instead of absolute addresses. This is used for dynamic libraries, and more recently to allow the dynamic loader (ld.so) to randomize the code location which has security benefits. However, this does introduce additional complexity, as some offset tables that contain locations of code and data have to be loaded and maintained. There's some more info here: https://mcuoneclipse.com/2021/06/05/position-independent-code-with-gcc-for-arm-cortex-m/ I think in the future, PIC should be configurable for crystal, but in any case I believe the default for embedded targets should be non-PIC. I personally couldn't get the linker to emit .plt/.got sections with the funky double-linking elf-patching toolchain rp2040 uses. |
To give some better reasons other than "i couldn't get it to work":
|
I understand and agree for real embedded CPU with limited power/memory, such as the Cortex M series, but the eabi targets in crystal target all of ARM32, which aren't necessarily embedded. For example the debian arm/armhf are arm-linux-gnueabi and arm-linux-gnueabihf 🤷 Or do I read this wrong and you mean to disable PIC by default for the generic arm-unknown-eabi and -eabihf targets (no stdlib)? That would make perfect sense. I'd love a |
Oh dear, I forgot that gnueabi was used on linux. Yes, the intention is to disable this on bare-metal targets like This stackoverflow answer seems to imply that I'm fine to add a |
Possibly to correct an inconvenient default configuration that disables it for a particular target, but you still want PIC... Like when targerting For comparison, |
Oh, you mean use |
The recently added branch protection flags from #15122: https://crystal-lang.org/reference/master/syntax_and_semantics/compile_time_flags.html#codegen-features |
Though I suppose we could talk about using a different method to pass these options to the compiler: They could be ordinary CLI options. Or we could a separate CLI option that works like |
|
I'm not sure if the program actually needs to know these flags. It's not really relevant, is it? |
This is actually the question I meant to ask with "but I'm not sure what it could ever be used for". The only answer I can come up with is if the program calls out to link a C library at runtime it might want to pass -fPIC or not using that flag. |
Let's disable PIC for both targets with exactly Using compile-time flags for setting compiler options is probably a bit clunky. It's dead simple to use, but explicit CLI options are probably more fit, yes. |
b4b1452
to
56de2e0
Compare
This should be the right logic for enabling now. Not sure what to think about how to expose override the default, unless we get consensus quickly I'd rather leave it for a later PR. |
Embedded targets (detected by target triples constaining "eabi") would prefer non-PIC builds, for smaller binary sizes and easier runtime support (avoiding having to handle the GOT).