gud.el file/line problems

gud.el file/line problems

[R Reitmaier]

Hi all,

I'm trying to hook up a gdb command-like, custom made
command line debugger to work with gud.

The debugger supports commands that are identical to
gdb and also generates the same output.  I haven't
modified gud.el at all, as I expected that if I keep
the command set identical and the output the same, it
should work seamlessly.

Unfortunately, it does not. I can perform single
stepping, continue, etc without a hitch but for some
reason emacs refuses to display the source file and
the associated => pointer.

I've double checked the output when I hit a breakpoint
and it is identical to gdb, as far as I can tell.
>From my limited understanding of gud, it does a screen
scrape, looking for a "filename:line number", so if I
match the output it should work, right?

I don't know lisp and really wouldn't know where to
begin if I needed to debug gud.el.

I'm hoping that there is something obvious I am doing
or not doing that will correct this problem.

Any ideas, anyone ?!?

Thanks in advance,
Rick

_________________________________________________________________
Need more e-mail storage? Get 10MB with Hotmail Extra Storage.   
http://join.msn.com/?PAGE=features/es

gud.el file/line problems

[Nick Roberts]

 > I'm trying to hook up a gdb command-like, custom made
 > command line debugger to work with gud.
 > 
 > The debugger supports commands that are identical to
 > gdb and also generates the same output.  

Perhaps you could call your debugger, err.. gdb?

 > I haven't modified gud.el at all, as I expected that 
 > if I keep the command set identical and the output the 
 > same, it should work seamlessly.

 > Unfortunately, it does not. I can perform single
 > stepping, continue, etc without a hitch but for some
 > reason emacs refuses to display the source file and
 > the associated => pointer.

You don't say which version of Emacs that you're running but I guess its not
the one in CVS because you would then see that GDB is run with the
"--fullname" option. With this every time gdb stops it generates something
like:

^Z^Z/home/nick/myprog.c:23:209:beg:0x804846c

and gud.el parses out the filename (/home/nick/myprog.c) and the line number
to know where to put the overlay-arrow. I'm guessing that your program doesn't
do this.

 > I've double checked the output when I hit a breakpoint
 > and it is identical to gdb, as far as I can tell.
 > >From my limited understanding of gud, it does a screen
 > scrape, looking for a "filename:line number", so if I
 > match the output it should work, right?

Right. Presumably though, you've not written your program from scratch and
you've made changes that you think improve gdb's behaviour. Why not submit
them to gdb-patches@sources.redhat.com for peer review and to share?

Nick

Re: gud.el file/line problems

[Richard Stallman]

    I'm trying to hook up a gdb command-like, custom made
    command line debugger to work with gud.

What debugger is that?

Re: gud.el file/line problems

[R Reitmaier]

Thanks for the info!

I'll try running gdb with the fullname option and mimic that output, then 
see what happens.

BTW, I'm using WinEmacs 21.3 and just looked more carefully at what is being 
passed to me; sure enough -fullname and -cd are specified.

FYI, I would have liked to port gdb to work with the simulation environment 
my client created, but unfortunately they didn't wish to go that route.  Due 
to other constraints I ended up building something from scratch.  The cli 
front-end I ended up with is significantly stripped down in functionality, 
when compared with gdb and it is really hard-wired for this particular 
simulator, but my client is happy.

- Rick

>From: Nick Roberts <nick@nick.uklinux.net>
>To: "R Reitmaier" <rreitmaier@hotmail.com>
>CC: emacs-devel@gnu.org
>Subject: gud.el file/line problems
>Date: Thu, 11 Sep 2003 18:37:42 +0100
>
>  > I'm trying to hook up a gdb command-like, custom made
>  > command line debugger to work with gud.
>  >
>  > The debugger supports commands that are identical to
>  > gdb and also generates the same output.
>
>Perhaps you could call your debugger, err.. gdb?
>
>  > I haven't modified gud.el at all, as I expected that
>  > if I keep the command set identical and the output the
>  > same, it should work seamlessly.
>
>  > Unfortunately, it does not. I can perform single
>  > stepping, continue, etc without a hitch but for some
>  > reason emacs refuses to display the source file and
>  > the associated => pointer.
>
>You don't say which version of Emacs that you're running but I guess its 
>not
>the one in CVS because you would then see that GDB is run with the
>"--fullname" option. With this every time gdb stops it generates something
>like:
>
>^Z^Z/home/nick/myprog.c:23:209:beg:0x804846c
>
>and gud.el parses out the filename (/home/nick/myprog.c) and the line 
>number
>to know where to put the overlay-arrow. I'm guessing that your program 
>doesn't
>do this.
>
>  > I've double checked the output when I hit a breakpoint
>  > and it is identical to gdb, as far as I can tell.
>  > >From my limited understanding of gud, it does a screen
>  > scrape, looking for a "filename:line number", so if I
>  > match the output it should work, right?
>
>Right. Presumably though, you've not written your program from scratch and
>you've made changes that you think improve gdb's behaviour. Why not submit
>them to gdb-patches@sources.redhat.com for peer review and to share?
>
>Nick

_________________________________________________________________
Get a FREE computer virus scan online from McAfee. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963