[PATCH] PR ld/19572: -Ttext-segment accepts out of range value

Cary Coutant ccoutant@gmail.com
Sat Feb 6 16:19:00 GMT 2016


>> The address for -Tbss, -Tdata, -Ttext, -Ttext-segment, -Trodata-segment
>> and -Tldata-segment shouldn't be bigger than the address space.
>
> Does it really matter if someone specifies an address that wraps?
>
> If it does, then it opens up other questions like:  Is the 32-bit
> address range 0 to 4G-1 or -2G to 2G-1?  We have ELF targets (see
> bed->sign_extend_vma) where the latter might be more natural.

This came up because of a discussion in PR gold/19567, where I pointed
out that setting the text segment to 0x80000000 in ld.bfd produces the
same symbol table and segment headers as when setting it to
0xffffffff80000000, but has a different effect on applying R_X86_64_64
relocations (e.g., to movabs instructions). My claim was that the
psABI defines the address space as signed (-2G to 2G-1), so that the
two starting addresses should both be treated as negative and that
both linkers should sign-extend the 32-bit value when applying the
R_X86_64_64 relocation. HJ disagreed, and decided that the linker
should reject the out-of-range (by his definition) value.

If this patch goes in, how would a developer build an x32 kernel-mode
binary intended for the negative half of the address space? The way ld
would work this way, setting any address in that half of the address
space would be treated as positive for purposes of the R_X86_64_64
relocation, and would produce relocation overflow errors for the
R_X86_64_32S relocation.

On the other hand, suppose a developer wants to build an x32 binary
intended for the upper half of an all-positive address space (which is
what HJ was doing with the test cases he used in the PR). How could
the linker support both models? Right now, ld.bfd does by treating
0x80000000 as positive and 0xffffffff80000000 as negative, except
there's no way to tell the difference once the final binary is
produced.

-cary



More information about the Binutils mailing list