Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Cc: vargaz@gmail.com
Subject: hook-stop sees dummy frames, bug or feature?
Date: Thu, 22 Jan 2009 03:22:00 -0000	[thread overview]
Message-ID: <200901220323.18225.pedro@codesourcery.com> (raw)

I was looking at fixing PR9664 <http://sourceware.org/bugzilla/show_bug.cgi?id=9664>,
which was a regression I introduced here:

 http://sourceware.org/ml/gdb-patches/2008-09/msg00193.html

The regression is about the fact that the hook-stop in normal_stop
is now run after frame printing, while it is documented as being run before.

 "(@samp{hook-stop}) makes the associated commands execute every time
 execution stops in your program: before breakpoint commands are run,
 displays are printed, or the stack frame is printed."

The current sequence is roughtly:

normal_stop ()
{
 ...
 - print frame
 - save `return' or infcall registers
 - pop dummy frame
 - hook-stop
 ...
}

Clearly, I need to put running the hook-stop higher up again.

In gdb <= 6.8, the hook-stop was run before we poped off the dummy
frame:

normal_stop ()
{
 ...
 - hook-stop
 - print frame
 - save `return' or infcall registers
 - pop dummy frame
 ...
}

 The case I'm considering is this:

(basically:
 define hook-stop
  frame
 end
 p func()
)

 >gdb-6.8 ./gdb
 (top-gdb) start
 Starting program: /home/pedro/gdb/normal_stop/build/gdb/gdb
 main (argc=1, argv=0x7ffff00043f8) at ../../src/gdb/gdb.c:28
 28        memset (&args, 0, sizeof args);
 (top-gdb) define hook-stop
 Type commands for definition of "hook-stop".
 End with a line saying just "end".
 >frame
 >end
 (top-gdb) p malloc (0)
 #0  <function called from gdb>          <<<<<< "frame" in hook-stop
 Current language:  auto; currently asm
 $1 = 11407376                           <<<<<< 'malloc (0)' result
 Current language:  auto; currently c
 (top-gdb) frame                         <<<<<< "frame" again shows something else.
 #0  main (argc=1, argv=0x7ffff00043f8) at ../../src/gdb/gdb.c:28
 28        memset (&args, 0, sizeof args);

Is the fact that the dummy frame is visible in a hook-stop a
bug, or a feature?

This is the current mainline behaviour:

 (top-gdb) p malloc (0)
 #0  main (argc=1, argv=0x7fffffffe408) at ../../src/gdb/gdb.c:28   <<< "frame" in hook-stop.
 28        memset (&args, 0, sizeof args);
 $1 = 11407440
 (top-gdb)

I'm inclined to consider it a bug to show the dummy frame, but I may be
missing some use cases.

Say, change normal_stop to:

 normal_stop ()
 {
  ...
  - pop dummy frame
  - hook-stop
  - print frame
  - save `return' or infcall registers
  ...
 }

(saving infcall registers could also move up, I think, but I'll leave
that out for now)

What do you guys think?

-- 
Pedro Alves


             reply	other threads:[~2009-01-22  3:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22  3:22 Pedro Alves [this message]
2009-01-22  3:45 ` Daniel Jacobowitz
2009-01-22  3:58 ` Joel Brobecker

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

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

  git send-email \
    --in-reply-to=200901220323.18225.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=vargaz@gmail.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox