-
Notifications
You must be signed in to change notification settings - Fork 194
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
Undefined weak symbol's address #222
Comments
I think this is a case of when we decide when a relocation type is PC relative. The ADRP is a PC-relative instruction, but as R_AARCH64_ADR_GOT_PAGE calculates the offset to the GOT entry for __gmon_start__ and not __gmon_start__ itself. The test for PC-relative is applied to the dynamic relocation R_AARCH64_GLOB_DAT to __gmon_start__, which will return 0 if __gmon_start__ is an undefined weak. Hope that makes sense. I think it is possible the wording could be tidied up to make it clearer, although I can't immediately think of any right now. |
well a reasonable interpretation of "the relocation type is pc-relative" is that the relocation operation has "P" in it. the operation of R_AARCH64_ADR_GOT_PAGE is "Page(G(GDAT(S+A)))-Page(P)" so it is pc-relative and thus in this expression the symbol value "S" is specified to be S=P for undef weak symbols, which is not what we want. i think this can be resolved by changing the wording of the condition to "has P but does not have G", or by changing GDAT(S+A) to GDAT(sym+A) (i.e. the symbol address S is not evaluated in an expression with GDAT) |
@nsz-arm Thanks, that's exactly why the control reached the
The linker relaxed the GOT-loading |
relaxing adrp+ldr to adrp+add is not valid for undef weak symbols, but i think you could relax to mov+nop (or mov+mov if the registers are different). (btw this is an issue in ld.so and static pie early start code where it is assumed that hidden symbols can be accessed without dynamic relocation, but that's not true for hidden weakref symbols, which is the common case when dealing with linker generated symbols that not all linkers emit.. i wish the spec required adrp to relax to mov x,0 for undef weak instead of doing adrp x,0, then using adrp+add for weakref would be valid) |
Relaxing adrp+ldr to adrp+add is valid for undef weak symbols if we are creating a position-dependent executable, no? The offset from a (non-relocatable) location to address 0 is a link-time constant in that case. |
ah yes, adrp can work in pde (assuming the adrp location is below 4G which is the case usually and in your example) |
Thanks for the suggestion on the changes we could make to the docs. Several areas where we could improve:
|
Regarding the second point, I strongly feel we should update this psABI doc to match the reality instead of the other way around. As far as I know, only Alpha and MIPS psABIs allow addends inside a GOT entry. Alpha is already irrelevant, and MIPS seems to be going the same route. There's no reason to diverge from other psABIs at this point. In addition to that, allowing addends inside GOT would result in a GOT size bloat because we need to create a separate GOT entry for each addend for the same symbol. It is better to just read a symbol value from GOT and add an addend afterward, and that's precisely what the current code does. |
Section 5.6.1 (https://github.com/ARM-software/abi-aa/blob/844a79fd4c77252a11342709e3b27b2c9f590cf1/aaelf64/aaelf64.rst#weak-references) says the following.
It looks like the second bullet point doesn't match the linker's actual behavior. Calling an unresolved weak symbol on AArch64 is expected to be equivalent to nop and just increments the program counter to the next instruction. Here is an excerpt from the real object file as an example.
If
__gmon_start__
is undefined in the above code,b
would fall into an infinite loop instead of behaving as nop if the address of__gmon_start__
is evaluated to the address of the relocated place. It needs to be evaluated to PC+4 instead.It looks like it's a spec bug.
The text was updated successfully, but these errors were encountered: