From: PAUL GILLIAM <pgilliam@us.ibm.com>
To: gdb@sources.redhat.com
Cc: John Yates <jyates@netezza.com>
Subject: Re: Instrcutions that must not be stepped.
Date: Sat, 10 Jun 2006 00:33:00 -0000 [thread overview]
Message-ID: <1149871875.3037.55.camel@dufur.beaverton.ibm.com> (raw)
In-Reply-To: <20060609141210.GA28306@nevyn.them.org>
On Fri, 2006-06-09 at 10:12 -0400, Daniel Jacobowitz wrote:
. . .
> There is no way to do this for most targets. Paul's probably talking
> about native PowerPC GDB, not any kind of remote stub. Even at that
> point, I think the performance impact here would be unacceptable; the
> repeated single step path is one of the few time-sensitive bits of
GDB.
Daniel is correct: my specific need is for native PowerPC, but the need
for dealing with atomic sequences is more universal. I would like to
come up with a solution for my need that would not hinder a more
universal solution at some later point.
_________
BAD NEWS:
~~~~~~~~~
I tried to measure the impact of reading the instruction about to be
stepped and stumbled across a *horrible* GDB bug. When the number of
instructions stepped in the "Single stepping until exit from function"
mode is large enough (haven't pinned it down yet), the system starts
thrashing until X freezes up and then, after a time, the system crashes.
This is with an un-modified GDB, both cvs-head and the 6.5 tarball.
Here is the setup:
I have a stripped shared library called libtest.so in a test directory.
Here is it's source, "libtest.c":
char *
slow_hello ()
{
char message[] = "Hello, World";
static char out_buf[sizeof(message)];
int i;
char *cp;
for (cp=message; *cp; ++cp)
for (i=0; i<10000; ++i)
out_buf[cp - message] = *cp;
return out_buf;
}
The main program, "testprog.c":
#include <stdio.h>
void slow_help ();
int
main ()
{
printf ("%s\n", slow_hello ());
return 0;
}
Here is how I built the executable:
cc -fPIC -c libtest.c
cc -shared libtest.o -o libtest.so
cc -c testprog.c
cc -L. -ltest testprog.o -o testprog
I used the following gdb script ("gdb-script"):
start
b slow_hello
c
s
c
q
Here is what it looks like when I run GDB:
[pgilliam@dufur]$ LD_LIBRARY_PATH=. gdb -x gdb-script testprog
GNU gdb 6.5.50.20060608-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "powerpc64-unknown-linux-gnu"...Using
host libthread_db library "/lib/libthread_db.so.1".
Breakpoint 1 at 0x100015a4: file testprog.c, line 8.
main () at testprog.c:8
8 printf ("%s\n", slow_hello ());
Breakpoint 2 at 0xffaf70c
Breakpoint 2, 0x0ffaf70c in slow_hello () from ./libtest.so
Single stepping until exit from function slow_hello,
which has no line number information.
Program received signal SIGINT, Interrupt.
0x0ffaf77c in slow_hello () from ./libtest.so
Hello, World
Program exited normally.
[pgilliam@dufur]$ cat libtest.c
If I didn't interrupt it with a <cntl-c> within a minute or so of it's
start, the system would start thrashing and, sometime overnight, it
crashed.
Again, both cvs-head and 6.5 exhibited this behavior, but
(HERE'S THE KICKER) the GDB distributed with the system did not.
Here is with the distributed GDB:
[pgilliam@dufur]$ time LD_LIBRARY_PATH=. gdb -x gdb-script
testprog
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "ppc-redhat-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".
Breakpoint 1 at 0x100015a4: file testprog.c, line 8.
main () at testprog.c:8
8 printf ("%s\n", slow_hello ());
Breakpoint 2 at 0xffaf70c
Breakpoint 2, 0x0ffaf70c in slow_hello () from ./libtest.so
Single stepping until exit from function slow_hello,
which has no line number information.
Hello, World
main () at testprog.c:9
9 return 0;
Program exited normally.
real 0m55.448s
user 0m12.933s
sys 0m30.534s
[pgilliam@dufur]$
I tried it with vanilla 6.4 with no problem.
I also tried it with cvs-head on an x86 system with no problem, but with
something strange:
here is with the distributed gdb on x86 (slight mod to gdb-script
needed):
pgilliam> time LD_LIBRARY_PATH=. gdb -x gdb-script ./testprog
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i586-suse-linux"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
Breakpoint 1 at 0x80484e2
Breakpoint 1, 0x080484e2 in main ()
Breakpoint 2 at 0x400186ae
Breakpoint 2, 0x400186ae in slow_hello () from ./libtest.so
Single stepping until exit from function slow_hello,
which has no line number information.
0x080484f7 in main ()
Hello, World
Program exited normally.
real 0m37.366s
user 0m14.006s
sys 0m25.242s
pgilliam>
And here it is with cvs-head on x86:
pgilliam> time LD_LIBRARY_PATH=. ../gdb -x gdb-script ./testprog
GNU gdb 6.5.50.20060609-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
Breakpoint 1 at 0x80484e2
Breakpoint 1, 0x080484e2 in main ()
Breakpoint 2 at 0x400186ae
Breakpoint 2, 0x400186ae in slow_hello () from ./libtest.so
Single stepping until exit from function slow_hello,
which has no line number information.
0x080484f7 in main ()
Hello, World
Program exited normally.
real 2m4.106s
user 0m42.448s
sys 1m25.191s
pgilliam>
Wow! Why did it take so much longer?
-=# Paul #=-
next prev parent reply other threads:[~2006-06-09 17:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-09 14:12 John Yates
2006-06-09 14:28 ` Daniel Jacobowitz
2006-06-10 0:33 ` PAUL GILLIAM [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-06-08 2:27 PAUL GILLIAM
2006-06-08 3:50 ` Daniel Jacobowitz
2006-06-16 4:36 ` PAUL GILLIAM
2006-06-17 12:26 ` PAUL GILLIAM
2006-06-18 4:57 ` Mark Kettenis
2006-06-20 20:13 ` PAUL GILLIAM
2006-06-20 22:53 ` Paul Koning
2006-06-20 23:34 ` PAUL GILLIAM
2006-06-21 1:17 ` Daniel Jacobowitz
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=1149871875.3037.55.camel@dufur.beaverton.ibm.com \
--to=pgilliam@us.ibm.com \
--cc=gdb@sources.redhat.com \
--cc=jyates@netezza.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