other weird gdb-mi problems

other weird gdb-mi problems

[Miles Bader]

I'm debugging a program, which segfaulted (I think due to stack
overflow); here's the top of the stack:

   (gdb) fr 0
   #0  0x083718ee in IpLoc::shares_outermost_container (this=0x84eb8fc, 
       var=0x84eb894) at IpLoc.h:1021
   1021		  return oc1 == oc2;
   (gdb) ba 5
   #0  0x083718ee in IpLoc::shares_outermost_container (this=0x84eb8fc, 
       var=0x84eb894) at IpLoc.h:1021
   #1  0x08371994 in IpLoc::contains (this=0x84eb8fc, var=0x84eb894)
       at IpLoc.h:1048
   #2  0x0836eb31 in IpLoc::innermost_container (this=0x84eb894, 
       within=0x84e95a4) at IpLoc.cpp:825
   #3  0x08372232 in IpLoc::innermost_container (this=0x84eb894, 
       within=0x84e95a4) at IpLoc.h:803
   #4  0x0836ed94 in print_member_name (cont=0x84e95a4, var=0x84eb894, os=...)
       at IpLoc.cpp:849

Now, let's try moving up the stack:

   (gdb) up
   #1  0x08371994 in IpLoc::contains (this=0x84eb8fc, var=0x84eb894)
       at IpLoc.h:1048
   1048		    && _oc_start <= var->_oc_start && _oc_end >= var->_oc_end);

(**** BUG 1) The transcript output looks ok -- but the source code
window displays the source file/location for frame 0, not for the
current frame!

Now let's try moving to deeper stack frames, using the "up" command:

   (gdb) up
   #1  0x08371994 in IpLoc::contains (this=0x84eb8fc, var=0x84eb894)
       at IpLoc.h:1048
   1048		    && _oc_start <= var->_oc_start && _oc_end >= var->_oc_end);
   (gdb) up
   #1  0x08371994 in IpLoc::contains (this=0x84eb8fc, var=0x84eb894)
       at IpLoc.h:1048
   1048		    && _oc_start <= var->_oc_start && _oc_end >= var->_oc_end);

... wait a minute... why am I still at frame 1?!
"down" is similarly weird:

   (gdb) down
   Bottom (innermost) frame selected; you cannot go down.

 (**** BUG 2) Basically, the "up" and "down" commands seem to always
start from frame 0, not from the current frame.  I can move to a given
frame using "frame N", but that's pretty annoying.  [The source code
window always shows a display for frame 0, no matter what frame is
printed in the transcript windows.]

That's all for now... :)

Thanks,

-Miles

-- 
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.

Re: other weird gdb-mi problems

[Eli Zaretskii]

> From: Miles Bader <miles.bader@necel.com>
> Date: Wed, 26 Aug 2009 16:49:10 +0900
> 
> Now let's try moving to deeper stack frames, using the "up" command:
> 
>    (gdb) up
>    #1  0x08371994 in IpLoc::contains (this=0x84eb8fc, var=0x84eb894)
>        at IpLoc.h:1048
>    1048		    && _oc_start <= var->_oc_start && _oc_end >= var->_oc_end);
>    (gdb) up
>    #1  0x08371994 in IpLoc::contains (this=0x84eb8fc, var=0x84eb894)
>        at IpLoc.h:1048
>    1048		    && _oc_start <= var->_oc_start && _oc_end >= var->_oc_end);
> 
> ... wait a minute... why am I still at frame 1?!
> "down" is similarly weird:
> 
>    (gdb) down
>    Bottom (innermost) frame selected; you cannot go down.

Does this work correctly outside Emacs?  (Sorry for asking such
obvious questions, but I thought it could be some genuine GDB problem
with inlined functions.)

Re: other weird gdb-mi problems

[Nick Roberts]

 > > ... wait a minute... why am I still at frame 1?!
 > > "down" is similarly weird:
 > > 
 > >    (gdb) down
 > >    Bottom (innermost) frame selected; you cannot go down.
 > 
 > Does this work correctly outside Emacs?  (Sorry for asking such
 > obvious questions, but I thought it could be some genuine GDB problem
 > with inlined functions.)

It's an Emacs problem.  The CLI commands "up" and "down", don't emit any
GDB/MI notifications so Emacs doen't know that the display needs updating.  It
could check the selected frame after every command but that seems inefficient.
I have proposed using notifications for changes in state in the past on the
GDB mailing list, e.g.,
http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html but there hasn't
been much interest.  I think this is because many frontends don't use a
console like the GUD buffer.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: other weird gdb-mi problems

[Miles Bader]

nickrob@snap.net.nz (Nick Roberts) writes:
> It's an Emacs problem.  The CLI commands "up" and "down", don't emit any
> GDB/MI notifications so Emacs doen't know that the display needs updating.  It
> could check the selected frame after every command but that seems inefficient.
> I have proposed using notifications for changes in state in the past on the
> GDB mailing list, e.g.,
> http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html but there hasn't
> been much interest.

hmm, if MI is supposed to be a useful interface, isn't gdb not giving
notice of its state changes a bug with gdb too?

> I think this is because many frontends don't use a
> console like the GUD buffer.

Argh, the mouth-breathers strike again ... :(

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: other weird gdb-mi problems

[Miles Bader]

p.s. What about emacs showing the wrong source file?

Thanks,

-miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.

Re: other weird gdb-mi problems

[Nick Roberts]

 > p.s. What about emacs showing the wrong source file?

Actually, I take back what I said earlier.  Previously, "-stack-info-frame"
was actually used to query for the current frame but I see now that after
Dmitry's changes it now gets sent as, e.g.,

        "-stack-info-frame --thread 1 -frame --0"

which resets the frame.  The change below seems to fix this for the problem
you reported with "up" and "down" by just specifying the thread,

        "-stack-info-frame --thread 1"

but this might breaks things in a multi-threaded situation where Emacs might
want send a GDB command that operates on a different frame to the selected
one.

Dmitry, what do you think?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** gdb-mi.el.~1.36.~	2009-08-25 09:58:16.000000000 +1200
--- gdb-mi.el	2009-08-27 16:35:02.000000000 +1200
*************** then no --frame option is added."
*** 1605,1614 ****
    ;; gdb-frame-number may be nil while gdb-thread-number is non-nil
    ;; (when current thread is running)
    (if gdb-thread-number
!       (concat command " --thread " gdb-thread-number
!               (if (not (or noframe (not gdb-frame-number)))
!                   (concat " --frame " gdb-frame-number) "")
!               " ")
      command))
  
  (defun gdb-current-context-buffer-name (name)
--- 1605,1611 ----
    ;; gdb-frame-number may be nil while gdb-thread-number is non-nil
    ;; (when current thread is running)
    (if gdb-thread-number
!       (concat command " --thread " gdb-thread-number)
      command))
  
  (defun gdb-current-context-buffer-name (name)

Re: other weird gdb-mi problems

[Miles Bader]

nickrob@snap.net.nz (Nick Roberts) writes:
>  > p.s. What about emacs showing the wrong source file?
>
> which resets the frame.  The change below seems to fix this for the problem
> you reported with "up" and "down" by just specifying the thread,

Thanks, that patch fixes both problems for me.

BTW, a few other things I noticed while testing that:

 (1) Calling a program function from gdb to display various info; these
     no longer seems to work.

     E.g. if I do:  "call dump_loc(SOME_VAR)"
     where the "dump_loc" function just prints some stuff about SOME_VAR
     to stdout (and then flushes stdout).  In previous versions of gdb
     this worked great, but now it doesn't.

     This is actually kinda important, because it's a very commonly
     used technique to add gdb debugging hooks into programs...

     I thought maybe this had something to do with the
     "*input/output ...*" buffer which is now getting used, but the
     output didn't show up there either.


 (2) It display breakpoint icon in the margin, instead of in the
     fringe, if I have the "fringe-style" set to `half'.

     I guess maybe it's trying to ensure that the icon it fits in the
     space available, and indeed, there's like a single pixel chopped
     off one edge if I force it (by setting half-margin-mode _after_
     setting the breakpoint).

     However, having the margins are much more annoying than slightly
     truncated icons (especially since the icon is essentially, a red
     blob), so it would be nice if it were less eager about doing this,
     or tried to substitute a smaller icon in such a case, or something.

Thanks,

-Miles

-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]

Re: other weird gdb-mi problems

[Nick Roberts]

 >  (1) Calling a program function from gdb to display various info; these
 >      no longer seems to work.
 > 
 >      E.g. if I do:  "call dump_loc(SOME_VAR)"
 >      where the "dump_loc" function just prints some stuff about SOME_VAR
 >      to stdout (and then flushes stdout).  In previous versions of gdb
 >      this worked great, but now it doesn't.

It works for me what do you see in Emacs?  What do you get if you do
"call dump_loc(SOME_VAR)" in GDB from the command line?

 >      This is actually kinda important, because it's a very commonly
 >      used technique to add gdb debugging hooks into programs...
 > 
 >      I thought maybe this had something to do with the
 >      "*input/output ...*" buffer which is now getting used, but the
 >      output didn't show up there either.
 > 
 > 
 >  (2) It display breakpoint icon in the margin, instead of in the
 >      fringe, if I have the "fringe-style" set to `half'.
 > 
 >      I guess maybe it's trying to ensure that the icon it fits in the
 >      space available, and indeed, there's like a single pixel chopped
 >      off one edge if I force it (by setting half-margin-mode _after_
 >      setting the breakpoint).
 > 
 >      However, having the margins are much more annoying than slightly
 >      truncated icons (especially since the icon is essentially, a red
 >      blob), so it would be nice if it were less eager about doing this,
 >      or tried to substitute a smaller icon in such a case, or something.

There are probably all kinds of anomalies with the margin: I don't know
why I made it two characters wide, the icon size is in pixels and not
not font size dependent ...

I think placement is determined by

	(if (>= (or left-fringe-width
		    (if source-window (car (window-fringes source-window)))
		    gdb-buffer-fringe-width) 8)

in gdb-put-breakpoint-icon.  You're welcome to change that value in CVS
to what you think is a more sensible value.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: other weird gdb-mi problems

[Dmitry Dzhus]

Nick Roberts wrote:

> It's an Emacs problem.  The CLI commands "up" and "down", don't emit any
> GDB/MI notifications so Emacs doen't know that the display needs updating.

I've changed `gdb-mi.el` to append `--frame` and `--thread` options to
every command it sends to GDB. This is is the recommended way to use
GDB/MI, because we can put all frame/thread selection logic to
frontend-land completely, without relying on internal state of GDB.
That's the way `gdb-mi.el` works now — select frame/thread on frontend
side and append --thread/--frame appropriately. `gdb-thread-number` and
`gdb-frame-number` variables reflect current thread (probably
buffer-local) and frame selected by Emacs.

When we type `thread N` in GUD console, GDB emits
`=thread-selected,id=N` notification. Emacs reads this and changes
`gdb-thread-number`.

No such notification is provided when we type `frame M`, `up` or `down`.
As the result, Emacs can't notice the change of current frame.

Previously `gdb-mi.el` deducted current frame from internal state of
GDB. I can revert changes to follow this behaviour again, but the real
fix would involve implementing `=frame-selected` notification in GDB.

> http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html but there hasn't
> been much interest.

It's pity that these patches didn't make it to GDB upstream :( I see now
that current `=thread-selected` notification implementation in GDB uses
a different and perhaps less elegant approach. I've posted a patch to
GDB mailing list which adds =frame-selected notification following the
current approach. I hope that GDB upstream accepts the patch or
reevaluates the one you'd sent before.
-- 
Happy Hacking.

http://sphinx.net.ru
む

Re: other weird gdb-mi problems

[Nick Roberts]

Dmitry Dzhus writes:
 > Nick Roberts wrote:
 > 
 > > It's an Emacs problem.  The CLI commands "up" and "down", don't emit any
 > > GDB/MI notifications so Emacs doen't know that the display needs updating.
 > 
 > I've changed `gdb-mi.el` to append `--frame` and `--thread` options to
 > every command it sends to GDB. This is is the recommended way to use
 > GDB/MI, because we can put all frame/thread selection logic to
 > frontend-land completely, without relying on internal state of GDB.
 > That's the way `gdb-mi.el` works now ? select frame/thread on frontend
 > side and append --thread/--frame appropriately. `gdb-thread-number` and
 > `gdb-frame-number` variables reflect current thread (probably
 > buffer-local) and frame selected by Emacs.

The problem here, though, is that when the user command _changes_ the
frame, e.g., "up", the frame number should change to 1 but Emacs sends
the command

 "-stack-info-frame --thread 1 --frame 0"
                                      ^^^
since it doesn't realise that the frame has changed.  It parses the output
and thinks that the frame is still 0.  If it sent:

 "-stack-info-frame --thread 1"

it would get the details of the newly selected frame and realise it had
changed.

 >
 > It's pity that these patches didn't make it to GDB upstream :( I see now
 > that current `=thread-selected` notification implementation in GDB uses
 > a different and perhaps less elegant approach. I've posted a patch to
 > GDB mailing list which adds =frame-selected notification following the
 > current approach. I hope that GDB upstream accepts the patch or
 > reevaluates the one you'd sent before.

The `=thread-selected` implementation is indeed somewhat different to what I
proposed. With regard to the frame-changed notification, I realise now Daniel
Jacobowitz pointed out that it would fire too often:

http://sourceware.org/ml/gdb-patches/2008-05/msg00024.html

I think that's when I added a handler for "-stack-info-frame" referred to
above.


-- 
Nick                                           http://www.inet.net.nz/~nickrob