This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD] debug_msg test
On Wed, Mar 06, 2013 at 09:46:37AM -0800, Cary Coutant wrote:
> > Although it does seem like a bug that the linker can't even come up
> > with the source file here.
>
> It could come up with a source file here, but if it can't find a line
> number, we opt for object file + section + offset, which is probably
> more useful than a source file without a line number.
>
> Besides, this test is specifically testing gold's ability to come up
> with the line number. Are you sure there's not a problem in the dwarf
> reader? If the powerpc compiler doesn't write good enough debug info
> for this test, maybe we should just disable it for powerpc. Ah, the
> reference is in the .toc section -- is this being compiled in PIC
> mode? Maybe the symbolization logic needs to be a little smarter to
> support powerpc (I checked on x86_64, and this works fine with -fPIC).
Yes, I'm sure we don't have a problem with the dwarf info. (Or at
least, it's not an easy problem to fix.) PowerPC64 doesn't have a
linker managed GOT like most other targets. Instead the compiler
manages the GOT (and calls it TOC). That results in no relocation
on the actual code referencing a variable, but one in the TOC section
instead. Like a linker managed GOT, a TOC entry can serve multiple
references to a given symbol, so there isn't really any way to
associate a TOC entry with a particular source/line. I suppose we
could modify gcc to output one source/line combo on TOC entries, but
we don't do that currently.
A similar situation happens on ppc32 with -fPIC and the .got2 section,
which again is a compiler managed GOT.
> The duplicate checks were there because there really are two sets of
> errors printed out, for undefined references from different functions
> -- gold used to print out the function name in addition to file and
> line number, and the tests were looking for that, too. The error
> messages got simplified in a patch on 4/18/11, and the second set of
> checks became redundant. Maybe we should adjust the test case to count
> the number of occurrences and check that there are two of each.
>
> -cary
--
Alan Modra
Australia Development Lab, IBM