Reporting proper line for breakpoints of non-executable lines (was: Re: RFC: preserve line number when skipping prologue)

["Marc Khouzam" <marc.khouzam@ericsson.com>]

I missed the original thread, I didn't notice the bit
about "GDB reported the real line on which it was inserted"
Please see below.

> On  Thu, 26 Mar 2009 15:49:49 -0700 Joel Brobeckerwrote:
> > If I set a breakpoint on line 3, gdb reports line 7.
> > 
> > (gdb) b 3
> > Breakpoint 1 at 0x80483c5: file m.c, line 7.
> > 
> > But if I set one on line 9, another non-executable line, gdb reports
> > line 9:
> > 
> > (gdb) b 9
> > Breakpoint 2 at 0x80483d1: file m.c, line 9.
> 
> I agree that we need to be consistent between the two cases!
> 
> I don't know which one I prefer, though. Actually, I think I would
> prefer if GDB reported the real line on which it was inserted. But
> that would be a change of behavior from before, and that could
> have ramifications that could potentially annoys the users
> (on the "clear" command, for instance).

I think that from a frontend point-of-view, it would be much nicer
to know where the real breakpoint was inserted.
Right now, in Eclipse CDT, if I set a bp on a non-executable line,
it will show as being set there, but the continue operation will
stop on the next line (or whichever is the first executable line.)
I think that is confusing.

I found a report that GDB did not used to do this dating back to 2003
http://sourceware.org/ml/gdb/2003-08/msg00312.html
but it seems to have died there.

I also noticed that in MI in HEAD, there is a new field to the reply
of break-insert which is "original-location" which was added for a 
different reason
http://sourceware.org/ml/gdb-patches/2008-04/msg00272.html
But I was thinking it would be nice to use that field to show where
the user set the bp, while showing where the bp was really set by
GDB in the other fields.

Do it make sense?

Marc