[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-17 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475

--- Comment #3 from whitequark at whitequark dot org ---
Actually, I might be wrong about this, since the comment in elflink.c implies
that the behavior is intentional. I'll attach another patch, which fixes the
logic of relocating R_OR1K_GOTOFF_* instead, making it follow the logic in
elflink.c.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-17 Thread whitequark at whitequark dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20475

--- Comment #4 from whitequark at whitequark dot org ---
Created attachment 9442
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9442&action=edit
OR1K target patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ncahill_alt at yahoo dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

ncahill_alt at yahoo dot com changed:

   What|Removed |Added

 CC||ncahill_alt at yahoo dot com

--- Comment #4 from ncahill_alt at yahoo dot com ---
Created attachment 9443
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9443&action=edit
object files that then failed the test

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ncahill_alt at yahoo dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #5 from ncahill_alt at yahoo dot com ---
Regarding this update, I'm getting a failure on "make testsuite/pr20308a_test":

pr20308_gd.o:function test_gd: error: missing expected TLS relocation
gcctestdir/ld: error: missing expected TLS relocation
pr20308_ld.o:function test_ld: error: missing expected TLS relocation
pr20308_ld.o:function test_ld: error: missing expected TLS relocation
gcctestdir/ld: error: missing expected TLS relocation

I see this message twice in i386.cc:

-- line 634 --
~Relocate()
{
  if (this->skip_call_tls_get_addr_)
{
  // FIXME: This needs to specify the location somehow.
  gold_error(_("missing expected TLS relocation"));
}
}

-- line 2787 ---
  const elfcpp::Rel<32, false> rel(preloc);
  unsigned int r_type = elfcpp::elf_r_type<32>(rel.get_r_info());

  if (this->skip_call_tls_get_addr_)
{
  if ((r_type != elfcpp::R_386_PLT32
   && r_type != elfcpp::R_386_GOT32X
   && r_type != elfcpp::R_386_PC32)
  || gsym == NULL
  || strcmp(gsym->name(), "___tls_get_addr") != 0)
gold_error_at_location(relinfo, relnum, rel.get_r_offset(),
   _("missing expected TLS relocation"));
  else
{
  this->skip_call_tls_get_addr_ = false;
  return false;
}
}
---

One thing I notice is this:

0066 R_386_GOT32   ___tls_get_addr

Hopefully that's the problem.  Also I wonder if it would be helpful to make
those two error messages slightly different so one could pick out which is
which.

Thank you.
Neil.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #6 from H.J. Lu  ---
Created attachment 9444
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9444&action=edit
Try this

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ncahill_alt at yahoo dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #7 from ncahill_alt at yahoo dot com ---
Created attachment 9445
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9445&action=edit
result of changes

It still fails:

pr20308_gd.o:function test_gd: error: missing expected TLS relocation
pr20308_ld.o:function test_ld: error: missing expected TLS relocation

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #8 from H.J. Lu  ---
(In reply to ncahill_alt from comment #7)
> Created attachment 9445 [details]
> result of changes
> 
> It still fails:
> 
> pr20308_gd.o:function test_gd: error: missing expected TLS relocation
> pr20308_ld.o:function test_ld: error: missing expected TLS relocation

Please show the output of "readelf -r pr20308_gd.o"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ncahill_alt at yahoo dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #9 from ncahill_alt at yahoo dot com ---

Relocation section '.rel.text' at offset 0x2ec contains 12 entries:
 Offset InfoTypeSym.Value  Sym. Name
0002  0b02 R_386_PC32   __x86.get_pc_thunk.bx
0008  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
0012  0d12 R_386_TLS_GD     gd
0017  0e04 R_386_PLT32      ___tls_get_addr
0022  0b02 R_386_PC32   __x86.get_pc_thunk.bx
0028  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
0031  0d12 R_386_TLS_GD     gd
0036  0e04 R_386_PLT32      ___tls_get_addr
0051  1102 R_386_PC32   __x86.get_pc_thunk.cx
0057  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
0060  0d12 R_386_TLS_GD     gd
0066  0e03 R_386_GOT32      ___tls_get_addr

CFLAGS = -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe
-funroll-loops -funswitch-loops
CXXFLAGS = -g -O2
LDFLAGS = -Wl,-O1

GCC is 5.2.0, i686-pc-linux-gnu-gcc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #10 from H.J. Lu  ---
(In reply to ncahill_alt from comment #9)
> Relocation section '.rel.text' at offset 0x2ec contains 12 entries:
>  Offset InfoTypeSym.Value  Sym. Name
> 0002  0b02 R_386_PC32   __x86.get_pc_thunk.bx
> 0008  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
> 0012  0d12 R_386_TLS_GD     gd
> 0017  0e04 R_386_PLT32      ___tls_get_addr
> 0022  0b02 R_386_PC32   __x86.get_pc_thunk.bx
> 0028  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
> 0031  0d12 R_386_TLS_GD     gd
> 0036  0e04 R_386_PLT32      ___tls_get_addr
> 0051  1102 R_386_PC32   __x86.get_pc_thunk.cx
> 0057  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
> 0060  0d12 R_386_TLS_GD     gd
> 0066  0e03 R_386_GOT32      ___tls_get_addr
> 
> CFLAGS = -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe
> -funroll-loops -funswitch-loops
> CXXFLAGS = -g -O2
> LDFLAGS = -Wl,-O1
> 
> GCC is 5.2.0, i686-pc-linux-gnu-gcc

Please show the command line used to compile pr20308_gd.o.

BTW, did you run "make clean" first?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


Re: [Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread Cary Coutant
> Please show the command line used to compile pr20308_gd.o.
>
> BTW, did you run "make clean" first?

Yeah, the build rules should also have a dependency on gcctestdir/as.
Forgot that when fixing the x86_64 test, sorry.

-cary

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ccoutant at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #11 from Cary Coutant  ---
> Please show the command line used to compile pr20308_gd.o.
>
> BTW, did you run "make clean" first?

Yeah, the build rules should also have a dependency on gcctestdir/as.
Forgot that when fixing the x86_64 test, sorry.

-cary

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20481] New: ld.gold should fail when producing an elf32 so >4G

2016-08-17 Thread tobiasjs at google dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20481

Bug ID: 20481
   Summary: ld.gold should fail when producing an elf32 so >4G
   Product: binutils
   Version: 2.24
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: tobiasjs at google dot com
CC: ian at airs dot com
  Target Milestone: ---

Created attachment 9448
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9448&action=edit
readelf -e good output

At the moment it succeeds without warning, but the resulting section header
offset is wrong, and the output is unusable.

In this case the library text is a comparatively sane 66M, but there is a
quantity of debug information best described as somewhat less so. I've attached
the readelf -e output for a version of the library where I stripped .o files
until I got the result down to slightly under 4G.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20481] ld.gold should fail when producing an elf32 so >4G

2016-08-17 Thread tobiasjs at google dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20481

--- Comment #1 from Tobias Sargeant  ---
Created attachment 9449
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9449&action=edit
readelf -e bad output

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ncahill_alt at yahoo dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #12 from ncahill_alt at yahoo dot com ---
(In reply to H.J. Lu from comment #10)
> (In reply to ncahill_alt from comment #9)
> > Relocation section '.rel.text' at offset 0x2ec contains 12 entries:
> >  Offset InfoTypeSym.Value  Sym. Name
> > 0002  0b02 R_386_PC32   __x86.get_pc_thunk.bx
> > 0008  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
> > 0012  0d12 R_386_TLS_GD     gd
> > 0017  0e04 R_386_PLT32      ___tls_get_addr
> > 0022  0b02 R_386_PC32   __x86.get_pc_thunk.bx
> > 0028  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
> > 0031  0d12 R_386_TLS_GD     gd
> > 0036  0e04 R_386_PLT32      ___tls_get_addr
> > 0051  1102 R_386_PC32   __x86.get_pc_thunk.cx
> > 0057  0c0a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
> > 0060  0d12 R_386_TLS_GD     gd
> > 0066  0e03 R_386_GOT32      ___tls_get_addr
> > 
> > CFLAGS = -O2 -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe
> > -funroll-loops -funswitch-loops
> > CXXFLAGS = -g -O2
> > LDFLAGS = -Wl,-O1
> > 
> > GCC is 5.2.0, i686-pc-linux-gnu-gcc
> 
> Please show the command line used to compile pr20308_gd.o.

i686-pc-linux-gnu-gcc -Bgcctestdir/ -fPIE -O2 -fno-tree-slsr -march=athlon64
-mtune=core2 -fno-inline -pipe -funroll-loops -funswitch-loops -Bgcctestdir/
-Wl,-R,. -Wl,-O1 -o pr20308a_test pr20308a_test-pr20308_main.o
pr20308a_test-pr20308_def.o pr20308_gd.o pr20308_ld.o -ldl

> 
> BTW, did you run "make clean" first?

Yes, I built binutils from scratch each time.  This all looks odd but
basically...
1.  CFLAGS is very well tested, I won't go into it but it gives helpful
profiling results, for example I was able to report performance issues with
GCC.
2.  CXXFLAGS should have been the same, I had a script that set everything but
I had to recreate it and forgot to set CXXFLAGS.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ncahill_alt at yahoo dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #13 from ncahill_alt at yahoo dot com ---
Oh sorry, here it is:

`echo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I../../../binutils-2.27/gold/testsuite -I.. 
-I../../../binutils-2.27/gold/testsuite
-I../../../binutils-2.27/gold/testsuite/..
-I../../../binutils-2.27/gold/testsuite/../../include
-I../../../binutils-2.27/gold/testsuite/../../elfcpp -I..
-DLOCALEDIR="\"/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale\""   -W
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -fno-tree-slsr
-march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops -funswitch-loops
| sed -e 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -Bgcctestdir/ -c -o
pr20308_gd.o ../../../binutils-2.27/gold/testsuite/pr20308_gd.S

which translates to

i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I../../../binutils-2.27/gold/testsuite -I..
-I../../../binutils-2.27/gold/testsuite
-I../../../binutils-2.27/gold/testsuite/..
-I../../../binutils-2.27/gold/testsuite/../../include
-I../../../binutils-2.27/gold/testsuite/../../elfcpp -I..
-DLOCALEDIR="/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale" -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2 -fno-tree-slsr
-march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops -funswitch-loops
-Bgcctestdir/ -c -o pr20308_gd.o
../../../binutils-2.27/gold/testsuite/pr20308_gd.S

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/20475] Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

2016-08-17 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20475

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #5 from Alan Modra  ---
Yes, your second patch is much better.  The first one probably would break some
other target.  Even better would be to use the value of _GLOBAL_OFFSET_TABLE_

  relocation
-= (htab->root.hgot->root.u.def.value
+ htab->root.hgot->root.u.def.section->output_offset
+ htab->root.hgot->root.u.def.section->output_section->vma);

Assuming the or1k backend doesn't have other bugs in this area, that would
allow a script to define _GLOBAL_OFFSET_TABLE_ at somewhere other than the
start of .got.plt.  If the above tests out OK, please post the patch to
binut...@sourceware.org noting my preapproval, and commit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #14 from H.J. Lu  ---
(In reply to ncahill_alt from comment #13)
> Oh sorry, here it is:
> 
> `echo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
> -I../../../binutils-2.27/gold/testsuite -I.. 
> -I../../../binutils-2.27/gold/testsuite
> -I../../../binutils-2.27/gold/testsuite/..
> -I../../../binutils-2.27/gold/testsuite/../../include
> -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I..
> -DLOCALEDIR="\"/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale\""  
> -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
> -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -fmerge-constants -O2 -fno-tree-slsr -march=athlon64 -mtune=core2
> -fno-inline -pipe -funroll-loops -funswitch-loops | sed -e
> 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -Bgcctestdir/ -c -o pr20308_gd.o
> ../../../binutils-2.27/gold/testsuite/pr20308_gd.S
> 
> which translates to
> 
> i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
> -I../../../binutils-2.27/gold/testsuite -I..
> -I../../../binutils-2.27/gold/testsuite
> -I../../../binutils-2.27/gold/testsuite/..
> -I../../../binutils-2.27/gold/testsuite/../../include
> -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I..
> -DLOCALEDIR="/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale" -W
> -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2
> -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops
> -funswitch-loops -Bgcctestdir/ -c -o pr20308_gd.o
> ../../../binutils-2.27/gold/testsuite/pr20308_gd.S

This should generate R_386_GOT32X, not R_386_GOT32 relocation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gold/20308] Gold should support i386 TLS code sequences without PLT

2016-08-17 Thread ncahill_alt at yahoo dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20308

--- Comment #15 from ncahill_alt at yahoo dot com ---
(In reply to H.J. Lu from comment #14)
> (In reply to ncahill_alt from comment #13)
> > Oh sorry, here it is:
> > 
> > `echo i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
> > -I../../../binutils-2.27/gold/testsuite -I.. 
> > -I../../../binutils-2.27/gold/testsuite
> > -I../../../binutils-2.27/gold/testsuite/..
> > -I../../../binutils-2.27/gold/testsuite/../../include
> > -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I..
> > -DLOCALEDIR="\"/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale\""  
> > -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
> > -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> > -fmerge-constants -O2 -fno-tree-slsr -march=athlon64 -mtune=core2
> > -fno-inline -pipe -funroll-loops -funswitch-loops | sed -e
> > 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -Bgcctestdir/ -c -o pr20308_gd.o
> > ../../../binutils-2.27/gold/testsuite/pr20308_gd.S
> > 
> > which translates to
> > 
> > i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
> > -I../../../binutils-2.27/gold/testsuite -I..
> > -I../../../binutils-2.27/gold/testsuite
> > -I../../../binutils-2.27/gold/testsuite/..
> > -I../../../binutils-2.27/gold/testsuite/../../include
> > -I../../../binutils-2.27/gold/testsuite/../../elfcpp -I..
> > -DLOCALEDIR="/usr/share/binutils-data/i686-pc-linux-gnu/2.27/locale" -W
> > -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -O2
> > -fno-tree-slsr -march=athlon64 -mtune=core2 -fno-inline -pipe -funroll-loops
> > -funswitch-loops -Bgcctestdir/ -c -o pr20308_gd.o
> > ../../../binutils-2.27/gold/testsuite/pr20308_gd.S
> 
> This should generate R_386_GOT32X, not R_386_GOT32 relocation.

Could this be a glibc problem?  I see this patch dated December 2015:

> diff --git a/backends/ChangeLog b/backends/ChangeLog 
> index 4b604fd..cc0dd6f 100644 
> --- a/backends/ChangeLog 
> +++ b/backends/ChangeLog 
> @@ -1,3 +1,8 @@ 
> +2015-12-28 Mark Wielaard ; 
> + 
> + * i386_reloc.def: Add GOT32X. 
> + * x86_64_reloc.def: Add GOTPCRELX and REX_GOTPCRELX. 
> + 2015-12-08 Jose E. Marchesi ;

I'm using glibc-2.22 from 2015-08-14.  In fact, I can confirm that elf.h
defines R_386_GOT32 but not R_386_GOT32X:

> #define R_68K_GOT32 7   /* 32 bit PC relative GOT entry */
> #define R_68K_GOT32O10  /* 32 bit GOT offset */
> #define R_386_GOT323/* 32 bit GOT entry */
> #define R_ARM_GOT32 26  /* 32 bit GOT entry */
> #define R_SH_GOT32  160
> #define R_390_GOT32 7   /* 32 bit GOT offset.  */
> #define R_X86_64_GOT32  3   /* 32 bit GOT entry */
> #define R_MN10300_GOT32 17  /* 32-bit offset to GOT entry.  */

I think this must be it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils