[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC gdb-mi.el changes
From: |
Dan Nicolaescu |
Subject: |
Re: GSoC gdb-mi.el changes |
Date: |
Tue, 11 Aug 2009 07:17:59 -0700 (PDT) |
Dmitry Dzhus <address@hidden> writes:
> Dan Nicolaescu wrote:
>
> > Suggestion: don't show the -i=mi flag, users don't care about it (same
> > way rgrep/lgrep don't show the -n flag they pass to grep)
>
> I'll do this.
>
> > Issues:
> > echo 'int main () { printf ("Hello, World!\n");}' > t.c
> > gcc t.c
> > emacs -Q
> > M-x gdb RET ./a.out RET
> >
> > error in process filter: Symbol's function definition is void: mapcar*
> >
> > M-x load-library RET cl RET
> > M-x gdb RET ./a.out RET
>
> Uh-oh, that's very bad. Somehow I thought that mapcar* is a macro. I'll
> rewrite some of my functions without mapcar* then.
To see more compilation warnings, you can cd to the lisp directory and
do:
make recompile
there. As of today you'll get some extra warnings about using
`goto-line' too.
> >
> > Show the disassembly window
> >
> > b main
> >
> > A warning pops up:
> > &"warning: GDB: Failed to set controlling terminal: Operation not
permitted\n"
How about this warning?
> >
> > si
> > si
> > si
> >
> > The cursor in the disassembly does not move correctly when single
> > stepping and it does not update the stack frames all the time.
>
> (At the time of your writing, stepping was just broken; I installed some
> fixes in CVS.)
Still some problems, given the example above if in the middle of the
execution I do:
r
yes (to restart execution)
I get:
Debugger aborted
the disassembly frame disappears and the debug window does not work anymore.
> Does it occur when you compile your target with -g, too?
It works for the code, but not when going through library functions that
don't have debug info (this worked fine in 22.1).
> Unlike GDB's CLI `disassemble` command, to show disassembly code for you
> program, MI needs to know either file:line information for the function
> you're interested in, or its memory range. For the former your target
> needs to be compiled with debugging information, and for the latter we
> need to query GDB for function memory range, but this command is not
> implemented in GDB/MI yet :(
Given that you know the details here, can you please file a gdb bug?
What do other GDB/MI front-ends do in this situation?