This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

I think they are permitted, especially if the statements are not
function calls. For instance, the compiler can certainly reverse
the following two statements:

   a = 1;
   b = 2;

I am not versed in the art of optimizing, but why not. I don't think
anything is forbidden as long as the program works as expected.

That being said, the example was just an extreme on meant to show
what it means to chose the line with the smaller number, and why
I prefer to select the first line in your case.

But, like you, I'm not too concerned about which line to select.
In practice, it's not going to happen much.  Even for you, I'm betting
that it's only happen when breaking on "main", because the compiler
should generate that stack re-alignment code only in the main, and
on functions that have special attributes meaning that it might be
called from some code whose stack is less aligned.

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

I can't remember what we do in that case. I'd have to look at
the code again.

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

At least for the part that lines are sorted by ascending PC order,
I'm pretty sure. If we break that assumption, we should fix it,
because I think we rely on it in several places.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]