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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 11 May 2009 21:27:09 +0200
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> I'm always reluctant to introduce code I don't understand, and usually
> leave it out until I see a bug - that's why I was asking. Have you
> tried without this part?

No, but I will.  Keep in mind, though, that the program which I was
using as my test case is just a toy test case.  Even if it works
there, I cannot be sure it will work in more complex cases.  I will
take your word for it, though ;-)

>    foo ()
>    {
>      a ();
>      b ();
>    }
> 
> If for some reason the optimizer rearanged the code like this:
> 
>    foo ()
>    {
>      b ();
>      a ();
>    }

Are such rearrangements permitted?  I mean, are we talking about a
real-life situation here?

> Do you really want "break foo" to break on the line where a () is
> called?

It's hard to say, really.  There are arguments for both, but I
personally tend to think that stopping on the call to `a' is what I'd
want.

What do others think?

>                                        In other words, when I break on
> a function, I expect that by the time I reach that function breakpoint,
> none of the real code has been executed yet - I want to debug the
> function :-).

This could be impossible anyway, if the compiler moves some of the
body into the prologue, right?

> > Is it guaranteed that the line table is always sorted by PC?
> 
> Yep:
> 
> /* The order of entries in the linetable is significant.  They should
>    be sorted by increasing values of the pc field.

Well, granted, I've seen that comment.  But (a) are we sure all of our
comments are necessarily accurate to rely on them?, and (b) it
continues to say

                                                If there is more than
   one entry for a given pc, then I'm not sure what should happen (and
   I not sure whether we currently handle it the best way).

Not very reassuring...