This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix "break foo" when `foo's prologue ends before line table
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 11 May 2009 21:20:56 +0300
- Subject: Re: [RFA] Fix "break foo" when `foo's prologue ends before line table
- References: <83skjebbef.fsf@gnu.org> <20090511125644.GD14773@adacore.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Mon, 11 May 2009 14:56:44 +0200
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
>
> Regardless of that, however, we should really look at what
> "break FUNCTION" is supposed to be doing. And looking at the doc,
> it says: ``Specifies the line that begins the body of the function''
> (this matches what I thought it should be doing intuitively).
> So, regardless of what GDB should be doing in terms of prologue
> analysis, I think we should still try to find the first line
> as you're doing in your patch.
Thanks for the feedback. That's two in favor, none against. ;-)
> > + ALL_PSYMTABS (objfile, p)
> > + {
> > + if (FILENAME_CMP (symtab->filename, p->filename) != 0)
> > + continue;
> > + PSYMTAB_TO_SYMTAB (p);
> > + }
> > +
> > + /* Loop over all symtabs for the function's file, looking for an
> > + entry in a lineinfo table whose PC is in the range
> > + [FUNC_START..FUNC_END] and whose line number is the smallest. */
> > + ALL_SYMTABS (objfile, s)
>
> I am wondering if this looping over all PSYMTAB and SYMTABs is really
> necessary. Is the symtab associated to your symbol not sufficient?
I must admit that I have only a very basic knowledge of symbol tables.
In particular, I'm only vaguely familiar with the possible intricacies
of symtabs in the presence of included files and such likes. I simply
saw that find_line_symtab, which does a similar job, loops like that,
so I used the same paradigm.
> Also, instead of returning the line whose number is the smallest,
> I would return the smallest PC, as we're trying to skip the minimum
> before inserting the breakpoint.
But the smallest PC could come from some source line that is further
down in the function's body, source-wise, if the compiler rearranged
code, couldn't it? What I'm trying to do is find the first source
line of the body of the function, not the first PC of the body. I
think the former is more in line with the semantics of "break FOO".
> This means that your iteration on the line table can stop as soon as
> you've found a non-zero line that's inside your function address
> range.
Is it guaranteed that the line table is always sorted by PC?