This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]