gdb-ui can't handle mutiple debugging sessions

gdb-ui can't handle mutiple debugging sessions

[Andreas Schwab]

When trying to use two debugging sessions at the same time gdb-ui gets
completely confused.  As soon as I start the second session all input is
sent to it, even when typed in the window of the first session.  This is a
serious regression compared the old interface.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb-ui can't handle mutiple debugging sessions

[Nick Roberts]

> When trying to use two debugging sessions at the same time gdb-ui gets
> completely confused.  As soon as I start the second session all input is
> sent to it, even when typed in the window of the first session.  This is a
> serious regression compared the old interface.

Thats right, gdb-ui can only handle one debugging session at a time. Trying
to run more seemed to require the code to be a lot more complex and
at the time only one overlay arrow was available so, in any case the old
interface didn't do it very well. I have always found the best way to run
two
debugging sessions at the same time is to run two versions of Emacs.
Whats the problem with this approach?

I don't see this as a serious regression and so far no-one else appears to
(gdb-ui has been in CVS Emacs for almost two years now). If you
can convince me otherwise or if others agree with you I will look at
adding support for multiple sessions. However, I think this would be a
major task which I could not complete till after the next release.

Nick

Re: gdb-ui can't handle mutiple debugging sessions

[Stefan]

>> When trying to use two debugging sessions at the same time gdb-ui gets
>> completely confused.  As soon as I start the second session all input is
>> sent to it, even when typed in the window of the first session.  This is a
>> serious regression compared the old interface.

> Thats right, gdb-ui can only handle one debugging session at a time. Trying
> to run more seemed to require the code to be a lot more complex and
> at the time only one overlay arrow was available so, in any case the old
> interface didn't do it very well. I have always found the best way to run
> two
> debugging sessions at the same time is to run two versions of Emacs.
> Whats the problem with this approach?

> I don't see this as a serious regression and so far no-one else appears to
> (gdb-ui has been in CVS Emacs for almost two years now). If you
> can convince me otherwise or if others agree with you I will look at
> adding support for multiple sessions. However, I think this would be a
> major task which I could not complete till after the next release.

Do multiple sessions still work (at least as well as before) if you use
`gdb --fullname'?

What's the source of difficulty in supporting multiple sesions with gdb-ui?
My experience in removing the "only one per Emacs process" limitation of
various special modes (such as pcl-cvs) is that it's usually not that hard,
only it requires care (basically: make all the relevant variables
buffer-local in the main buffer and be careful to always select the main
buffer before reading those vars).

In Emacs-21.3, the multiple-session support in gud.el is pretty fragile:
it only works if all the GUD sessions use the same backend (i.e. all gdb,
or all dbx, or all perldb).  That should be added to the TODO (which should
have a KNOWN-BUGS section).



        Stefan

Re: gdb-ui can't handle mutiple debugging sessions

[Andreas Schwab]

Stefan <monnier@iro.umontreal.ca> writes:

>>> When trying to use two debugging sessions at the same time gdb-ui gets
>>> completely confused.  As soon as I start the second session all input is
>>> sent to it, even when typed in the window of the first session.  This is a
>>> serious regression compared the old interface.
>
>> Thats right, gdb-ui can only handle one debugging session at a time. Trying
>> to run more seemed to require the code to be a lot more complex and
>> at the time only one overlay arrow was available so, in any case the old
>> interface didn't do it very well. I have always found the best way to run
>> two
>> debugging sessions at the same time is to run two versions of Emacs.
>> Whats the problem with this approach?

I do all my work in a single Emacs session.  Having to start a new
instance would mean not being able to share buffers and various history
lists, for example.

> Do multiple sessions still work (at least as well as before) if you use
> `gdb --fullname'?

Multiple sessions with --fullname also have some limitations, but they are
easily understood.  For example, trying to set a breakpoint in a source
file with C-x a SPC will send the command to the last active session,
which is usually what you want, but not always.  In general, it works
quite well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb-ui can't handle mutiple debugging sessions

[Miles Bader]

On Mon, Sep 13, 2004 at 01:32:57AM +0200, Andreas Schwab wrote:
> >> I have always found the best way to run two debugging sessions at the
> >> same time is to run two versions of Emacs.  Whats the problem with this
> >> approach?
> 
> I do all my work in a single Emacs session.  Having to start a new
> instance would mean not being able to share buffers and various history
> lists, for example.

Yes.  Requiring multiple emacs sessions is as best a poor workaround for
grotty code; sometimes it's a necessary for whatever reason, but it's almost
never desirable.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: gdb-ui can't handle mutiple debugging sessions

[Stefan]

>> Do multiple sessions still work (at least as well as before) if you use
>> `gdb --fullname'?

> Multiple sessions with --fullname also have some limitations, but they are
> easily understood.

Well, I'm not sure you're answering my question: do they *still* work?
I.e. as long as you use `gdb --fullname', Emacs-CVS works just as well as
Emacs-21.3?

> For example, trying to set a breakpoint in a source file with C-x a SPC
> will send the command to the last active session, which is usually what
> you want, but not always.  In general, it works quite well.

Yes, it has many problems, but these are not new: it is important (to me at
least) to distinguish "regressions", from "lack of improvement".

As for the specific example you mention, I'd be interested to hear your
suggestions for how GUD should handle it (I don't have much experience with
such situations, so it's difficult for me to know what would be best).


        Stefan

Re: gdb-ui can't handle mutiple debugging sessions

[Nick Roberts]

> Do multiple sessions still work (at least as well as before) if you use
> `gdb --fullname'?

gdb -fullname *should* work as before in all respects but I won't be able to
check anything for another couple of weeks.

> What's the source of difficulty in supporting multiple sesions with
gdb-ui?
> My experience in removing the "only one per Emacs process" limitation of
> various special modes (such as pcl-cvs) is that it's usually not that
hard,
> only it requires care (basically: make all the relevant variables
> buffer-local in the main buffer and be careful to always select the main
> buffer before reading those vars).

The original code (gdba.el) did have buffer-local variables although I'm
not sure that multiple sessions worked. Since the mode has multiple
windows/frames for a single session I decided it was best to make
the variables global for cleaner code. Given the difficulty that I've had
controlling the display of  the appropriate windows/frames just for
a single session, I still don't think that was a bad decision.

> In Emacs-21.3, the multiple-session support in gud.el is pretty fragile:
> it only works if all the GUD sessions use the same backend (i.e. all gdb,
> or all dbx, or all perldb).  That should be added to the TODO (which
should
> have a KNOWN-BUGS section).

How often would people need that kind of support?

gdb-ui needs feedback from a wider audience to find out which features are
important. Eventually it has to be replaced by a mode that uses GDB's
Machine Interface (MI) so it is really interim code.. When I started I just
didn't realise that a release would take so long.

Nick

Re: gdb-ui can't handle mutiple debugging sessions

[Kenichi Handa]

In article <001101c499fa$f5fba540$949260cb@h>, Nick Roberts <nickrob@gnu.org> writes:

> gdb-ui needs feedback from a wider audience to find out which features are
> important.

I'm writing a C library.  I also wrote several programs that
use that library to test it.  So, it's important for me to
use a single Emacs session to run those test programs under
multiple gdb sessions.  In that situation, when I want to
set a breakpoint in some file of the library by C-x SPC, its
usually for a gdb buffer that I visited most recently.
Otherwise, I'd like to type C-u C-x SPC and expect Emacs to
ask me for which gdb buffer to set the break point.

---
Ken'ichi HANDA
handa@m17n.org

Re: gdb-ui can't handle mutiple debugging sessions

[Nick Roberts]

> I'm writing a C library.  I also wrote several programs that
> use that library to test it.  So, it's important for me to
> use a single Emacs session to run those test programs under
> multiple gdb sessions...  

Why can't you test the library with your programs in a serial fashion?
Do you really need to start the second test before finishing the first?
(I'm sure you do, but I'm just trying to understand how and when the
need arises)

>                              ...In that situation, when I want to
> set a breakpoint in some file of the library by C-x SPC, its
> usually for a gdb buffer that I visited most recently.
> Otherwise, I'd like to type C-u C-x SPC and expect Emacs to
> ask me for which gdb buffer to set the break point.

Perhaps we could implement that behaviour for 'gdb -fullname'
(assuming it doesn't already have it).

Nick

Re: gdb-ui can't handle mutiple debugging sessions

[Kenichi Handa]

In article <000401c49ad5$e94a78e0$bc9260cb@h>, Nick Roberts <nickrob@gnu.org> writes:
>>  I'm writing a C library.  I also wrote several programs that
>>  use that library to test it.  So, it's important for me to
>>  use a single Emacs session to run those test programs under
>>  multiple gdb sessions...  

> Why can't you test the library with your programs in a serial fashion?
> Do you really need to start the second test before finishing the first?

Because I must confirm that a bug fix for test 2 doesn't
break test 1.

---
Ken'ichi HANDA
handa@m17n.org

RE: gdb-ui can't handle mutiple debugging sessions

[Zoltan Kemenczy]

Another example where multiple debugging sessions are used is concurrent java / c debugging.

In this case a java application (debuggee 1) at some point loads one of the native code extensions (shared library, DLL (debugee 2).  The trouble here is that, because the native code runs from a shared library, one has to stop the java application just after the DLL had been loaded (jdb), and then attach to the native code process using gdb to set breakpoints.  While debugging the native code, the jdb session is active and waiting for the native code to return control...  This can't be performed in a serial fashion.

Regards,
Zoltan Kemenczy

> Message: 4
> Date: Wed, 15 Sep 2004 13:10:06 +0900 (JST)
> From: Kenichi Handa <handa@m17n.org>
> Subject: Re: gdb-ui can't handle mutiple debugging sessions
> To: nickrob@gnu.org
> Cc: schwab@suse.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Message-ID: <200409150410.NAA16483@etlken.m17n.org>
> Content-Type: text/plain; charset=US-ASCII
> 
> In article <000401c49ad5$e94a78e0$bc9260cb@h>, Nick Roberts 
> <nickrob@gnu.org> writes:
> >>  I'm writing a C library.  I also wrote several programs that
> >>  use that library to test it.  So, it's important for me to
> >>  use a single Emacs session to run those test programs under
> >>  multiple gdb sessions...  
> 
> > Why can't you test the library with your programs in a 
> serial fashion?
> > Do you really need to start the second test before 
> finishing the first?
> 
> Because I must confirm that a bug fix for test 2 doesn't
> break test 1.
> 
> ---
> Ken'ichi HANDA
> handa@m17n.org
> 

RE: gdb-ui can't handle mutiple debugging sessions

[Nick Roberts]

> Another example where multiple debugging sessions are used is concurrent
java / c debugging.

> In this case a java application (debuggee 1) at some point loads one of
the native code extensions (shared
> library, DLL (debugee 2).  The trouble here is that, because the native
code runs from a shared library, one
> has to stop the java application just after the DLL had been loaded (jdb),
and then attach to the native code
> process using gdb to set breakpoints.  While debugging the native code,
the jdb session is active and
> waiting for the native code to return control...  This can't be performed
in a serial fashion.

Can you currently do this with 'gdb -fullname' in CVS Emacs
or with Emacs 21.3 with 'M-x gdb' (which also uses -fullname)?

Nick

RE: gdb-ui can't handle mutiple debugging sessions

[Zoltan Kemenczy]

Yes. For the java application I used M-x jdb with the default 'jdb -attach javadebug' parameters, and M-x gdb used 'gbd -fullname' (the 'attach' and 'dll' gdb commands are used subsequently in the *gud* buffer to specify the dll file and process id).
I was able to do this with emacs-CVS and and emacs-21.3.
Zoltan
> -----Original Message-----
> From: Nick Roberts [mailto:nickrob@gnu.org]
> Sent: September 15, 2004 5:08 PM
> To: Zoltan Kemenczy
> Cc: emacs-devel@gnu.org
> Subject: RE: gdb-ui can't handle mutiple debugging sessions
> 
> 
> > Another example where multiple debugging sessions are used 
> is concurrent
> java / c debugging.
> 
> > In this case a java application (debuggee 1) at some point 
> loads one of
> the native code extensions (shared
> > library, DLL (debugee 2).  The trouble here is that, 
> because the native
> code runs from a shared library, one
> > has to stop the java application just after the DLL had 
> been loaded (jdb),
> and then attach to the native code
> > process using gdb to set breakpoints.  While debugging the 
> native code,
> the jdb session is active and
> > waiting for the native code to return control...  This 
> can't be performed
> in a serial fashion.
> 
> Can you currently do this with 'gdb -fullname' in CVS Emacs
> or with Emacs 21.3 with 'M-x gdb' (which also uses -fullname)?
> 
> Nick
> 
> 
> 

Re: gdb-ui can't handle mutiple debugging sessions

[Stefan Monnier]

> Yes. For the java application I used M-x jdb with the default 'jdb -attach
> javadebug' parameters, and M-x gdb used 'gbd -fullname' (the 'attach' and
> 'dll' gdb commands are used subsequently in the *gud* buffer to specify
> the dll file and process id).
> I was able to do this with emacs-CVS and and emacs-21.3.

And after the M-x gdb step, have you noticed any problems in the jdb buffer?


        Stefan

RE: gdb-ui can't handle mutiple debugging sessions

[Zoltan Kemenczy]

No.  And my emacs is a snapshot from CVS on Sep 1, built using mingw (not cygwin).

Ofcourse, jdb (in *gud-javadebug*) is 'dead' while I'm e.g single-stepping native (C) code (as expected), and as soon as I do 'cont' in gdb (in *gud*), my *gud-javadebug* gets control back...

What kind of problems should I be looking for? I am not using gdb-ui in any way during the above.
My original email was just to point out a need for supporting multiple gud session within emacs...

Zoltan

P.S.: It took me a while to 'dust'-off the java/native c code application.  Loading native dlls built with later cygwin gccs (starting at version 3.3.1) fails with JDK 1.4.2, so I had to go back to gcc 3.2 prerelease which still works with this JDK.

> -----Original Message-----
> From: Stefan Monnier [mailto:monnier@iro.umontreal.ca]
> Sent: September 15, 2004 6:17 PM
> To: Zoltan Kemenczy
> Cc: Nick Roberts; emacs-devel@gnu.org
> Subject: Re: gdb-ui can't handle mutiple debugging sessions
> 
> 
> > Yes. For the java application I used M-x jdb with the 
> default 'jdb -attach
> > javadebug' parameters, and M-x gdb used 'gbd -fullname' 
> (the 'attach' and
> > 'dll' gdb commands are used subsequently in the *gud* 
> buffer to specify
> > the dll file and process id).
> > I was able to do this with emacs-CVS and and emacs-21.3.
> 
> And after the M-x gdb step, have you noticed any problems in 
> the jdb buffer?
> 
> 
>         Stefan
> 

Re: gdb-ui can't handle mutiple debugging sessions

[Stefan]

> What kind of problems should I be looking for? I am not using gdb-ui in
> any way during the above.

You don't have to look for anything in particular, I was just asking what
was your experience.  IIRC there are still known problems with shortcuts
like C-c C-n and C-x SPC and such (i.e. same thing if you use the menubar to
activate such GUD commands) which will send gdb-format commands (even to
a jdb subprocess) after you did M-x gdb.

> My original email was just to point out a need for supporting multiple gud
> session within Emacs...

Which I think we all agree on.


        Stefan

Re: gdb-ui can't handle mutiple debugging sessions

[Nick Roberts]

> > My original email was just to point out a need for supporting multiple
gud
> > session within Emacs...
>
> Which I think we all agree on.

For now then, I suggest documenting in the info manual that this currently
requires 'gdb -fullname'. I will do this when I can access the repository
again.

Nick