[PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu
Hi,

I checked in this patch to check PC-relative offset overflow in pushq
instruction in x86-64 PLT entry.


H.J.
--
bfd/

        PR ld/17618
        * elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Check
        PC-relative offset overflow in PLT entry.

ld/testsuite/

        PR ld/17618
        * ld-x86-64/x86-64.exp: Run pr17618 for Linux target.

        * ld-x86-64/pr17618.d: New file.
        * ld-x86-64/pr17618.s: Likewise.
---
 bfd/ChangeLog                     |  6 ++++++
 bfd/elf64-x86-64.c                | 27 +++++++++++++++++++--------
 ld/testsuite/ChangeLog            |  8 ++++++++
 ld/testsuite/ld-x86-64/pr17618.d  |  4 ++++
 ld/testsuite/ld-x86-64/pr17618.s  | 18 ++++++++++++++++++
 ld/testsuite/ld-x86-64/x86-64.exp |  7 +++++++
 6 files changed, 62 insertions(+), 8 deletions(-)
 create mode 100644 ld/testsuite/ld-x86-64/pr17618.d
 create mode 100644 ld/testsuite/ld-x86-64/pr17618.s

diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index f606e15..579cca2 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,9 @@
+2014-11-18  H.J. Lu  <[hidden email]>
+
+ PR ld/17618
+ * elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Check
+ PC-relative offset overflow in PLT entry.
+
 2014-11-18  Nick Clifton  <[hidden email]>
 
  PR binutils/17512
diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index 20f45a9..432ab58 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -4749,6 +4749,8 @@ elf_x86_64_finish_dynamic_symbol (bfd *output_bfd,
       bfd_byte *loc;
       asection *plt, *gotplt, *relplt, *resolved_plt;
       const struct elf_backend_data *bed;
+      bfd_boolean gotplt_after_plt;
+      int32_t plt_got_pcrel_offset;
 
       /* When building a static executable, use .iplt, .igot.plt and
  .rela.iplt sections for STT_GNU_IFUNC symbols.  */
@@ -4853,14 +4855,23 @@ elf_x86_64_finish_dynamic_symbol (bfd *output_bfd,
 
       /* Put offset the PC-relative instruction referring to the GOT entry,
  subtracting the size of that instruction.  */
-      bfd_put_32 (output_bfd,
-  (gotplt->output_section->vma
-   + gotplt->output_offset
-   + got_offset
-   - resolved_plt->output_section->vma
-   - resolved_plt->output_offset
-   - plt_offset
-   - plt_got_insn_size),
+      plt_got_pcrel_offset = (gotplt->output_section->vma
+      + gotplt->output_offset
+      + got_offset
+      - resolved_plt->output_section->vma
+      - resolved_plt->output_offset
+      - plt_offset
+      - plt_got_insn_size);
+
+      /* Check PC-relative offset overflow in PLT entry.  */
+      gotplt_after_plt = (gotplt->output_section->vma
+  > resolved_plt->output_section->vma);
+      if ((gotplt_after_plt && plt_got_pcrel_offset < 0)
+  || (!gotplt_after_plt && plt_got_pcrel_offset > 0))
+ info->callbacks->einfo (_("%F%B: PC-relative offset overflow in PLT entry for `%s'\n"),
+ output_bfd, h->root.root.string);
+
+      bfd_put_32 (output_bfd, plt_got_pcrel_offset,
   resolved_plt->contents + plt_offset + plt_got_offset);
 
       /* Fill in the entry in the global offset table, initially this
diff --git a/ld/testsuite/ChangeLog b/ld/testsuite/ChangeLog
index a8aa37d..72b4bb9 100644
--- a/ld/testsuite/ChangeLog
+++ b/ld/testsuite/ChangeLog
@@ -1,5 +1,13 @@
 2014-11-18  H.J. Lu  <[hidden email]>
 
+ PR ld/17618
+ * ld-x86-64/x86-64.exp: Run pr17618 for Linux target.
+
+ * ld-x86-64/pr17618.d: New file.
+ * ld-x86-64/pr17618.s: Likewise.
+
+2014-11-18  H.J. Lu  <[hidden email]>
+
  * ld-x86-64/mpx.exp: Always run mpx3 and mpx4 tests in 64-bit.
 
 2014-11-18  Igor Zamyatin  <[hidden email]>
diff --git a/ld/testsuite/ld-x86-64/pr17618.d b/ld/testsuite/ld-x86-64/pr17618.d
new file mode 100644
index 0000000..e640b40
--- /dev/null
+++ b/ld/testsuite/ld-x86-64/pr17618.d
@@ -0,0 +1,4 @@
+#name: PLT PC-relative offset overflow check
+#as: --64
+#ld: -shared -melf_x86_64
+#error: .*PC-relative offset overflow in PLT entry for `bar'
diff --git a/ld/testsuite/ld-x86-64/pr17618.s b/ld/testsuite/ld-x86-64/pr17618.s
new file mode 100644
index 0000000..39102e0
--- /dev/null
+++ b/ld/testsuite/ld-x86-64/pr17618.s
@@ -0,0 +1,18 @@
+ .text
+ .globl foo
+ .type foo, @function
+foo:
+ call bar@PLT
+ .size foo, .-foo
+
+ .globl gap
+ .type gap, @function
+gap:
+ jmp .L0
+ .space 0x40000000, 0x90
+.L0:
+ jmp .L2
+ .space 0x3fdfff14, 0x90
+.L2:
+ .size gap, .-gap
+ .section .note.GNU-stack,"",@progbits
diff --git a/ld/testsuite/ld-x86-64/x86-64.exp b/ld/testsuite/ld-x86-64/x86-64.exp
index a9b68ff..7f09458 100644
--- a/ld/testsuite/ld-x86-64/x86-64.exp
+++ b/ld/testsuite/ld-x86-64/x86-64.exp
@@ -333,3 +333,10 @@ if { [isnative] && [which $CC] != 0 } {
  {dummy.s} {{readelf {-s --wide} x86-64-x32.rd}} "x86-64-x32"}
     }
 }
+
+if { ![istarget "x86_64-*-linux*"]} {
+    return
+}
+
+# Linux only tests
+run_dump_test "pr17618"
--
1.9.3

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu
On Tue, Nov 18, 2014 at 11:11:13AM -0800, H.J. Lu wrote:
> Hi,
>
> I checked in this patch to check PC-relative offset overflow in pushq
> instruction in x86-64 PLT entry.
>
>

I checked in this patch to avoid running pr17618.d test on x32 since
it needs more than 4GB memory.

H.J.
---
diff --git a/ld/testsuite/ChangeLog b/ld/testsuite/ChangeLog
index f959d55..8e69a89 100644
--- a/ld/testsuite/ChangeLog
+++ b/ld/testsuite/ChangeLog
@@ -1,5 +1,9 @@
 2014-11-20  H.J. Lu  <[hidden email]>
 
+ * ld-x86-64/pr17618.d: Don't run on x32.
+
+2014-11-20  H.J. Lu  <[hidden email]>
+
  * ld-x86-64/plt-main1.rd: Updated for x32.
  * ld-x86-64/plt-main2.rd: Likewise.
  * ld-x86-64/plt-main3.rd: Likewise.
diff --git a/ld/testsuite/ld-x86-64/pr17618.d b/ld/testsuite/ld-x86-64/pr17618.d
index e640b40..b090aa0 100644
--- a/ld/testsuite/ld-x86-64/pr17618.d
+++ b/ld/testsuite/ld-x86-64/pr17618.d
@@ -1,4 +1,5 @@
 #name: PLT PC-relative offset overflow check
 #as: --64
 #ld: -shared -melf_x86_64
+#notarget: x86_64-*-linux*-gnux32
 #error: .*PC-relative offset overflow in PLT entry for `bar'
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu
In reply to this post by H.J. Lu
On Tue, Nov 18, 2014 at 11:11:13AM -0800, H.J. Lu wrote:

> Hi,
>
> I checked in this patch to check PC-relative offset overflow in pushq
> instruction in x86-64 PLT entry.
>
>
> H.J.
> --
> bfd/
>
> PR ld/17618
> * elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Check
> PC-relative offset overflow in PLT entry.
>

I checked in this patch to optimize PC-relative offset overflow check.


H.J.
---
diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index a9e6787..1f5ad55 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,8 @@
+2014-11-21  H.J. Lu  <[hidden email]>
+
+ * elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Optimize
+ PC-relative offset overflow check.
+
 2014-11-21  Alexander Cherepanov  <[hidden email]>
 
  PR binutils/17512
diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index 432ab58..c64ff4f 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -4749,8 +4749,7 @@ elf_x86_64_finish_dynamic_symbol (bfd *output_bfd,
       bfd_byte *loc;
       asection *plt, *gotplt, *relplt, *resolved_plt;
       const struct elf_backend_data *bed;
-      bfd_boolean gotplt_after_plt;
-      int32_t plt_got_pcrel_offset;
+      bfd_vma plt_got_pcrel_offset;
 
       /* When building a static executable, use .iplt, .igot.plt and
  .rela.iplt sections for STT_GNU_IFUNC symbols.  */
@@ -4864,10 +4863,7 @@ elf_x86_64_finish_dynamic_symbol (bfd *output_bfd,
       - plt_got_insn_size);
 
       /* Check PC-relative offset overflow in PLT entry.  */
-      gotplt_after_plt = (gotplt->output_section->vma
-  > resolved_plt->output_section->vma);
-      if ((gotplt_after_plt && plt_got_pcrel_offset < 0)
-  || (!gotplt_after_plt && plt_got_pcrel_offset > 0))
+      if ((plt_got_pcrel_offset + 0x80000000) > 0xffffffff)
  info->callbacks->einfo (_("%F%B: PC-relative offset overflow in PLT entry for `%s'\n"),
  output_bfd, h->root.root.string);
 
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu-30
In reply to this post by H.J. Lu
On Thu, Nov 20, 2014 at 1:37 PM, H.J. Lu <[hidden email]> wrote:

> On Tue, Nov 18, 2014 at 11:11:13AM -0800, H.J. Lu wrote:
>> Hi,
>>
>> I checked in this patch to check PC-relative offset overflow in pushq
>> instruction in x86-64 PLT entry.
>>
>>
>
> I checked in this patch to avoid running pr17618.d test on x32 since
> it needs more than 4GB memory.
>
> H.J.
> ---
> diff --git a/ld/testsuite/ChangeLog b/ld/testsuite/ChangeLog
> index f959d55..8e69a89 100644
> --- a/ld/testsuite/ChangeLog
> +++ b/ld/testsuite/ChangeLog
> @@ -1,5 +1,9 @@
>  2014-11-20  H.J. Lu  <[hidden email]>
>
> +       * ld-x86-64/pr17618.d: Don't run on x32.
> +
> +2014-11-20  H.J. Lu  <[hidden email]>
> +
>         * ld-x86-64/plt-main1.rd: Updated for x32.
>         * ld-x86-64/plt-main2.rd: Likewise.
>         * ld-x86-64/plt-main3.rd: Likewise.
> diff --git a/ld/testsuite/ld-x86-64/pr17618.d b/ld/testsuite/ld-x86-64/pr17618.d
> index e640b40..b090aa0 100644
> --- a/ld/testsuite/ld-x86-64/pr17618.d
> +++ b/ld/testsuite/ld-x86-64/pr17618.d
> @@ -1,4 +1,5 @@
>  #name: PLT PC-relative offset overflow check
>  #as: --64
>  #ld: -shared -melf_x86_64
> +#notarget: x86_64-*-linux*-gnux32
>  #error: .*PC-relative offset overflow in PLT entry for `bar'
I checked in this patch to run PR ld/17618 test only with 64-bit
ELF linker.


--
H.J.

0001-Run-PR-ld-17618-test-only-with-64-bit-ELF-linker.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu-30
On Wed, Aug 9, 2017 at 3:08 PM, H.J. Lu <[hidden email]> wrote:

> On Thu, Nov 20, 2014 at 1:37 PM, H.J. Lu <[hidden email]> wrote:
>> On Tue, Nov 18, 2014 at 11:11:13AM -0800, H.J. Lu wrote:
>>> Hi,
>>>
>>> I checked in this patch to check PC-relative offset overflow in pushq
>>> instruction in x86-64 PLT entry.
>>>
>>>
>>
>> I checked in this patch to avoid running pr17618.d test on x32 since
>> it needs more than 4GB memory.
>>
>> H.J.
>> ---
>> diff --git a/ld/testsuite/ChangeLog b/ld/testsuite/ChangeLog
>> index f959d55..8e69a89 100644
>> --- a/ld/testsuite/ChangeLog
>> +++ b/ld/testsuite/ChangeLog
>> @@ -1,5 +1,9 @@
>>  2014-11-20  H.J. Lu  <[hidden email]>
>>
>> +       * ld-x86-64/pr17618.d: Don't run on x32.
>> +
>> +2014-11-20  H.J. Lu  <[hidden email]>
>> +
>>         * ld-x86-64/plt-main1.rd: Updated for x32.
>>         * ld-x86-64/plt-main2.rd: Likewise.
>>         * ld-x86-64/plt-main3.rd: Likewise.
>> diff --git a/ld/testsuite/ld-x86-64/pr17618.d b/ld/testsuite/ld-x86-64/pr17618.d
>> index e640b40..b090aa0 100644
>> --- a/ld/testsuite/ld-x86-64/pr17618.d
>> +++ b/ld/testsuite/ld-x86-64/pr17618.d
>> @@ -1,4 +1,5 @@
>>  #name: PLT PC-relative offset overflow check
>>  #as: --64
>>  #ld: -shared -melf_x86_64
>> +#notarget: x86_64-*-linux*-gnux32
>>  #error: .*PC-relative offset overflow in PLT entry for `bar'
>
> I checked in this patch to run PR ld/17618 test only with 64-bit
> ELF linker.
>
I checked in this patch to check .libs/ld-new for real linker first.


--
H.J.

0001-LD_CLASS-Check-.libs-ld-new-for-linker-first.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

Hans-Peter Nilsson
In reply to this post by H.J. Lu-30
> From: "H.J. Lu" <[hidden email]>
> Date: Wed, 9 Aug 2017 15:08:54 -0700

> PR ld/17618 test requires 64-bit linker to run.  Set LD_CLASS to "64bit"
> for 64-bit ELF linker and run PR ld/17618 test only if $LD_CLASS is
> "64bit".  More checks can be added to support 64-bit linkers in non-ELF
> format.
>
>  * testsuite/config/default.exp (LD_CLASS): New.  Set to "64bit"
>  for 64-bit ELF linker.
>  * testsuite/ld-x86-64/pr17618.d (#notarget): Removed.
>  * testsuite/ld-x86-64/x86-64.exp: Run pr17618 only for 64-bit
>  linker.

> diff --git a/ld/testsuite/config/default.exp b/ld/testsuite/config/default.exp
> index f5cb188478..355d98f24a 100644
> --- a/ld/testsuite/config/default.exp
> +++ b/ld/testsuite/config/default.exp
> @@ -251,6 +251,16 @@ if ![info exists LDFLAGS] then {
>      set LDFLAGS {}
>  }
>  
> +# Set LD_CLASS to "64bit" for 64-bit LD.
> +if { ![info exists LD_CLASS] } then {
> +    set readelf_output [run_host_cmd "$READELF" "-h $LD"]

(later changed LD to REAL_LD, but that doesn't solve the issue
pointed out below)

> +    if { [regexp {[ \t]+Class:[ \t]+ELF64} $readelf_output] } then {
> + set LD_CLASS "64bit"
> +    } else {
> + set LD_CLASS "32bit"
> +    }
> +}
> +

This method was suggested in PR ld/22304 as a help.  It's not
actually applicable there, but it's the reason I'm looking.

This looks like it has a bug.  You're looking at the "ELF class"
for the ld being built, which is not necessarily a program that
will run on the target; it will "only" work for native builds.
A trivial suggestion is to link some simple object and inspect
that result (instead of the ld tool).  If you really want the
host "ELF class" of the toolchain (which also has some value), I
think it should be called "BUILD_ELF_CLASS".  Note also that
either can be completely different from the "bfd-size";
i.e. whether --enable-64-bit-bfd has been explicitly or
implicitly used.

Unless I miss something?

(I don't care to mention Canadian crosses here, i.e. build !=
host != target, because then I'd surely confuse myself.)

brgds, H-P
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu-30
On Sat, Oct 21, 2017 at 11:34 AM, Hans-Peter Nilsson
<[hidden email]> wrote:

>> From: "H.J. Lu" <[hidden email]>
>> Date: Wed, 9 Aug 2017 15:08:54 -0700
>
>> PR ld/17618 test requires 64-bit linker to run.  Set LD_CLASS to "64bit"
>> for 64-bit ELF linker and run PR ld/17618 test only if $LD_CLASS is
>> "64bit".  More checks can be added to support 64-bit linkers in non-ELF
>> format.
>>
>>         * testsuite/config/default.exp (LD_CLASS): New.  Set to "64bit"
>>         for 64-bit ELF linker.
>>         * testsuite/ld-x86-64/pr17618.d (#notarget): Removed.
>>         * testsuite/ld-x86-64/x86-64.exp: Run pr17618 only for 64-bit
>>         linker.
>
>> diff --git a/ld/testsuite/config/default.exp b/ld/testsuite/config/default.exp
>> index f5cb188478..355d98f24a 100644
>> --- a/ld/testsuite/config/default.exp
>> +++ b/ld/testsuite/config/default.exp
>> @@ -251,6 +251,16 @@ if ![info exists LDFLAGS] then {
>>      set LDFLAGS {}
>>  }
>>
>> +# Set LD_CLASS to "64bit" for 64-bit LD.
>> +if { ![info exists LD_CLASS] } then {
>> +    set readelf_output [run_host_cmd "$READELF" "-h $LD"]
>
> (later changed LD to REAL_LD, but that doesn't solve the issue
> pointed out below)
>
>> +    if { [regexp {[ \t]+Class:[ \t]+ELF64} $readelf_output] } then {
>> +     set LD_CLASS "64bit"
>> +    } else {
>> +     set LD_CLASS "32bit"
>> +    }
>> +}
>> +
>
> This method was suggested in PR ld/22304 as a help.  It's not
> actually applicable there, but it's the reason I'm looking.
>
> This looks like it has a bug.  You're looking at the "ELF class"
> for the ld being built, which is not necessarily a program that
> will run on the target; it will "only" work for native builds.
> A trivial suggestion is to link some simple object and inspect
> that result (instead of the ld tool).  If you really want the
> host "ELF class" of the toolchain (which also has some value), I
> think it should be called "BUILD_ELF_CLASS".  Note also that
> either can be completely different from the "bfd-size";
> i.e. whether --enable-64-bit-bfd has been explicitly or
> implicitly used.
>
> Unless I miss something?
>

It checks if linker can support 64-bit address space, which
is independent of bfd-size.   Some tests require that linker
supports 64-bit address.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

Hans-Peter Nilsson
> From: "H.J. Lu" <[hidden email]>
> Date: Sat, 21 Oct 2017 12:17:23 -0700

> On Sat, Oct 21, 2017 at 11:34 AM, Hans-Peter Nilsson
> <[hidden email]> wrote:
> >> From: "H.J. Lu" <[hidden email]>
> >> 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
other than a native linker.  Again, you need to test an object
other than $REAL_LD.

> which
> is independent of bfd-size.   Some tests require that linker
> supports 64-bit address.

It's good that we agree about these parts.

brgds, H-P

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu-30
On Sat, Oct 21, 2017 at 1:47 PM, Hans-Peter Nilsson
<[hidden email]> wrote:

>> From: "H.J. Lu" <[hidden email]>
>> Date: Sat, 21 Oct 2017 12:17:23 -0700
>
>> On Sat, Oct 21, 2017 at 11:34 AM, Hans-Peter Nilsson
>> <[hidden email]> wrote:
>> >> From: "H.J. Lu" <[hidden email]>
>> >> 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.  We can tell the target address
from target.   But here is we want to know if the linker running on
host/build machine is 64-bit.

> other than a native linker.  Again, you need to test an object
> other than $REAL_LD.
>
>> which
>> is independent of bfd-size.   Some tests require that linker
>> supports 64-bit address.
>
> It's good that we agree about these parts.
>
> brgds, H-P
>



--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

Hans-Peter Nilsson
> From: "H.J. Lu" <[hidden email]>
> Date: Sat, 21 Oct 2017 15:31:58 -0700

> On Sat, Oct 21, 2017 at 1:47 PM, Hans-Peter Nilsson
> <[hidden email]> wrote:
> >> From: "H.J. Lu" <[hidden email]>
> >> Date: Sat, 21 Oct 2017 12:17:23 -0700
> >
> >> On Sat, Oct 21, 2017 at 11:34 AM, Hans-Peter Nilsson
> >> <[hidden email]> wrote:
> >> >> From: "H.J. Lu" <[hidden email]>
> >> >> 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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu-30
On Sat, Oct 21, 2017 at 4:37 PM, Hans-Peter Nilsson
<[hidden email]> wrote:

> 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

These tests don't care about target address space.

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

Some linker tests need to allocate more than 4GB memory,
which only work if linker is an ELF64 linker.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

Joseph Myers
On Sat, 21 Oct 2017, H.J. Lu wrote:

> Some linker tests need to allocate more than 4GB memory,
> which only work if linker is an ELF64 linker.

I would certainly hope such tests work, for example, with a linker built
for 64-bit Windows host, which would be a PE .exe file, not an ELF file at
all.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR ld/17618: Check PC-relative offset overflow in PLT entry

H.J. Lu-30
On Mon, Oct 23, 2017 at 10:13 AM, Joseph Myers <[hidden email]> wrote:
> On Sat, 21 Oct 2017, H.J. Lu wrote:
>
>> Some linker tests need to allocate more than 4GB memory,
>> which only work if linker is an ELF64 linker.
>
> I would certainly hope such tests work, for example, with a linker built
> for 64-bit Windows host, which would be a PE .exe file, not an ELF file at
> all.
>

Yes, a patch to detect 64-bit linker binary on Windows is needed.


--
H.J.