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: Cary Coutant <ccoutant at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Sat, 6 Feb 2016 08:19:08 -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>
>> 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
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