-
Notifications
You must be signed in to change notification settings - Fork 26
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
Preemptable linkage #80
Comments
I don't follow the C code example. Is faerie not capable of emitting those relocations? How is the difference related to the symbol table? I don't think I understand the distinction between preemptable and weak. My understanding was that @sunfishcode selected those variants because the two were synonyms. |
For the C code example, note that the global and weak relocations reference the symbol, not the section (e.g. For preemptable vs weak, maybe I am reading too much into the name. Have a look at https://llvm.org/docs/LangRef.html#runtime-preemption-specifiers. It would be good if @sunfishcode could clarify the intent here. |
Thanks, I missed the distinction between referencing a symbol and a section. I agree that this is something we should correct. |
@philipc I believe you are correct, and we should fix this. |
@sunfishcode Is cranelift's |
For defined symbols, faerie always references the section symbol in ELF relocations:
faerie/src/elf.rs
Line 676 in dcb671a
I think this means that these relocations can never be preempted. However, my understanding is that normally all global symbols are preemptable, regardless of whether they are weak.
e.g. for the following C code:
I get these relocations (compiled with
gcc -fPIC -ffunction-sections
):To complicate this, cranelift has
Linkage::Preemptible
, but this is translated toweak
for the faerie backend, which seems to be conflating weak and preemptable.Is my understanding of all this correct?
cc @pchickey since I think you did the weak support?
The text was updated successfully, but these errors were encountered: