Re: [PATCH , all targets] Fix order of prologue instructions for varargs functions with -O0 and -m32

[Luis Machado <luisgpm at linux dot vnet dot ibm dot com>]

Hi,

On Sun, 2009-03-01 at 21:11 +0000, Dave Korn wrote:
> Daniel Jacobowitz wrote:
> > On Sat, Feb 28, 2009 at 10:46:50AM +0000, Dave Korn wrote:
> >>> 2 - GDB stops right after the branch, due to an additional line number
> >>> entry that is (forcibly) generated because GCC saw a different Basic
> >>> Block.
> >>   Ah.  I wonder if there's an implicit assumption in GDB that the prologue is
> >> only a single basic block?
> > 
> > Irrelevant, but it has to be a single "line".  That's how prologue
> > analysis has worked in GDB for probably 20 years.  It's improved a lot
> > in that time, but the basic assumption remains.
> > 
> >>   Hmm, but shouldn't GDB really be paying attention to the information it
> >> receives from RTX_FRAME_RELATED_P?
> > 
> > GDB does not receive this information.
> > 
> 
>   Ok, so I guess Luis' suggestion:
> 
> Luis Machado wrote:
> 
> > The other way around this problem, without changing the ordering of
> > instructions in more general code is to omit the output of that
> > additional Line Number Entry. Does it sound like a better solution for
> > mainline?
> 
> ... must be the right thing to do.
> 
>     cheers,
>       DaveK

Considering this path, would it be a bad idea to output a new line
number entry just when the line number changes?

This way, even though we're forcing GCC to emit a new line number, if
the line number is the same, we'll hold back on doing so.

I have this working with a condition change on
final.c:notice_source_line, but wanted to have some input on how
acceptable this is. Am i overlooking something here?

Regards,
Luis