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

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

[-- 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