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

[H.J. Lu]

On Sat, Feb 6, 2016 at 8:19 AM, Cary Coutant <ccoutant@gmail.com> wrote:
>>> 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

Small model is for normal programs in user space.

> 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.

Please see how x32 to use full 4GB address space:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352

The normal program is still limited to 2GB symbol range unless you
use the trick above.

> 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.



-- 
H.J.