Re: GDB 6

Re: GDB 6

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> Given this, I think the next release of GDB should be named ``GDB 6''.

I was hoping that it would be gdb 5.4, and that we would tell
everyone that has 5.3 that it's good for them to upgrade to 5.4.

Guess I'm outvoted.  :)

The last time I compared 5.3 to HEAD was more than a month ago.
HEAD was in pretty good shape then -- better than gdb-5_3-branch
was when it was branched.

I will try to get back to testing and reporting soon, but I can't
promise anything.

Michael C

Re: GDB 6

[Andrew Cagney]

> Andrew Cagney writes:
> 
>> Given this, I think the next release of GDB should be named ``GDB 6''.
> 
> 
> I was hoping that it would be gdb 5.4, and that we would tell
> everyone that has 5.3 that it's good for them to upgrade to 5.4.
> 
> Guess I'm outvoted.  :)

It's all marketing anyway :-)

> The last time I compared 5.3 to HEAD was more than a month ago.
> HEAD was in pretty good shape then -- better than gdb-5_3-branch
> was when it was branched.
> 
> I will try to get back to testing and reporting soon, but I can't
> promise anything.

Mostly yes.

[poor] Kevin keeps finding problems with with the MIPS and the new frame 
code.  I'd suspect a similar situtation with other architectures.  So 
when it works it works well, but when it fails it really goes down - 
typical behavior for a new .0 release :-^

Andrew

Re: GDB 6

[Nick Roberts]

 > Is it possible for you to use the tty command?
 > This is what I do with cgdb.
 > That way you always know if the output is from the inferior or from gdb.

I can only get the tty command work in one direction. That is, I can send
the inferior's output to another terminal/buffer easily enough but I can't
seem to receive its input. I don't really know what a terminal is in
low-level (kernel?) terms so I've not made any progress with this approach.

Nick

Re: GDB 6

[Nick Roberts]

 > Also, do you relize that breakpoint-invalid is buggy?
 > For many versions, gdb will not output breakpoints-invalid when you
 > delete the last breakpoint in the list.
 > 
 > so, 
 > 
 > b main
 > delete main
 > 
 > you will not get a breakpoints-invalid and emacs will still be
 > displaying a breakpoint.

I guess you mean `clear main' or `delete 1'. I've never had this problem. Perhaps
its is version or configuration dependent. For example, I've noticed that Gdb 5.0
configured as mips-sgi-irix6.2 doesn't generate pre-prompt or prompt annotations
but its always worked elsewhere.

Nick

Re: GDB 6

[Bob Rossi]

On Sun, May 11, 2003 at 09:13:20PM +0100, Nick Roberts wrote:
> 
>  > > Here is a revised and reduced list of annotations that I think I could
>  > > work with:
>  > > 
>  > > frames-invalid
>  > > breakpoints-invalid
>  > > pre-prompt
>  > > prompt
>  > > commands
>  > > overload-choice
>  > > query
>  > > prompt-for-continue
>  > > post-prompt
>  > > source
>  > > starting
>  > > exited
>  > > signalled
>  > > signal
>  > > breakpoint
>  > > watchpoint
>  > > frame-begin
>  > > stopped
>  > 
>  > I'm not sure about frame begin.  Things like frames-invalid are events 
>  > and they can stay (forever? ...).
>  > 
> 
> I don't really need frame-begin. The problem that I have, however, is that
> frame-begin (and other annotations) are issued *before* stopped. This meant
> that sometimes Emacs thought that frame details output by Gdb were output by
> the inferior and so they were displayed in the IO buffer. I can only reproduce
> this problem now with tbreak where a typical annotation sequence (avoiding
> many repeats) looks like:
> 
> frames-invalid
> breakpoints-invalid
> starting                <--
> frames-invalid
> breakpoints-invalid
> frame-begin etc         <--
> source
> frame-end
> stopped                 <--
> 

Also, do you relize that breakpoint-invalid is buggy?
For many versions, gdb will not output breakpoints-invalid when you
delete the last breakpoint in the list.

so, 

b main
delete main

you will not get a breakpoints-invalid and emacs will still be
displaying a breakpoint.

Bob Rossi

Re: GDB 6

[Bob Rossi]

On Sun, May 11, 2003 at 09:13:20PM +0100, Nick Roberts wrote:
> 
>  > > Here is a revised and reduced list of annotations that I think I could
>  > > work with:
>  > > 
>  > > frames-invalid
>  > > breakpoints-invalid
>  > > pre-prompt
>  > > prompt
>  > > commands
>  > > overload-choice
>  > > query
>  > > prompt-for-continue
>  > > post-prompt
>  > > source
>  > > starting
>  > > exited
>  > > signalled
>  > > signal
>  > > breakpoint
>  > > watchpoint
>  > > frame-begin
>  > > stopped
>  > 
>  > I'm not sure about frame begin.  Things like frames-invalid are events 
>  > and they can stay (forever? ...).
>  > 
> 
> I don't really need frame-begin. The problem that I have, however, is that
> frame-begin (and other annotations) are issued *before* stopped. This meant
> that sometimes Emacs thought that frame details output by Gdb were output by
> the inferior and so they were displayed in the IO buffer. I can only reproduce
> this problem now with tbreak where a typical annotation sequence (avoiding
> many repeats) looks like:

Is it possible for you to use the tty command?
This is what I do with cgdb.
That way you always know if the output is from the inferior or from gdb.

Bob Rossi

Re: GDB 6

[Nick Roberts]

 > > Here is a revised and reduced list of annotations that I think I could
 > > work with:
 > > 
 > > frames-invalid
 > > breakpoints-invalid
 > > pre-prompt
 > > prompt
 > > commands
 > > overload-choice
 > > query
 > > prompt-for-continue
 > > post-prompt
 > > source
 > > starting
 > > exited
 > > signalled
 > > signal
 > > breakpoint
 > > watchpoint
 > > frame-begin
 > > stopped
 > 
 > I'm not sure about frame begin.  Things like frames-invalid are events 
 > and they can stay (forever? ...).
 > 

I don't really need frame-begin. The problem that I have, however, is that
frame-begin (and other annotations) are issued *before* stopped. This meant
that sometimes Emacs thought that frame details output by Gdb were output by
the inferior and so they were displayed in the IO buffer. I can only reproduce
this problem now with tbreak where a typical annotation sequence (avoiding
many repeats) looks like:

frames-invalid
breakpoints-invalid
starting                <--
frames-invalid
breakpoints-invalid
frame-begin etc         <--
source
frame-end
stopped                 <--

Using break instead of tbreak, the breakpoint annotation is issued before
frame-begin which tells Emacs that output is now from Gdb and not the
inferior.

Before frame-begin is deleted, can Gdb issue another annotation (stopping ?)
prior to printing frame details so that Emacs will always understand that this
is output from Gdb?

Also Emacs doesn't need prompt-for-continue.

Nick

Re: GDB 6

[Andrew Cagney]

> I don't really need frame-begin. The problem that I have, however, is that
> frame-begin (and other annotations) are issued *before* stopped. This meant
> that sometimes Emacs thought that frame details output by Gdb were output by
> the inferior and so they were displayed in the IO buffer. I can only reproduce
> this problem now with tbreak where a typical annotation sequence (avoiding
> many repeats) looks like:
> 
> frames-invalid
> breakpoints-invalid
> starting                <--
> frames-invalid
> breakpoints-invalid
> frame-begin etc         <--
> source
> frame-end
> stopped                 <--

The testsuite now looks like:

(gdb)
^Z^Zprompt
PASS: gdb.base/annota3.exp: breakpoint info
run

^Z^Zpost-prompt
Starting program: 
/home/scratch/PENDING/2003-03-11-ann-3/N-powerpc-unknown-netbs
d1.6/gdb/testsuite/gdb.base/annota3

^Z^Zframes-invalid

^Z^Zframes-invalid

^Z^Zbreakpoints-invalid

^Z^Zstarting

^Z^Zframes-invalid

^Z^Zframes-invalid

^Z^Zframes-invalid

^Z^Zframes-invalid

^Z^Zbreakpoint 1

Breakpoint 1, main () at 
/home/scratch/PENDING/2003-03-11-ann-3/src/gdb/testsuit
e/gdb.base/annota3.c:32

^Z^Zsource 
/home/scratch/PENDING/2003-03-11-ann-3/src/gdb/testsuite/gdb.base/ann
ota3.c:32:323:beg:0x1800bc8

^Z^Zstopped

^Z^Zpre-prompt
(gdb)

Does this help?  You get ^Z^Zbreakpoint 1 when the target hits that 
breakpoint.

> Using break instead of tbreak, the breakpoint annotation is issued before
> frame-begin which tells Emacs that output is now from Gdb and not the
> inferior.

There are other places that could gain events if needed.

> Before frame-begin is deleted, can Gdb issue another annotation (stopping ?)
> prior to printing frame details so that Emacs will always understand that this
> is output from Gdb?
> 
> Also Emacs doesn't need prompt-for-continue.

Ok.

Andrew

Re: GDB 6

[Andrew Cagney]

>> > What exactly do you mean here?
>> > Annotations Level 2 will stay in gdb for version 6.0?
>> > This would truly be a great thing.
> 
> 
> 
>> It won't have been deleted (but it would continue to be on notice).
> 
> 
> Will GDB 6 have annotation level three? The patch that you posted (2003-03-11)
> doesn't appear to have been applied yet.

That's correct.  I've got a small matter of the doco and testsuite to 
resolve :-)

> I might have lost the plot a bit. I initially checked out interps-20030202-branch
> but, after some difficulty, I moved to HEAD and found that things like 
> 
> -interpreter-exec console cli-command
> 
>  and 
> 
> interpreter mi -<mi-command> <mi-args>
> 
> were present there also. Am I in the right place?

Yes.

> In the past you have suggested that (in the fullness of time)
> 
> 
>> The events [annotations] remain (target changed, breakpoint created, ....). 
>> The markups are removed (*-{begin,end})

There was some progress.  Joel added a proper observer.  Next is for the 
breakpoint stuff to use that.

> I've got my head round variable objects and think that they might map on to
> alists and the Emacs speedbar quite well. This means I can avoid the
> annotations that mark up displayed expressions. However, the proposed patch
> also removed some event annotations e.g source, query. I would like these to
> stay. Here is a revised and reduced list of annotations that I think I could
> work with:
> 
> frames-invalid
> breakpoints-invalid
> pre-prompt
> prompt
> commands
> overload-choice
> query
> prompt-for-continue
> post-prompt
> source
> starting
> exited
> signalled
> signal
> breakpoint
> watchpoint
> frame-begin
> stopped

I'm not sure about frame begin.  Things like frames-invalid are events 
and they can stay (forever? ...).

Andrew

Re: GDB 6

[Nick Roberts]

> > What exactly do you mean here?
> > Annotations Level 2 will stay in gdb for version 6.0?
> > This would truly be a great thing.


> It won't have been deleted (but it would continue to be on notice).

Will GDB 6 have annotation level three? The patch that you posted (2003-03-11)
doesn't appear to have been applied yet.

I might have lost the plot a bit. I initially checked out interps-20030202-branch
but, after some difficulty, I moved to HEAD and found that things like 

-interpreter-exec console cli-command

 and 

interpreter mi -<mi-command> <mi-args>

were present there also. Am I in the right place?

In the past you have suggested that (in the fullness of time)

> The events [annotations] remain (target changed, breakpoint created, ....). 
> The markups are removed (*-{begin,end})

I've got my head round variable objects and think that they might map on to
alists and the Emacs speedbar quite well. This means I can avoid the
annotations that mark up displayed expressions. However, the proposed patch
also removed some event annotations e.g source, query. I would like these to
stay. Here is a revised and reduced list of annotations that I think I could
work with:

frames-invalid
breakpoints-invalid
pre-prompt
prompt
commands
overload-choice
query
prompt-for-continue
post-prompt
source
starting
exited
signalled
signal
breakpoint
watchpoint
frame-begin
stopped

Could these stay? (indefinitely?)

Nick

Re: GDB 6

[Andrew Cagney]

> On Fri, May 09, 2003 at 12:58:08PM -0400, Andrew Cagney wrote:
> 
>> The sole objective for GDB 6 was to have GDB multi-arch.  Since Joel has 
>> now committed a change that multi-arch partial's the HP/PA, and all 
>> architectures can be built multi-arch partial, it can be argued that GDB 
>> has technically reached this goal(1).
>> 
>> Given this, I think the next release of GDB should be named ``GDB 6''.
>> 
>> In doing this, there is an oportunity to, identify as obsolete (but not 
>> actually delete) a few extra bits..  The following come to mind:
>> 
>> - non event loop platforms
>> - DWARF (a.k.a., DWARF 1)
>> 
>> People with systems that rely on said features can always download the 
>> GDB 5 series debuggers.
>> 
>> With regard to annotations, someone [me] still still has the 
>> documentation and testsuite to update (....).  That, I think is the only 
>> ``must have'' thing for the next GDB release.  
> 
> 
> What exactly do you mean here?
> Annotations Level 2 will stay in gdb for version 6.0?
> This would truly be a great thing.

It won't have been deleted (but it would continue to be on notice).

Andrew

Re: GDB 6

[Bob Rossi]

On Fri, May 09, 2003 at 12:58:08PM -0400, Andrew Cagney wrote:
> The sole objective for GDB 6 was to have GDB multi-arch.  Since Joel has 
> now committed a change that multi-arch partial's the HP/PA, and all 
> architectures can be built multi-arch partial, it can be argued that GDB 
> has technically reached this goal(1).
> 
> Given this, I think the next release of GDB should be named ``GDB 6''.
> 
> In doing this, there is an oportunity to, identify as obsolete (but not 
> actually delete) a few extra bits..  The following come to mind:
> 
> - non event loop platforms
> - DWARF (a.k.a., DWARF 1)
> 
> People with systems that rely on said features can always download the 
> GDB 5 series debuggers.
> 
> With regard to annotations, someone [me] still still has the 
> documentation and testsuite to update (....).  That, I think is the only 
> ``must have'' thing for the next GDB release.  

What exactly do you mean here?
Annotations Level 2 will stay in gdb for version 6.0?
This would truly be a great thing.

Bob Rossi

Re: GDB 6

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Fri, May 09, 2003 at 12:58:08PM -0400, Andrew Cagney wrote:
 > > The sole objective for GDB 6 was to have GDB multi-arch.  Since Joel has 
 > > now committed a change that multi-arch partial's the HP/PA, and all 
 > > architectures can be built multi-arch partial, it can be argued that GDB 
 > > has technically reached this goal(1).
 > > 
 > > Given this, I think the next release of GDB should be named ``GDB 6''.
 > > 
 > > In doing this, there is an oportunity to, identify as obsolete (but not 
 > > actually delete) a few extra bits..  The following come to mind:
 > > 
 > > - non event loop platforms
 > > - DWARF (a.k.a., DWARF 1)
 > > 
 > > People with systems that rely on said features can always download the 
 > > GDB 5 series debuggers.
 > > 
 > > With regard to annotations, someone [me] still still has the 
 > > documentation and testsuite to update (....).  That, I think is the only 
 > > ``must have'' thing for the next GDB release.  Other things such as NPTL 
 > > et.al. are obvious nice to have (and probably will because more people 
 > > are motivated to get them in :-).
 > > 
 > > Andrew
 > > 
 > > (1) Just ignore the cleanup that will eventually follow, oh and that one 
 > > of the SPARC and HP/PA variants still need some work.
 > 
 > It sounds mighty good to me.
 > 
 > I'd like to see the new dwarf-frame code finished before GDB 6, but it
 > sounds like we'll have (just?) enough time.
 > 

me too! me too!
I think we'll also have objc finished (there is only one last patch pending).
I'll go after DavidC patches for namespaces now....

there are so many new things that we could bump the version number up to 7!

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 6

[Daniel Jacobowitz]

On Fri, May 09, 2003 at 12:58:08PM -0400, Andrew Cagney wrote:
> The sole objective for GDB 6 was to have GDB multi-arch.  Since Joel has 
> now committed a change that multi-arch partial's the HP/PA, and all 
> architectures can be built multi-arch partial, it can be argued that GDB 
> has technically reached this goal(1).
> 
> Given this, I think the next release of GDB should be named ``GDB 6''.
> 
> In doing this, there is an oportunity to, identify as obsolete (but not 
> actually delete) a few extra bits..  The following come to mind:
> 
> - non event loop platforms
> - DWARF (a.k.a., DWARF 1)
> 
> People with systems that rely on said features can always download the 
> GDB 5 series debuggers.
> 
> With regard to annotations, someone [me] still still has the 
> documentation and testsuite to update (....).  That, I think is the only 
> ``must have'' thing for the next GDB release.  Other things such as NPTL 
> et.al. are obvious nice to have (and probably will because more people 
> are motivated to get them in :-).
> 
> Andrew
> 
> (1) Just ignore the cleanup that will eventually follow, oh and that one 
> of the SPARC and HP/PA variants still need some work.

It sounds mighty good to me.

I'd like to see the new dwarf-frame code finished before GDB 6, but it
sounds like we'll have (just?) enough time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

GDB 6

[Andrew Cagney]

The sole objective for GDB 6 was to have GDB multi-arch.  Since Joel has 
now committed a change that multi-arch partial's the HP/PA, and all 
architectures can be built multi-arch partial, it can be argued that GDB 
has technically reached this goal(1).

Given this, I think the next release of GDB should be named ``GDB 6''.

In doing this, there is an oportunity to, identify as obsolete (but not 
actually delete) a few extra bits..  The following come to mind:

- non event loop platforms
- DWARF (a.k.a., DWARF 1)

People with systems that rely on said features can always download the 
GDB 5 series debuggers.

With regard to annotations, someone [me] still still has the 
documentation and testsuite to update (....).  That, I think is the only 
``must have'' thing for the next GDB release.  Other things such as NPTL 
et.al. are obvious nice to have (and probably will because more people 
are motivated to get them in :-).

Andrew

(1) Just ignore the cleanup that will eventually follow, oh and that one 
of the SPARC and HP/PA variants still need some work.