unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nick Roberts <nick@nick.uklinux.net>
Cc: emacs-devel@gnu.org
Subject: Re: gdba probs
Date: Sun, 15 Dec 2002 00:36:02 +0000	[thread overview]
Message-ID: <15867.52850.157380.627084@nick.uklinux.net> (raw)
In-Reply-To: <200212052149.gB5LnZ504967@rum.cs.yale.edu>

Stefan Monnier writes:

 > I have no idea what this entails, but maybe it is related to another
 > wish of mine: to make it usable when running "gdb --fullname foo".
 > Right now, it seems that if gdb is not started with "--annotate=2"
 > gdba just "freezes" (typing stuff at gdb prompt leads nowhere).

I've looked at it now. 

It "freezes" because when a gdb command is typed in the GUD buffer goes onto
the queue (C-h v gdb-input-queue). It goes on the input queue because
gdb-instance-prompting is nil therefore thinks its not ready for
input. gdb-instance-prompting is nil because it hasn't received the prompt
annotation. It hasn't received the prompt annotation because its been called
with "--fullname".

> > > > @@ -2344,6 +2347,42 @@
> > > >  
> > > >  (defun gud-filter (proc string)
> > > >    ;; Here's where the actual buffer insertion is done
> > > > +  (when (and gud-first-time (string-match
> > > > +       "\n\032\032[a-z]" string))
> > > 
> > > What if DBX outputs this same sequence?
> > 
> > You take the patch too literally. It should have something like:
> > 
> > (string-match "\n\032\032pre-prompt\|\n\032\032breakpoints-invalid" string)

> And?  Same thing: some other debugger might use the exact same sequence.
> Better put the test in gud-gdb-marker-filter so there's not ambiguity
> and so the generic part of the code stays cleaner.

I see now that "^Z^Z" is some kind of universal marker, I had thought it was
GDB specific.

> Better put the test in gud-gdb-marker-filter so there's not ambiguity
> and so the generic part of the code stays cleaner.
> ...

It might be easier to approach it from the other end i.e add an annotation
rule for gdb-output-burst to accommodate "--fullname".

> The ultimate goal is to merge M-x gdb and M-x gdba, but it doesn't
> have to be done in a single step.  I think the first step is to make
> sure that both work (maybe with quirks) regardless of whether
> --annotate=2 was used or not.

I think I understand now. I'll go away and think about it.

Miles Bader writes :

> into a separate function to avoid cluttering up gud-filter, something
> like `gdba-take-over-process' or something.  It could even be an
> autoloaded function in gdb-ui.el.
  ^^^^^^^^^^

So gdb-ui.el wouldn't get loaded unless gdb was invoked with annotations, right?
Thats a good point, I hadn't thought of that. 

Nick

  parent reply	other threads:[~2002-12-15  0:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05 20:40 gdba probs Nick Roberts
2002-12-05 21:49 ` Stefan Monnier
2002-12-07  2:38   ` Nick Roberts
2002-12-07  3:10     ` Miles Bader
2002-12-09 15:46     ` Stefan Monnier
2002-12-10 14:19     ` Stefan Monnier
     [not found]       ` <15862.30022.647969.267154@nick.uklinux.net>
     [not found]         ` <200212111411.gBBEBUn03805@rum.cs.yale.edu>
2002-12-11 22:27           ` Nick Roberts
2002-12-11 22:48             ` Stefan Monnier
2002-12-12  0:05               ` Nick Roberts
2002-12-12 13:49                 ` Stefan Monnier
2002-12-12 14:13                   ` Miles Bader
2002-12-13 22:21                 ` Richard Stallman
2002-12-12  1:24             ` Miles Bader
2002-12-12 10:22               ` Kim F. Storm
2002-12-15  0:36   ` Nick Roberts [this message]
2002-12-07 21:25 ` Richard Stallman
2002-12-08  1:55   ` Nick Roberts
2002-12-09 20:21     ` Richard Stallman
2002-12-10 21:39       ` Nick Roberts
2002-12-10 23:44         ` Kim F. Storm
2002-12-11 20:40         ` Richard Stallman
2002-12-08  2:27   ` Miles Bader
2002-12-10 14:14     ` Stefan Monnier
2002-12-11 17:45       ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2002-12-05  6:19 Miles Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15867.52850.157380.627084@nick.uklinux.net \
    --to=nick@nick.uklinux.net \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).