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: Ian Lance Taylor <iant at google dot com>
- Cc: Per Øyvind Karlsen <peroyvind at mandriva dot org>, binutils <binutils at sourceware dot org>
- Date: Tue, 14 Feb 2012 13:37:57 -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> <CAHACq4pREHCw3hxY8sj3aurO-WBoaN5Fd5sGH=XAMaNooZ7ghw@mail.gmail.com> <mcrr4xx9kkw.fsf@dhcp-172-18-216-180.mtv.corp.google.com>
> 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