This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: hjl dot tools at gmail dot com
- Cc: binutils at sourceware dot org
- Date: Sun, 22 Oct 2017 01:37:41 +0200
- Subject: Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry
- Authentication-results: sourceware.org; auth=none
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Sat, 21 Oct 2017 15:31:58 -0700
> On Sat, Oct 21, 2017 at 1:47 PM, Hans-Peter Nilsson
> <hans-peter.nilsson@axis.com> wrote:
> >> From: "H.J. Lu" <hjl.tools@gmail.com>
> >> Date: Sat, 21 Oct 2017 12:17:23 -0700
> >
> >> On Sat, Oct 21, 2017 at 11:34 AM, Hans-Peter Nilsson
> >> <hans-peter.nilsson@axis.com> wrote:
> >> >> From: "H.J. Lu" <hjl.tools@gmail.com>
> >> >> Date: Wed, 9 Aug 2017 15:08:54 -0700
> >> >> +# Set LD_CLASS to "64bit" for 64-bit LD.
> >> >> +if { ![info exists LD_CLASS] } then {
> >> >> + set readelf_output [run_host_cmd "$READELF" "-h $LD"]
> >
> > (s/LD/REAL_LD/)
> >
> >> It checks if linker can support 64-bit address space,
> >
> > No, as it stands it tests that the linker *is of* 64-bit
> > address-space, not that it *generates* 64-bit address-space, for
>
> That is exactly what it is testing.
There's a little bit too much ambiguity here. I wish you'd help
remove that ambiguity. For example your "that" doesn't tell me
whether you agree or disagree. :) Also "for 64-bit ld" and "can
support 64-bit" above may refer to either the format written by
the just-built linker and it may refer to the format of the
linker binary, which may be different, and while the former is
the most obvious meaning, what it does is actually the latter.
For what appears to be your purposes (detecting overflow in the
target address space, IIUC), you should check the address-space
of a linked target object, not the tools; not whatever format
the host uses for the just-build linker. While I can agree that
it's less likely that you can build a 64-bit-capable target
linker that can link a >32-bit binary (i.e. actually that large
objects) on a 32-bit host, you're still testing the wrong thing
here, IMO.
To wit, you can't imply a 64-bit target address by observing
that the just-built linker executable is ELF64, except on native
builds.
But, I'm starting to repeat myself. I'll just add that
$LD_CLASS would be more useful if it reflected the target
address-space, not the build machine.
brgds, H-P