This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] "fix" a problem where a breakpoint would be associated with the wrong source
- From: Daniel Jacobowitz <drow at false dot org>
- To: PAUL GILLIAM <pgilliam at us dot ibm dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 1 Feb 2006 20:27:33 -0500
- Subject: Re: [RFA] "fix" a problem where a breakpoint would be associated with the wrong source
- References: <1138843590.1423.106.camel@dufur.beaverton.ibm.com>
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