[PATCH] D31528: [ELF][MIPS] Multi-GOT implementation

[Ed Maste via Phabricator via llvm-commits]

emaste added a comment.

I compared the tmp objects in the failing and passing case using diffoscope and noticed one unexpected difference, although it does not appear to be root cause of the failure.

With stat() differences elided I see:

  --- fail
  +++ work
  ├── file list
  │ @@ -1,3 +1,4 @@
  │ +mips-got-and-copy.s.tmp.exe
  │  mips-got-and-copy.s.tmp.o
  │  mips-got-and-copy.s.tmp.so
  │  mips-got-and-copy.s.tmp.so.o
  ├── mips-got-and-copy.s.tmp.so
  ├── readelf --wide --symbols {}
  │ │ @@ -1,16 +1,16 @@
  │ │  
  │ │  Symbol table '.dynsym' contains 6 entries:
  │ │     Num:    Value  Size Type    Bind   Vis      Ndx Name
  │ │       0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
  │ │ -     1: 00010008     0 FUNC    GLOBAL DEFAULT    7 foo1
  │ │ -     2: 00010004     0 FUNC    GLOBAL DEFAULT    7 foo0
  │ │ +     1: 00010000     0 NOTYPE  GLOBAL DEFAULT    7 _foo
  │ │ +     2: 00020000     4 OBJECT  GLOBAL DEFAULT    8 data0
  │ │       3: 00020004     4 OBJECT  GLOBAL DEFAULT    8 data1
  │ │ -     4: 00020000     4 OBJECT  GLOBAL DEFAULT    8 data0
  │ │ -     5: 00010000     0 NOTYPE  GLOBAL DEFAULT    7 _foo
  │ │ +     4: 00010004     0 FUNC    GLOBAL DEFAULT    7 foo0
  │ │ +     5: 00010008     0 FUNC    GLOBAL DEFAULT    7 foo1
  │ │  
  │ │  Symbol table '.symtab' contains 8 entries:
  │ │     Num:    Value  Size Type    Bind   Vis      Ndx Name
  │ │       0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
  │ │       1: 00028000     0 NOTYPE  LOCAL  HIDDEN   ABS _gp
  │ │       2: 000001c0     0 NOTYPE  LOCAL  HIDDEN     5 _DYNAMIC
  │ │       3: 00010000     0 NOTYPE  GLOBAL DEFAULT    7 _foo
  ├── readelf --wide --decompress --hex-dump=.hash {}
  │ │ @@ -1,7 +1,7 @@
  │ │  
  │ │  Hex dump of section '.hash':
  │ │ -  0x00000188 00000006 00000006 00000002 00000001 ................
  │ │ -  0x00000198 00000004 00000003 00000000 00000005 ................
  │ │ +  0x00000188 00000006 00000006 00000004 00000005 ................
  │ │ +  0x00000198 00000002 00000003 00000000 00000001 ................
  │ │    0x000001a8 00000000 00000000 00000000 00000000 ................
  │ │    0x000001b8 00000000 00000000                   ........

so for some reason the sort order for .dynsym is reversed between the two cases.


Repository:
  rL LLVM

https://reviews.llvm.org/D31528