This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Sat, Feb 6, 2016 at 8:19 AM, Cary Coutant <> 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:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]