This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
- From: Cary Coutant <ccoutant at google dot com>
- To: Per Øyvind Karlsen <peroyvind at mandriva dot org>
- Cc: Ian Lance Taylor <iant at google dot com>, binutils <binutils at sourceware dot org>
- Date: Tue, 14 Feb 2012 12:05:22 -0800
- Subject: Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
- References: <CA+0WU1SqJgWb74moznhKa7_LwPgYQQWh0ZsYv62_Bgx_twETaw@mail.gmail.com> <mcr1usrzaw1.fsf@dhcp-172-18-216-180.mtv.corp.google.com> <CA+0WU1R2DJCSALj2FaPOHC1+DfojXjXV-JGXcwN3qK_kRDJkiw@mail.gmail.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