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
next 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