Re: [RFC/RFA?] Should break FILE:LINENO skip prologue?

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Michael Snyder <msnyder@specifix.com>
> Date: Thu, 10 Jan 2008 13:47:02 -0800
> 
> On Thu, 2008-01-10 at 12:47 +0100, Eric Botcazou wrote:
> > > If generating the right location information for -O0 is too difficult,
> > > perhaps the compiler should make life easier for itself and disable
> > > scheduling instructions into the prologue?
> > 
> > What do you call "scheduling instructions into the prologue" exactly?
> 
> I wouldn't speak for Mark, but personally I could imagine, say, 
> that at -O0 gcc might treat the prologue (whatever we decide
> that means) as an atom, and not allow non-prologue instructions
> to be shuffled into it.
> 
> The next question would be, are automatic variable initializations
> part of that atom?
> 
> I might say that I personally rarely need to debug the "formal"
> prologue (that part that would exist in any (framed/frameless)
> function independent of automatics initialization), and when I
> do, it's as a tools developer, not as an ordinary debugger user.
> Therefore I don't mind having to do something "special".
> 
> But the initializations are another story, especially if they
> require non-trivial stuff like computations or function calls.
> Any user might reasonably want to debug those.  So any change
> that made it difficult for a user to debug those (say by forcing
> him to set a break at the label) would go against the grain
> for me.

I think that the compiler will actually almost never move non-trivial
initializations into the prologue, especially if they involve function
calls.  The prologue is all about putting the origional function
arguments in a safe place, and that needs to be done before you call
other functions that might clobber registers.  So if you have
something like:

int
foo (int i, double d)
{
  int j = 42;
  float f = sin(d);
  ...
}

the first assignment may be scheduled into the prologue, but the
second almost certainly won't.  I don't think anybody will actually
miss the possibility to break on the first assignment.  If we can
somehow ascertain ourselves that indeed we can still put a breakpoint
on the second assignment and have it break before entering sin(), I
think Joels origional diff is actually acceptable.