Re: building glibc with gold linker & -frecord-gcc-switches results in internal error

[Cary Coutant <ccoutant at google dot com>]

I received a (very) simple test case that demonstrates the problem --
a copy of crti.o compiled with -frecord-gcc-switches. An attempt to
link just that file produces:

ld-new: internal error in relocate, at ../../binutils/gold/i386.cc:2512

This is an attempt to apply an R_386_GOT32 relocation in the
.GCC.command.line section, but we never scanned the relocations in
that section because it's not allocated.

There are 15 section headers, starting at offset 0xa60:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000034 000000 00  AX  0   0  4
  [ 2] .data             PROGBITS        00000000 000034 000000 00  WA  0   0  4
  [ 3] .bss              NOBITS          00000000 000034 000000 00  WA  0   0  4
  [ 4] .GCC.command.line PROGBITS        00000000 000034 00095c 01  MS  0   0  4
  [ 5] .rel.GCC.command.line REL             00000000 000dbc 000018 08
    13   4  4
  [ 6] .init             PROGBITS        00000000 000990 00000b 00  AX  0   0  4
  [ 7] .rel.init         REL             00000000 000dd4 000008 08     13   6  4
  [ 8] .fini             PROGBITS        00000000 00099c 000011 00  AX  0   0  4
  [ 9] .rel.fini         REL             00000000 000ddc 000008 08     13   8  4
  [10] .comment          PROGBITS        00000000 0009ad 000043 01  MS  0   0  1
  [11] .note.GNU-stack   PROGBITS        00000000 0009f0 000000 00      0   0  1
  [12] .shstrtab         STRTAB          00000000 0009f0 00006f 00      0   0  1
  [13] .symtab           SYMTAB          00000000 000cb8 0000d0 10     14   9  4
  [14] .strtab           STRTAB          00000000 000d88 000032 00      0   0  1

Relocation section '.rel.GCC.command.line' at offset 0xdbc contains 3 entries:
 Offset     Info    Type                Sym. Value  Symbol's Name
00000945  00000a0a R_386_GOTPC            00000000   _GLOBAL_OFFSET_TABLE_
0000094b  00000903 R_386_GOT32            00000000   __gmon_start__
00000954  00000904 R_386_PLT32            00000000   __gmon_start__

For some reason, the .GCC.command.line section is marked as a
non-allocated, string merge section, and it consists entirely of
strings up until offset 0x936, where some binary data begins, with the
three relocations:

Hex dump of section '.GCC.command.line':
 NOTE: This section has relocations against it, but these have NOT
been applied to this dump.
  0x00000000 2d6e6f73 7464696e 63002d49 202e2e2f -nostdinc.-I ../
  0x00000010 696e636c 75646500 2d49202f 7661722f include.-I /var/
  0x00000020 746d702f 706f7274 6167652f 63726f73 tmp/portage/cros
  0x00000030 732d6936 38362d70 632d6c69 6e75782d s-i686-pc-linux-
  0x00000040 676e752f 676c6962 632d322e 31312e31 gnu/glibc-2.11.1
  [snip]
  0x00000900 6e77696e 642d7461 626c6573 002d6669 nwind-tables.-fi
  0x00000910 6e686962 69742d73 697a652d 64697265 nhibit-size-dire
  0x00000920 63746976 65002d66 6e6f2d65 78636570 ctive.-fno-excep
  0x00000930 74696f6e 73000000 5589e553 52e80000 tions...U..SR...
  0x00000940 00005b81 c3030000 008b8b00 00000085 ..[.............
  0x00000950 c97405e8 fcffffff 585b5dc3          .t......X[].

I'm not sure what to make of this. I think it clearly doesn't make
sense to have those relocations in a string merge section, so I'd
think the right thing to do here is to fix gold so that it prints an
error instead of asserting.

Ian, what do you think?

-cary