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

Daniel Jacobowitz
2006-02-10T05:33:56Z

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.

> Here is another patch that 'fixes' the problem.
>
> In symtab.c(find_pc_sect_psymtab), we first see if we can find a symbol
> in the minimal symbol table that contains the PC in the proper section.
> If so, we make sure the PC is a text symbol. But in my case, the section
> is '.opd' so we can't find a minimal symbol.

First of all, why is the PC in .opd? Last time I looked at the PPC64
ABI, which was a while ago, .opd contained descriptors, not code. Are
we actually executing code in .opd? How did it get there? Is there
a partial symbol for the code we're executing (i.e. debug info)?

All the code involving texthigh/textlow is a bit sketchy. Nowadays
we could be recording precise ranges instead, in many cases; Jim
posted a potential interface for that a year or two ago. Maybe
that would fix your problem.

I think that if your patch works, it's just getting lucky and
will break some other case.