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

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

[PAUL GILLIAM]

I ran across a problem where a breakpoint would be associated with the
wrong source.  Not every breakpoint, just some breakpoints.  And
changing the order of .o files on the link line would change which
breakpoints where affected.

A 'bad' breakpoint would give the wrong source file and line number when
it was set.  When the program was run and a bad breakpoint hit, the
wrong source would be shown by the break and by list.  But the break
would, in fact, be at the right place.

In debugging gdb, I narrowed it down (not the cause, just the failure)
to find_function_start_sal().  The call to find_pc_sect_line() was
finding the wrong sal.  I noticed that the right sal was being found
earlier during the processing done by SKIP_PROLOGUE().  There,
find_pc_sect_line() was being called with a null section argument.

This patch seems to "fix" the problem.  But I don't feel comfortable
with it.

Comments?

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.146
diff -a -u -r1.146 symtab.c
--- symtab.c    17 Dec 2005 22:34:03 -0000      1.146
+++ symtab.c    2 Feb 2006 00:57:52 -0000
@@ -2457,7 +2457,7 @@
       /* For overlays, map pc back into its mapped VMA range */
       pc = overlay_mapped_address (pc, section);
     }
-  sal = find_pc_sect_line (pc, SYMBOL_BFD_SECTION (sym), 0);
+  sal = find_pc_sect_line (pc, 0, 0);

   /* Check if SKIP_PROLOGUE left us in mid-line, and the next
      line is still part of the same function.  */
~

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

[Daniel Jacobowitz]

On Wed, Feb 01, 2006 at 05:26:30PM -0800, PAUL GILLIAM wrote:
> I ran across a problem where a breakpoint would be associated with the
> wrong source.  Not every breakpoint, just some breakpoints.  And
> changing the order of .o files on the link line would change which
> breakpoints where affected.
> 
> A 'bad' breakpoint would give the wrong source file and line number when
> it was set.  When the program was run and a bad breakpoint hit, the
> wrong source would be shown by the break and by list.  But the break
> would, in fact, be at the right place.
> 
> In debugging gdb, I narrowed it down (not the cause, just the failure)
> to find_function_start_sal().  The call to find_pc_sect_line() was
> finding the wrong sal.  I noticed that the right sal was being found
> earlier during the processing done by SKIP_PROLOGUE().  There,
> find_pc_sect_line() was being called with a null section argument.
> 
> This patch seems to "fix" the problem.  But I don't feel comfortable
> with it.
> 
> Comments?

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?

-- 
Daniel Jacobowitz
CodeSourcery

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

[PAUL GILLIAM]

[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]

On Wed, 2006-02-01 at 20:27 -0500, Daniel Jacobowitz wrote:
> On Wed, Feb 01, 2006 at 05:26:30PM -0800, PAUL GILLIAM wrote:
> > I ran across a problem where a breakpoint would be associated with the
> > wrong source.  Not every breakpoint, just some breakpoints.  And
> > changing the order of .o files on the link line would change which
> > breakpoints where affected.
> > 
> > A 'bad' breakpoint would give the wrong source file and line number when
> > it was set.  When the program was run and a bad breakpoint hit, the
> > wrong source would be shown by the break and by list.  But the break
> > would, in fact, be at the right place.
> > 
> > In debugging gdb, I narrowed it down (not the cause, just the failure)
> > to find_function_start_sal().  The call to find_pc_sect_line() was
> > finding the wrong sal.  I noticed that the right sal was being found
> > earlier during the processing done by SKIP_PROLOGUE().  There,
> > find_pc_sect_line() was being called with a null section argument.
> > 
> > This patch seems to "fix" the problem.  But I don't feel comfortable
> > with it.
> > 
> > Comments?
> 
> 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?
> 

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.

Next, we look at all the partial symbol tables.  If we find one, we want
to make sure it's the best, so we scan the rest, starting with the one
we found.

But before we scan the rest of the partial symbol tables, we have to
pass a couple of tests first.

This patch removes the second of those tests which, in effect, said "If
we didn't find a minimal symbol, then go with the first partial symbol
table we found.'

In the loop that scans the rest of the partial symbol tables, there is a
"stop scanning now if we have a partial symbol that is an exact match
for the minimal symbol we found earlier".  This had to be altered so the
test is only made if we *did* find a minimal symbol.

What I am asking is why is the minimal symbol test I removed needed?
Hopefully, the answer will help me understand the real cause of my bug.

Thanks for all your help,

-=# Paul #=-

 

[-- Attachment #2: hope.patch --]
[-- Type: text/x-patch, Size: 1017 bytes --]

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.146
diff -a -u -r1.146 symtab.c
--- symtab.c	17 Dec 2005 22:34:03 -0000	1.146
+++ symtab.c	10 Feb 2006 01:39:41 -0000
@@ -746,9 +746,6 @@
 	    section == 0)	/* can't validate section this way */
 	  return (pst);
 
-	if (msymbol == NULL)
-	  return (pst);
-
 	/* The code range of partial symtabs sometimes overlap, so, in
 	   the loop below, we need to check all partial symtabs and
 	   find the one that fits better for the given PC address. We
@@ -763,10 +760,14 @@
 		struct partial_symbol *p;
 
 		p = find_pc_sect_psymbol (tpst, pc, section);
+
 		if (p != NULL
+                    && msymbol != NULL
 		    && SYMBOL_VALUE_ADDRESS (p)
 		    == SYMBOL_VALUE_ADDRESS (msymbol))
+                  /* Return early if we found an exact match in the msymtab. */
 		  return (tpst);
+
 		if (p != NULL)
 		  {
 		    /* We found a symbol in this partial symtab which

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

[Daniel Jacobowitz]

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.


-- 
Daniel Jacobowitz
CodeSourcery

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

[PAUL GILLIAM]

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 #=-

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

[Daniel Jacobowitz]

On Mon, Feb 13, 2006 at 07:27:08PM -0800, PAUL GILLIAM wrote:
> 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.

We've got lots of hacks thrown around to try to make this case work. 
It might be possible to add another to fix your variant.  But, it
sounds like recording discrete range information would be a better
idea.

-- 
Daniel Jacobowitz
CodeSourcery