Re: [RFA] "fix" a problem where a breakpoint would be associated with the wrong source

[PAUL GILLIAM <pgilliam@us.ibm.com>]

On Fri, 2006-02-10 at 00:33 -0500, Daniel Jacobowitz wrote: 
> I wrote:
> 
> On Thu, Feb 09, 2006 at 06:14:19PM -0800, PAUL GILLIAM wrote:
> > On Wed, 2006-02-01 at 20:27 -0500, Daniel Jacobowitz wrote:
> > > The patch is definitely wrong, as you suspected.  We'd need to see a
> > > testcase; it could be bogus, or partially missing, debug information.
> > > Is the 'bad' breakpoint in a file with line numbers?
> 
> That's still true; Paul, rather than poking around in the symbol
> reader, I think we need to know how to reproduce this so that we can
> understand what's going on.  This code is all very fragile; without
> some idea of what you're trying to fix I've got no idea if it's right
> or not.

I am working on trying to get together a small test case.

In the mean time, here is a better description of what is going bad and why:

There is a compilation unit that uses constructors/destructors for some class.
There is a .text section for it in the executable, followed by '.gnu.linkonce...'
sections for those constructors/destructors.  Then there is a .text section for
the compilation unit that contains the function we are trying to set a breakpoint
on.  Then comes a .text section for part of the implementation for that class.

The high/low pc values for the compilation unit for that last .text section are
not given in it's compilation unit DIE.  GDB computes high/low pc values, but these
are bogus because the code for the compilation unit is not contiguous.  When GDB
searches for the psymtab that contains the function where the breakpoint was set,
it finds the wrong one because of these bogus high/low pc values.  It then returns
the 'best' sal from the wrong psymtab which has nothing to do with the function being
breakpointed.

I think the .opd think was a red herring. 

-=# Paul #=-