Re: Minor gdb-ui patches to make it a bit more robust

[Stefan Monnier]

>> Here are 2 patches which help me deal with gdb-ui.
>> The first 2 hunks reset gdb-output-sink as it should after starting
>> a new process.  I think this is a plain bug fix, but I'll let
>> Nick decide.

> I don't know why you declare gdb-output-sink with a value of nil as it
> has no meaning but it's harmless.

This variable should really be a process property, so it makes sense for
it to have an invalid value when no process is running.  Setting it to
an invalid default value therefore intends to help catch the case where
we forget to initialize the variable.

> In practice, I've not found a need to reset gdb-output-sink but you
> presumably have.

Indeed.  I think it's pretty easy to get into such a state if you're
edebugging gdba functions and abort them forcefully.

> So I'm happy if you want to make these changes.

Thanks.

>> The second hunk make it fallback on the old gud-gdb code in case the
>> prompt appears before we get to receive the expected annotations.
>> I've been using M-x gdb RET with "gdb --fullname emacs" for ever and it
>> took me a while to understand why it suddenly stopped working properly:
>> the behavior is pretty nasty: you get all the expected GDB output but
>> your input isn't sent to the gdb process (because gdb-ui thinks that
>> GDB is still initializing) and completion just hangs (because it sends
>> a command which isn't passed on to the process and then waits for the
>> process to reply).

> Using the same startup function (M-x gdb) for graphical mode and text command
> mode ("fullname") has given backward compatiblity but caused a lot of grief.

> Previously (Emacs 22.1) M-x gdb assumed text command mode until it received
> annotations to put it in graphical mode.  This led to error reports where
> users wanted graphical mode and had commands in their .gdbinit which started
> execution.  My advice was to use M-x gdba.

> In EMACS_22_BASE, I switched things round so that M-x gdb assumed graphical
> mode until it received a fullname annotation to put it in text command mode.
> This solved the above problem.  I also removed M-x gdba and added M-x gud-gdb.

Yes, I saw that.  You may want to keep the gdba alias, tho.  I do not
disagree with this change.

> More recently, Robert Marshall made a bug report about start up with
> M-x gdb where he entered Gdb user commands before Emacs was ready.
> On the *trunk*, I've solved this by deferring the input rather than
> discarding it.  I also made a couple of other related changes, one of
> which was setting comint-input-sender to gdb-send earlier.  I think
> this change has caused the problem you are seeing.  I've not made this
> change on EMACS_22_BASE, so I think M-x gdb RET with "gdb --fullname
> emacs" will STILL WORK there.

Indeed, the specific problem I encountered is recent.

> On the trunk, I want to migrate away slightly from text command mode so my
> advice there is to use it via M-x gud-gdb now.  I have a patch for gdb-ui.el
> which will mean that M-x gdb will only work in graphical mode and doc changes
> to reflect this which I propose to commit shortly.

That's OK.  But given the reliability problems of gdb-ui, I think it's
crucial that we take a defensive-coding approach there.  I.e. whenever
possible check our assumptions, and not wait for someone to come up with
a counter example before initializing the variables at the right place.

Detecting a (gdb) prompt when we don't expect it is part of
defensive coding.  Maybe falling back automatically to gud-gdb is not
a good idea, but detecting the situation and signalling it to the user
is important.  There might be all kinds of reasons why the user failed
to provide the --annotate=3 argument.

Also I think a good way to make it more reliable would be to make
it work with several gud buffers by moving most global vars to
process properties, so they're necessarily correctly initialized, and
we'd be forced to think a bit harder about what's going on where.


        Stefan


PS: Is there any hope for GDB to accept a command that puts it in
annotate=3 mode, rather than having to tweak the command line for it?
That would solve a lot of those problems.