This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] PR ld/19572: -Ttext-segment accepts out of range value
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Alan Modra <amodra at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Sat, 6 Feb 2016 08:48:32 -0800
- Subject: Re: [PATCH] PR ld/19572: -Ttext-segment accepts out of range value
- Authentication-results: sourceware.org; auth=none
- References: <20160205211658 dot GA30879 at intel dot com> <20160206135936 dot GH22967 at bubble dot grove dot modra dot org> <CAJimCsGRkaHZ159NmUdDOddm_X0YoYRwB9bNmDw1CpcAw6HRJg at mail dot gmail dot com>
On Sat, Feb 6, 2016 at 8:19 AM, Cary Coutant <email@example.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:
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