* building glibc with gold linker & -frecord-gcc-switches results in internal error
@ 2011-11-29 3:29 Per Øyvind Karlsen
2011-11-29 6:44 ` Ian Lance Taylor
0 siblings, 1 reply; 11+ messages in thread
From: Per Øyvind Karlsen @ 2011-11-29 3:29 UTC (permalink / raw)
To: binutils
When building glibc using the gold linker and compiling with
-frecord-gcc-switches the following happens (keeping it short with the
relevant details only):
gcc -shared -static-libgcc
-Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -Wl,-z,defs
-B/home/peroy vind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/csu/
-Wl,-z,combreloc -Wl,--hash-style=both
-L/home/peroyvind/RPM/glibc/B
UILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux
-L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/math
-L/home/pe royvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf
-L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_6
4-linux/dlfcn -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nss
-L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-
394-g8f3b1ff/build-x86_64-linux/nis
-L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/rt
-L/home/peroyvind/RPM/gl
ibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/resolv
-L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/cry
pt -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nptl
-Wl,-rpath-link=/home/peroyvind/RPM/glibc/BUILD/glibc-2
.14-394-g8f3b1ff/build-x86_64-linux:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/math:/home/peroyvind/RPM/glib
c/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/dlfcn:/hom
e/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nss:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86
_64-linux/nis:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/rt:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g
8f3b1ff/build-x86_64-linux/resolv:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/crypt:/home/peroyvind/RPM/glibc
/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nptl -o
/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/sot
russ-lib.so /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/csu/abi-note.o
-Wl,--as-needed /home/peroyvind/RPM/g
libc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/sotruss-lib.os
/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_6
4-linux/libc.so
/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/ld.so
/home/peroyvind/RPM/glibc/BUILD/glibc-2
.14-394-g8f3b1ff/build-x86_64-linux/libc_nonshared.a
-Wl,--no-as-needed
/usr/bin/ld: internal error in relocate, at ../../gold/x86_64.cc:2917
collect2: ld returned 1 exit status
This does not happen with BFD linker, and removing
-frecord-gcc-switches will avoid this happening when using gold
linker..
--
Regards,
Per Øyvind
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2011-11-29 3:29 building glibc with gold linker & -frecord-gcc-switches results in internal error Per Øyvind Karlsen
@ 2011-11-29 6:44 ` Ian Lance Taylor
2011-11-29 6:50 ` Per Øyvind Karlsen
0 siblings, 1 reply; 11+ messages in thread
From: Ian Lance Taylor @ 2011-11-29 6:44 UTC (permalink / raw)
To: Per Øyvind Karlsen; +Cc: binutils
Per Øyvind Karlsen <peroyvind@mandriva.org> writes:
> When building glibc using the gold linker and compiling with
> -frecord-gcc-switches the following happens (keeping it short with the
> relevant details only):
> gcc -shared -static-libgcc
> -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -Wl,-z,defs
> -B/home/peroy vind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/csu/
> -Wl,-z,combreloc -Wl,--hash-style=both
> -L/home/peroyvind/RPM/glibc/B
> UILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux
> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/math
> -L/home/pe royvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf
> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_6
> 4-linux/dlfcn -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nss
> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-
> 394-g8f3b1ff/build-x86_64-linux/nis
> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/rt
> -L/home/peroyvind/RPM/gl
> ibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/resolv
> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/cry
> pt -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nptl
> -Wl,-rpath-link=/home/peroyvind/RPM/glibc/BUILD/glibc-2
> .14-394-g8f3b1ff/build-x86_64-linux:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/math:/home/peroyvind/RPM/glib
> c/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/dlfcn:/hom
> e/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nss:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86
> _64-linux/nis:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/rt:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g
> 8f3b1ff/build-x86_64-linux/resolv:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/crypt:/home/peroyvind/RPM/glibc
> /BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nptl -o
> /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/sot
> russ-lib.so /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/csu/abi-note.o
> -Wl,--as-needed /home/peroyvind/RPM/g
> libc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/sotruss-lib.os
> /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_6
> 4-linux/libc.so
> /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/ld.so
> /home/peroyvind/RPM/glibc/BUILD/glibc-2
> .14-394-g8f3b1ff/build-x86_64-linux/libc_nonshared.a
> -Wl,--no-as-needed
> /usr/bin/ld: internal error in relocate, at ../../gold/x86_64.cc:2917
> collect2: ld returned 1 exit status
>
>
> This does not happen with BFD linker, and removing
> -frecord-gcc-switches will avoid this happening when using gold
> linker..
Can you pare this down to a test case smaller than building glibc?
Which gold sources are you using?
Ian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2011-11-29 6:44 ` Ian Lance Taylor
@ 2011-11-29 6:50 ` Per Øyvind Karlsen
2012-02-14 20:05 ` Cary Coutant
0 siblings, 1 reply; 11+ messages in thread
From: Per Øyvind Karlsen @ 2011-11-29 6:50 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils
Den 07:43 29. november 2011 skrev Ian Lance Taylor <iant@google.com> følgende:
> Per Øyvind Karlsen <peroyvind@mandriva.org> writes:
>
>> When building glibc using the gold linker and compiling with
>> -frecord-gcc-switches the following happens (keeping it short with the
>> relevant details only):
>> gcc -shared -static-libgcc
>> -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -Wl,-z,defs
>> -B/home/peroy vind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/csu/
>> -Wl,-z,combreloc -Wl,--hash-style=both
>> -L/home/peroyvind/RPM/glibc/B
>> UILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux
>> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/math
>> -L/home/pe royvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf
>> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_6
>> 4-linux/dlfcn -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nss
>> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-
>> 394-g8f3b1ff/build-x86_64-linux/nis
>> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/rt
>> -L/home/peroyvind/RPM/gl
>> ibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/resolv
>> -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/cry
>> pt -L/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nptl
>> -Wl,-rpath-link=/home/peroyvind/RPM/glibc/BUILD/glibc-2
>> .14-394-g8f3b1ff/build-x86_64-linux:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/math:/home/peroyvind/RPM/glib
>> c/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/dlfcn:/hom
>> e/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nss:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86
>> _64-linux/nis:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/rt:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g
>> 8f3b1ff/build-x86_64-linux/resolv:/home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/crypt:/home/peroyvind/RPM/glibc
>> /BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/nptl -o
>> /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/sot
>> russ-lib.so /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/csu/abi-note.o
>> -Wl,--as-needed /home/peroyvind/RPM/g
>> libc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/sotruss-lib.os
>> /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_6
>> 4-linux/libc.so
>> /home/peroyvind/RPM/glibc/BUILD/glibc-2.14-394-g8f3b1ff/build-x86_64-linux/elf/ld.so
>> /home/peroyvind/RPM/glibc/BUILD/glibc-2
>> .14-394-g8f3b1ff/build-x86_64-linux/libc_nonshared.a
>> -Wl,--no-as-needed
>> /usr/bin/ld: internal error in relocate, at ../../gold/x86_64.cc:2917
>> collect2: ld returned 1 exit status
>>
>>
>> This does not happen with BFD linker, and removing
>> -frecord-gcc-switches will avoid this happening when using gold
>> linker..
>
> Can you pare this down to a test case smaller than building glibc?
I wish.. :/
>
> Which gold sources are you using?
Latest.
--
Regards,
Per Øyvind
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2011-11-29 6:50 ` Per Øyvind Karlsen
@ 2012-02-14 20:05 ` Cary Coutant
2012-02-14 21:22 ` Ian Lance Taylor
0 siblings, 1 reply; 11+ messages in thread
From: Cary Coutant @ 2012-02-14 20:05 UTC (permalink / raw)
To: Per Øyvind Karlsen; +Cc: Ian Lance Taylor, binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2012-02-14 20:05 ` Cary Coutant
@ 2012-02-14 21:22 ` Ian Lance Taylor
2012-02-14 21:38 ` Cary Coutant
0 siblings, 1 reply; 11+ messages in thread
From: Ian Lance Taylor @ 2012-02-14 21:22 UTC (permalink / raw)
To: Cary Coutant; +Cc: Per Øyvind Karlsen, binutils
Cary Coutant <ccoutant@google.com> writes:
> 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?
Would the error be about a GOT32 relocation in a non-allocated section?
Or would it be about an unrecognized relocation in a string merge
section? I can't quite decide if we should give an error for either of
those cases or whether we should try to handle them as best we can.
Obviously an error is better than a crash.
And obviously it would be good to figure out what gcc is doing to create
those relocations, and try to fix that.
Ian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2012-02-14 21:22 ` Ian Lance Taylor
@ 2012-02-14 21:38 ` Cary Coutant
2012-02-14 21:44 ` Cary Coutant
2012-02-14 23:55 ` Ian Lance Taylor
0 siblings, 2 replies; 11+ messages in thread
From: Cary Coutant @ 2012-02-14 21:38 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Per Øyvind Karlsen, binutils
> Would the error be about a GOT32 relocation in a non-allocated section?
> Or would it be about an unrecognized relocation in a string merge
> section? I can't quite decide if we should give an error for either of
> those cases or whether we should try to handle them as best we can.
I think both of those conditions are worthy of an error message. I
don't think we want to go allocating GOT and PLT entries based on
relocations in non-allocated sections. For string merge sections, the
only reasonable thing to do other than an error is to turn off the
merge property and process the section as a normal section -- but by
the time we are scanning relocations, I think gold is committed to the
merge processing. I suppose we could make an early check, but I doubt
it's worth it.
> And obviously it would be good to figure out what gcc is doing to create
> those relocations, and try to fix that.
Yes. I've just started looking at gcc, but don't see anything obvious.
Nothing in elf_record_gcc_switches() looks like it would be adding
those relocs to the end of the section.
-cary
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2012-02-14 21:38 ` Cary Coutant
@ 2012-02-14 21:44 ` Cary Coutant
2012-02-14 23:30 ` Cary Coutant
2012-02-14 23:55 ` Ian Lance Taylor
1 sibling, 1 reply; 11+ messages in thread
From: Cary Coutant @ 2012-02-14 21:44 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Per Øyvind Karlsen, binutils
>> And obviously it would be good to figure out what gcc is doing to create
>> those relocations, and try to fix that.
>
> Yes. I've just started looking at gcc, but don't see anything obvious.
> Nothing in elf_record_gcc_switches() looks like it would be adding
> those relocs to the end of the section.
The Makefile rules for crti.o do some massaging of the assembly with
sed. I wonder if something is going haywire there.
-cary
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2012-02-14 21:44 ` Cary Coutant
@ 2012-02-14 23:30 ` Cary Coutant
2012-02-14 23:55 ` Ian Lance Taylor
0 siblings, 1 reply; 11+ messages in thread
From: Cary Coutant @ 2012-02-14 23:30 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Per Øyvind Karlsen, binutils
> The Makefile rules for crti.o do some massaging of the assembly with
> sed. I wonder if something is going haywire there.
That's exactly what's happening. Here's the code for initfini.s...
.file "initfini.c"
.section .GCC.command.line,"MS",@progbits,1
.ascii "-nostdinc"
.zero 1
.ascii "-I ../include"
.zero 1
.ascii "-I /var/tmp/portage/cross-i686-pc-linux-gnu/glibc-2.11.1-r3/"
.ascii "work/build-default-i686-pc-linux-gnu-nptl/csu"
.zero 1
[...snip...]
.ascii "-finhibit-size-directive"
.zero 1
.ascii "-fno-exceptions"
.zero 1
#APP
#include "defs.h"
/*@HEADER_ENDS*/
/*@TESTS_BEGIN*/
#NO_APP
.text
.p2align 2,,3
.globl dummy
.type dummy, @function
dummy:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl 8(%ebp), %eax
testl %eax, %eax
je .L1
call *%eax
.L1:
leave
ret
#APP
/*@TESTS_END*/
/*@_init_PROLOG_BEGINS*/
#NO_APP
.p2align 2,,3
.type call_gmon_start, @function
call_gmon_start:
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edx
call .L6
[...]
The glibc/csu/Makefile runs this code through a sed script that
deletes everything between HEADER_ENDS and _init_PROLOG_BEGINS, which
loses the ".text" directive, and the code for call_gmon_start ends up
placed in the .GCC.command.line section.
Refile this as a glibc bug (although we'll keep this one open for the
assert failure that should be a reasonable error message).
-cary
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2012-02-14 23:30 ` Cary Coutant
@ 2012-02-14 23:55 ` Ian Lance Taylor
0 siblings, 0 replies; 11+ messages in thread
From: Ian Lance Taylor @ 2012-02-14 23:55 UTC (permalink / raw)
To: Cary Coutant; +Cc: Per Øyvind Karlsen, binutils
Cary Coutant <ccoutant@google.com> writes:
> The glibc/csu/Makefile runs this code through a sed script that
> deletes everything between HEADER_ENDS and _init_PROLOG_BEGINS, which
> loses the ".text" directive, and the code for call_gmon_start ends up
> placed in the .GCC.command.line section.
Cute.
Ian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2012-02-14 21:38 ` Cary Coutant
2012-02-14 21:44 ` Cary Coutant
@ 2012-02-14 23:55 ` Ian Lance Taylor
2012-02-15 1:03 ` Cary Coutant
1 sibling, 1 reply; 11+ messages in thread
From: Ian Lance Taylor @ 2012-02-14 23:55 UTC (permalink / raw)
To: Cary Coutant; +Cc: Per Øyvind Karlsen, binutils
Cary Coutant <ccoutant@google.com> writes:
>> Would the error be about a GOT32 relocation in a non-allocated section?
>> Or would it be about an unrecognized relocation in a string merge
>> section? I can't quite decide if we should give an error for either of
>> those cases or whether we should try to handle them as best we can.
>
> I think both of those conditions are worthy of an error message. I
> don't think we want to go allocating GOT and PLT entries based on
> relocations in non-allocated sections.
Good point.
> For string merge sections, the
> only reasonable thing to do other than an error is to turn off the
> merge property and process the section as a normal section -- but by
> the time we are scanning relocations, I think gold is committed to the
> merge processing. I suppose we could make an early check, but I doubt
> it's worth it.
For a string merge section we don't really have to scan the relocs--if
there are any relocs at all, something weird is going on.
Output_section::add_merge_input_section already supports having
add_input_section return false to mean that the section should be
handled as a normal section rather than a merge section.
Ian
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: building glibc with gold linker & -frecord-gcc-switches results in internal error
2012-02-14 23:55 ` Ian Lance Taylor
@ 2012-02-15 1:03 ` Cary Coutant
0 siblings, 0 replies; 11+ messages in thread
From: Cary Coutant @ 2012-02-15 1:03 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Per Øyvind Karlsen, binutils
> For a string merge section we don't really have to scan the relocs--if
> there are any relocs at all, something weird is going on.
> Output_section::add_merge_input_section already supports having
> add_input_section return false to mean that the section should be
> handled as a normal section rather than a merge section.
As it turns out, add_merge_input_section already refuses to handle it
as a merge section if reloc_shndx > 0, so we're good here.
We just need to gracefully handle the GOT reloc in a non-allocated section.
-cary
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-02-15 1:03 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-29 3:29 building glibc with gold linker & -frecord-gcc-switches results in internal error Per Øyvind Karlsen
2011-11-29 6:44 ` Ian Lance Taylor
2011-11-29 6:50 ` Per Øyvind Karlsen
2012-02-14 20:05 ` Cary Coutant
2012-02-14 21:22 ` Ian Lance Taylor
2012-02-14 21:38 ` Cary Coutant
2012-02-14 21:44 ` Cary Coutant
2012-02-14 23:30 ` Cary Coutant
2012-02-14 23:55 ` Ian Lance Taylor
2012-02-14 23:55 ` Ian Lance Taylor
2012-02-15 1:03 ` Cary Coutant
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).