Re: [RFA] Fix "break foo" when `foo's prologue ends before line table

Joel Brobecker
2009-05-20T23:07:31Z

> 2009-05-09 Eli Zaretskii <eliz@gnu.org>
>
> * symtab.c (skip_prologue_using_lineinfo): New function.
> (find_function_start_sal): Use it to get to the first line of
> function's body that has an entry in the lineinfo table.

The change looks OK to me, overall. I do have a couple of little
comments, but do feel free to check it in once the comments are
addressed.

> + /* Get the range for the function's PC values, or give up if we
> + cannot, for some reason. */
> + if (!find_pc_partial_function (func_addr, NULL, &func_start, &func_end))
> + return func_addr;
> + l = LINETABLE (symtab);
> + if (l == NULL)
> + return func_addr;

Perhaps you want to check for this before doing the lookup above,
since you have access to the linetable directly. Although, in
practice, we know it should never fail, since the func_addr comes
from a symbol. So we should always find the associated partial
symbol.

> + /* Linetable entries are ordered by PC values, see the commentary in
^^^^^^ comment
> + symtab.h where `struct linetable' is defined. Thus, the first
> + entry whose PC is in the range [FUNC_START..FUNC_END] is the
^^^
You probably want to say [FUNC_START..FUNC_END[, as FUNC_END should
be excluded from the function range. And therefore:

> + the table. See the commentary on symtab.h before the
^^^^^^^^ comment
> + definition of struct linetable. */
> + if (item->line > 0 && func_start <= item->pc && item->pc <= func_end)
^^
I believe that the second comparison should be a strict compare:
item->pc < func_end
> + /* If we still don't have a valid source line, try to find the first
> + PC in the lineinfo table that belongs to the same function. */

That's just a suggestion, but I wouldn't mind if we provided a little
extra explainations about the situation where we have encountered this.
That way, when we later come back to this and try to determine whether
this is still relelvant or not, we'll find a little more context.

Something saying that this can happen if the first line in lineinfo data
for our function starts after the end of the function prologue. This
was observed with DJGPP in a function where the prologue was followed
by some code realigning the stack, before the "real" code started.
The line info for that function started at the beginning of the "real"
code. So, there was no line info available for the instruction after
the prologue. Something like that.

Cheers,
--
Joel