Re: [8/9] multiple locations

[Nick Roberts <nickrob@snap.net.nz>]

 > > This can break a front end which parses the old output, and this is indeed
 > > the case for Emacs 22.1, which has already been released.
 > 
 > The CLI output was never documented as stable, and using it in frontend
 > is prone to such breakage. 

It still presumably makes sense to avoid such breakage where possible.

 > > Does the (p) add anything useful to the user?  The manual says:
 > > 
 > >       An optional `(p)' suffix marks pending breakpoints
 > > 
 > > Is that not clear from the word PENDING?
 > 
 > No, because if you set breakpoint in a shared library, and that library is
 > unloaded, you have some number in 'address' field, but the breakpoint won't
 > actually fire, and the "(p)" indicates that fact.

OK, but the column you've added this to is "Enb" which refers to whether
the breakpoint is enabled or not.  That is really a yes/no question and
not related to whether the breakpoint is pending.

 > > If it's not needed can we please revert it to the old format?  If it is
 > > needed can we find a format that doesn't break existing parsing?
 > 
 > I personally don't think we should cater for clients that try to use CLI
 > despite that being known as bad idea. 

I think we should generally try to cater for _all_ users of GDB and not
impose requirements on their use of GDB.

 >                                       That said -- do you have any
 > suggestions for an alternative format?

Yes I do.  Instead of:

(gdb) inf bre
Num     Type           Disp Enb  Address    What
1       breakpoint     keep y(p) 0xb7f4ce40 

for an unloaded breakpoint, how about:

(gdb) inf bre
Num     Type                   Disp Enb  Address    What
1       pending breakpoint     keep y    0xb7f4ce40 

which seems the right place to put it, and Emacs will parse this properly
because that's where other breakpoint variants are described, e.g.,


3       hw breakpoint  keep y    0x080485bc in main at myprog.c:75

-- 
Nick                                           http://www.inet.net.nz/~nickrob