|
From: <sv...@va...> - 2011-06-18 08:32:57
|
Author: sewardj
Date: 2011-06-18 09:28:04 +0100 (Sat, 18 Jun 2011)
New Revision: 11822
Log:
Minor GDBserver source tidying. Also a small usability fix: if
--vgdb-error=N is specified, print a bit of text telling the user the
magic commands to give GDB in order to attach to the process.
Added:
trunk/gdbserver_tests/README_DEVELOPERS
Removed:
trunk/gdbserver_tests/README_DEVELOPPERS
Modified:
trunk/coregrind/m_gdbserver/m_gdbserver.c
trunk/coregrind/m_gdbserver/remote-utils.c
trunk/coregrind/m_main.c
trunk/coregrind/m_scheduler/scheduler.c
trunk/coregrind/pub_core_gdbserver.h
trunk/coregrind/pub_core_scheduler.h
trunk/coregrind/vgdb.c
trunk/docs/xml/manual-core-adv.xml
trunk/gdbserver_tests/Makefile.am
trunk/gdbserver_tests/filter_stderr
trunk/gdbserver_tests/mcclean_after_fork.stderr.exp
trunk/gdbserver_tests/mcsignopass.stderr.exp
trunk/gdbserver_tests/mcsigpass.stderr.exp
trunk/gdbserver_tests/mcwatchpoints.stderr.exp
trunk/gdbserver_tests/nlcontrolc.stderr.exp
trunk/include/pub_tool_gdbserver.h
trunk/none/tests/cmdline1.stdout.exp
trunk/none/tests/cmdline2.stdout.exp
Modified: trunk/coregrind/m_gdbserver/m_gdbserver.c
===================================================================
--- trunk/coregrind/m_gdbserver/m_gdbserver.c 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/coregrind/m_gdbserver/m_gdbserver.c 2011-06-18 08:28:04 UTC (rev 11822)
@@ -7,7 +7,7 @@
This file is part of Valgrind, a dynamic binary instrumentation
framework.
- Copyright (C) 2011 Philippe Waroquiers
+ Copyright (C) 2011-2011 Philippe Waroquiers
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
Modified: trunk/coregrind/m_gdbserver/remote-utils.c
===================================================================
--- trunk/coregrind/m_gdbserver/remote-utils.c 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/coregrind/m_gdbserver/remote-utils.c 2011-06-18 08:28:04 UTC (rev 11822)
@@ -250,14 +250,31 @@
VG_(umsg)("embedded gdbserver: reading from %s\n", from_gdb);
VG_(umsg)("embedded gdbserver: writing to %s\n", to_gdb);
VG_(umsg)("embedded gdbserver: shared mem %s\n", shared_mem);
- VG_(umsg)("CONTROL ME using: vgdb --pid=%d%s%s ...command...\n",
+ VG_(umsg)("\n");
+ VG_(umsg)("TO CONTROL THIS PROCESS USING vgdb (which you probably\n"
+ "don't want to do, unless you know exactly what you're doing,\n"
+ "or are doing some strange experiment):\n"
+ " %s/../../bin/vgdb --pid=%d%s%s ...command...\n",
+ VG_LIBDIR,
pid, (name_default ? "" : " --vgdb="),
(name_default ? "" : name));
- VG_(umsg)("DEBUG ME using: (gdb) target remote | vgdb --pid=%d%s%s\n",
- pid, (name_default ? "" : " --vgdb="),
- (name_default ? "" : name));
- VG_(umsg)(" --pid optional if only one valgrind process is running\n");
}
+ if (VG_(clo_verbosity) > 1
+ || VG_(clo_vgdb_error) < 999999999) {
+ VG_(umsg)("\n");
+ VG_(umsg)(
+ "TO DEBUG THIS PROCESS USING GDB: start GDB like this\n"
+ " /path/to/gdb %s\n"
+ "and then give GDB the following command\n"
+ " target remote | %s/../../bin/vgdb --pid=%d%s%s\n",
+ VG_(args_the_exename),
+ VG_LIBDIR,
+ pid, (name_default ? "" : " --vgdb="),
+ (name_default ? "" : name)
+ );
+ VG_(umsg)("--pid is optional if only one valgrind process is running\n");
+ VG_(umsg)("\n");
+ }
if (!mknod_done) {
mknod_done++;
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/coregrind/m_main.c 2011-06-18 08:28:04 UTC (rev 11822)
@@ -132,7 +132,9 @@
" --child-silent-after-fork=no|yes omit child output between fork & exec? [no]\n"
" --vgdb=no|yes|full activate gdbserver? [yes]\n"
" full is slower but provides precise watchpoint/step\n"
-" --vgdb-error=<number> invoke gdbserver after <number> errors [%d] \n"
+" --vgdb-error=<number> invoke gdbserver after <number> errors [%d]\n"
+" to get started quickly, use --vgdb-error=0\n"
+" and follow the on-screen directions\n"
" --track-fds=no|yes track open file descriptors? [no]\n"
" --time-stamp=no|yes add timestamps to log messages? [no]\n"
" --log-fd=<number> log messages to file descriptor [2=stderr]\n"
Modified: trunk/coregrind/m_scheduler/scheduler.c
===================================================================
--- trunk/coregrind/m_scheduler/scheduler.c 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/coregrind/m_scheduler/scheduler.c 2011-06-18 08:28:04 UTC (rev 11822)
@@ -901,12 +901,7 @@
return retval;
}
-ULong VG_(bbs_done) (void)
-{
- return bbs_done;
-}
-
/* ---------------------------------------------------------------------
The scheduler proper.
------------------------------------------------------------------ */
Modified: trunk/coregrind/pub_core_gdbserver.h
===================================================================
--- trunk/coregrind/pub_core_gdbserver.h 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/coregrind/pub_core_gdbserver.h 2011-06-18 08:28:04 UTC (rev 11822)
@@ -7,7 +7,7 @@
This file is part of Valgrind, a dynamic binary instrumentation
framework.
- Copyright (C) 2011 Philippe Waroquiers
+ Copyright (C) 2011-2011 Philippe Waroquiers
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
Modified: trunk/coregrind/pub_core_scheduler.h
===================================================================
--- trunk/coregrind/pub_core_scheduler.h 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/coregrind/pub_core_scheduler.h 2011-06-18 08:28:04 UTC (rev 11822)
@@ -100,9 +100,6 @@
extern void VG_(disable_vgdb_poll) (void );
extern void VG_(force_vgdb_poll) ( void );
-/* nr of bbs done since startup. */
-extern ULong VG_(bbs_done) (void);
-
/* Stats ... */
extern void VG_(print_scheduler_stats) ( void );
Modified: trunk/coregrind/vgdb.c
===================================================================
--- trunk/coregrind/vgdb.c 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/coregrind/vgdb.c 2011-06-18 08:28:04 UTC (rev 11822)
@@ -6,7 +6,7 @@
This file is part of Valgrind, a dynamic binary instrumentation
framework.
- Copyright (C) 2011 Philippe Waroquiers
+ Copyright (C) 2011-2011 Philippe Waroquiers
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
Modified: trunk/docs/xml/manual-core-adv.xml
===================================================================
--- trunk/docs/xml/manual-core-adv.xml 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/docs/xml/manual-core-adv.xml 2011-06-18 08:28:04 UTC (rev 11822)
@@ -295,6 +295,13 @@
xreflabel="gdbserver simple example">
<title>Quick Start: debugging in 3 steps</title>
+<para>The simplest way to get started is to run Valgrind with the
+flag <option>--vgdb-error=0</option>. Then follow the on-screen
+directions, which give you the precise commands needed to start GDB
+and connect it to your program.</para>
+
+<para>Otherwise, here's a slightly more verbose overview.</para>
+
<para>If you want to debug a program with GDB when using the Memcheck
tool, start Valgrind the following way:
<screen><![CDATA[
Modified: trunk/gdbserver_tests/Makefile.am
===================================================================
--- trunk/gdbserver_tests/Makefile.am 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/Makefile.am 2011-06-18 08:28:04 UTC (rev 11822)
@@ -7,6 +7,7 @@
filter_memcheck_monitor filter_stderr filter_vgdb
EXTRA_DIST = \
+ README_DEVELOPERS \
mcbreak.stderrB.exp \
mcbreak.stderr.exp \
mcbreak.stdinB.gdb \
Copied: trunk/gdbserver_tests/README_DEVELOPERS (from rev 11818, trunk/gdbserver_tests/README_DEVELOPPERS)
===================================================================
--- trunk/gdbserver_tests/README_DEVELOPERS (rev 0)
+++ trunk/gdbserver_tests/README_DEVELOPERS 2011-06-18 08:28:04 UTC (rev 11822)
@@ -0,0 +1,241 @@
+Automatic regression tests:
+---------------------------
+The Valgrind gdbserver automatic tests are by default
+executed as part of the Valgrind test suite:
+ make regtest
+
+By default, these tests are running with the gdb found at
+Valgrind configure time.
+
+If you want to test with another gdb version, you can do:
+ make regtest GDB=/path/to/another/gdb
+
+or (to just run the gdbserver tests with another gdb):
+ cd gdbserver_tests
+ make check
+ cd ..
+ gdbserver_tests/make_local_links /path/to/another/gdb
+ perl tests/vg_regtest gdbserver_tests
+
+The minimum version to use the Valgrind gdbserver is gdb >= 6.5.
+ Previous versions do not have the 'target remote |' command. It
+ would be possible to use an older version by having a tcp relay
+ application between gdb and vgdb (or, alternatively, change vgdb
+ so that it could read/write from/to a tcpip socket rather than
+ read/write from stdin/stdout.
+
+The tests have been run on various platforms using gdb 7.2
+and on some platforms gdb 7.0 and 7.1.
+Some gdb tests implies a gdb >= 7.2. (these are automatically disabled
+if testing with a lower version).
+Test behaviour with gdb < 7.0 is unknown: some might fail,
+some might block or loop for a very long time.
+
+Some tests implies to have a vgdb "ptrace invoker" capable.
+
+The prerequisite are established during make regtest (using marker files).
+Each test verifies the prerequisite using the prereq: line.
+
+In case of failing tests
+------------------------
+When executed with a new gdb version and/or depending on the OS version,
+gdbserver tests might often fail due to (irrelevant) differences.
+Such irrelevant differences have to be filtered by gdbserver_tests/filter_gdb.
+
+You are welcome to fix such bugs by enhancing filter_gdb.
+
+Alternatively, to report such problems, the best is to re-run
+the gdbserver tests the following way:
+ perl tests/vg_regtest --keep-unfiltered gdbserver_tests
+
+Then file a bug in bugzilla, giving the following information:
+ output of
+ gdbserver_tests/gdb --version
+ uname -a
+ cat /etc/issue
+ valgrind --version (and/or svn version)
+ and attach a tar file containing all the *.out and *.diff
+ files in gdbserver_tests directory
+
+If a gdbserver test fails for other reasons, you can run the test
+manually in two windows:
+ In one window, the valgrind
+ In another window, you launch gdb yourself, and you copy paste
+ the command from xxxx.stdinB.gdb. This might help to see what is
+ wrong.
+
+Another good trick is also to execute the same kind of actions
+using a gdb connected to the gdbserver part of gdb.
+You can examine what is happening by enabling the trace
+of the packets being sent using the gdb command:
+ set debug remote 1
+Note however that the packets might be different
+(e.g. the Valgrind gdbserver understands the 'P' packet,
+which might not be understood by the gdbserver of gdb).
+
+Naming conventions:
+-------------------
+
+The gdbserver tests are done with various Valgrind tools. A gdbserver
+test using a tool xxxxxx should have its name starting with the 'short
+two letters code' of this tool. For example, the test mcvabits.vgtest
+is using Memcheck tool, while the test mssnapshot.vgtest is using
+massif tool.
+
+Typically, a gdbserver test implies to launch two programs:
+ prog: a program running under valgrind
+ progB: another program (typically, either gdb or vgdb standalone)
+The conventions about how to specify the 2nd program in a .vgtest
+are explained in the file ../tests/vg_regtest.in
+Many tests are using gdb as progB. The input for gdb is named
+xxxxxx.stdinB.gdb.
+
+One day, we might imagine to run tests in parallel.
+So, each test gets its own '--vgdb-prefix' argument.
+This also help to avoid interactions between two successive tests:
+if a previous test stayed blocked, the vgdb of the next test
+will not report an error due to multiple possible FIFOs.
+
+
+Rational for test approach
+--------------------------
+Two approaches have been looked at:
+ V: use the 'vg_regtest' approach used by the rest of Valgrind tests
+ G: use the gdb Dejagnu test framework.
+
+Advantages of V: much simpler that G, known by Valgrind developpers,
+no additional dependency for the Valgrind build and test.
+
+Disadvantages of V: not well suited to testing of interactive tools,
+very unflexible way to test the results (everything is in "template"
+files), templates contains often irrelevant data for the test but it
+can make the test fail. After writing 13 tests, it looks like the
+template diff approach is quite fragile (e.g. changing the gdb version
+and/or the OS version influences the output of irrelevant things which
+are part of the template).
+
+A more flexible template filtering is needed.
+Maybe something like:
+The program under test is outputting its instructions to be filtered in
+special markers e.g.
+#pushf filter_addresses | filter_messages
+... some output
+#pushf an_additional_filter
+... some other output, filtered by both the first and second push
+#popf
+... here output filtered only by the first pushf
+#popf
+
+Advantages of G: much more powerful, well suited to test a gdb with a
+gdbserver, tests can verify specifically some output without being
+impacted by other output, allow to test Valgrind gdbserver with the
+all of the gdb test suite (but a lot of tests will rather test gdb
+than Valgrind gdbserver).
+
+Disadvantages: not an easy beast to understand and master, running the
+whole gdb testsuite with Valgrind gdbserver looks to be a challenge.
+
+Currently, tests are written with vg_regtest. Approach G will be looked at it
+again (e.g. to complement V) once a basic set of tests are available.
+
+
+Manual tests still to automate:
+-------------------------------
+
+Validate monitor commands abbreviation recognition
+***************************************************
+mo vg.info all_errors # to show all errors recorded so far
+mo vg.i a # the same
+mo v # must give an error: v can match vg.set vg.info
+mo vg # the same vg
+mo vg. # the same vg.
+
+test of gdb detaching or dying
+******************************
+valgrind --vgdb=yes --vgdb-error=0 --vgdb-poll=500 ./t
+
+in another window
+
+gdb ./t
+set remotetimeout 100
+target remote|vgdb
+detach valgrind continues
+target remote|vgdb reattach
+detach valgrind continues
+target remote|vgdb reattach
+monitor vg.wait no effect
+
+
+
+test of valgrind/gdb output redirection
+***************************************
+valgrind --vgdb=yes --vgdb-error=1 --vgdb-poll=500 ./t
+
+in another window
+
+**** command to type*** ****** expected behaviour
+gdb ./t
+set remotetimeout 1000
+target remote | vgdb
+mo vg.set vgdb-error 1000 # so that valgrind does stop only at error 1000 and after
+mo vg.set gdb_output # to have further valgrind errors output in gdb
+c # continue, some errors will appear
+C-c # interrupt program
+mo vg.set log_output # to set back the valgrind output to normal process log output
+mo mc.l # leak output to appear in log of process
+mo vg.set mixed_output
+mo mc.l # leak output to appear in gdb
+
+
+
+test with a big executable: firefox
+***********************************
+valgrind --vgdb=yes --vgdb-error=1000 --vgdb-poll=50000 --trace-children=yes firefox 2>&1 | tee f.out
+
+wait for some messages from the "big" firefox executable to appear.
+Then:
+
+gdb /usr/lib/firefox-3.5/firefox
+target remote | vgdb
+... then you can do various next/print/bt/bt full/break/... to see it is working
+
+bulk test with the above
+************************
+to verify there is no race condition/no reentrance problem
+between gdbserver code and valgrind:
+start firefox like in the previous test.
+In another window, do:
+ while true
+ do
+ vgdb mc.leak
+ sleep 1
+ done
+
+NB: this will make firefox run extremely slow, as it will do a leak
+search every second.
+
+
+Test of "jump" functionality
+----------------------------
+... to be done : put two breaks, jump over one.
+... same but when error is encountered
+
+
+* test with --max-invoke-ms=0
+-----------------------------
+valgrind --vgdb=yes ./t
+... wait till you see "petachounok sleeping 4 of 15
+then try to gdb it
+
+!!!! this often causes gdb to report a protocol timeout.
+use gdb set remotetimeout <a big time> to avoid that.
+The symptoms of a timeout are:
+ (gdb) tar rem|vgdb --max-invoke-ms=0
+ Remote debugging using |vgdb --max-invoke-ms=0
+ relaying data between gdb and process 2930
+ Ignoring packet error, continuing...
+ warning: unrecognized item "timeout" in "qSupported" response
+
+* tests of shadow registers
+----------------------------
+Show/modify shadow registers
Deleted: trunk/gdbserver_tests/README_DEVELOPPERS
===================================================================
--- trunk/gdbserver_tests/README_DEVELOPPERS 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/README_DEVELOPPERS 2011-06-18 08:28:04 UTC (rev 11822)
@@ -1,241 +0,0 @@
-Automatic regression tests:
----------------------------
-The Valgrind gdbserver automatic tests are by default
-executed as part of the Valgrind test suite:
- make regtest
-
-By default, these tests are running with the gdb found at
-Valgrind configure time.
-
-If you want to test with another gdb version, you can do:
- make regtest GDB=/path/to/another/gdb
-
-or (to just run the gdbserver tests with another gdb):
- cd gdbserver_tests
- make check
- cd ..
- gdbserver_tests/make_local_links /path/to/another/gdb
- perl tests/vg_regtest gdbserver_tests
-
-The minimum version to use the Valgrind gdbserver is gdb >= 6.5.
- Previous versions do not have the 'target remote |' command. It
- would be possible to use an older version by having a tcp relay
- application between gdb and vgdb (or, alternatively, change vgdb
- so that it could read/write from/to a tcpip socket rather than
- read/write from stdin/stdout.
-
-The tests have been run on various platforms using gdb 7.2
-and on some platforms gdb 7.0 and 7.1.
-Some gdb tests implies a gdb >= 7.2. (these are automatically disabled
-if testing with a lower version).
-Test behaviour with gdb < 7.0 is unknown: some might fail,
-some might block or loop for a very long time.
-
-Some tests implies to have a vgdb "ptrace invoker" capable.
-
-The prerequisite are established during make regtest (using marker files).
-Each test verifies the prerequisite using the prereq: line.
-
-In case of failing tests
-------------------------
-When executed with a new gdb version and/or depending on the OS version,
-gdbserver tests might often fail due to (irrelevant) differences.
-Such irrelevant differences have to be filtered by gdbserver_tests/filter_gdb.
-
-You are welcome to fix such bugs by enhancing filter_gdb.
-
-Alternatively, to report such problems, the best is to re-run
-the gdbserver tests the following way:
- perl tests/vg_regtest --keep-unfiltered gdbserver_tests
-
-Then file a bug in bugzilla, giving the following information:
- output of
- gdbserver_tests/gdb --version
- uname -a
- cat /etc/issue
- valgrind --version (and/or svn version)
- and attach a tar file containing all the *.out and *.diff
- files in gdbserver_tests directory
-
-If a gdbserver test fails for other reasons, you can run the test
-manually in two windows:
- In one window, the valgrind
- In another window, you launch gdb yourself, and you copy paste
- the command from xxxx.stdinB.gdb. This might help to see what is
- wrong.
-
-Another good trick is also to execute the same kind of actions
-using a gdb connected to the gdbserver part of gdb.
-You can examine what is happening by enabling the trace
-of the packets being sent using the gdb command:
- set debug remote 1
-Note however that the packets might be different
-(e.g. the Valgrind gdbserver understands the 'P' packet,
-which might not be understood by the gdbserver of gdb).
-
-Naming conventions:
--------------------
-
-The gdbserver tests are done with various Valgrind tools. A gdbserver
-test using a tool xxxxxx should have its name starting with the 'short
-two letters code' of this tool. For example, the test mcvabits.vgtest
-is using Memcheck tool, while the test mssnapshot.vgtest is using
-massif tool.
-
-Typically, a gdbserver test implies to launch two programs:
- prog: a program running under valgrind
- progB: another program (typically, either gdb or vgdb standalone)
-The conventions about how to specify the 2nd program in a .vgtest
-are explained in the file ../tests/vg_regtest.in
-Many tests are using gdb as progB. The input for gdb is named
-xxxxxx.stdinB.gdb.
-
-One day, we might imagine to run tests in parallel.
-So, each test gets its own '--vgdb-prefix' argument.
-This also help to avoid interactions between two successive tests:
-if a previous test stayed blocked, the vgdb of the next test
-will not report an error due to multiple possible FIFOs.
-
-
-Rational for test approach
---------------------------
-Two approaches have been looked at:
- V: use the 'vg_regtest' approach used by the rest of Valgrind tests
- G: use the gdb Dejagnu test framework.
-
-Advantages of V: much simpler that G, known by Valgrind developpers,
-no additional dependency for the Valgrind build and test.
-
-Disadvantages of V: not well suited to testing of interactive tools,
-very unflexible way to test the results (everything is in "template"
-files), templates contains often irrelevant data for the test but it
-can make the test fail. After writing 13 tests, it looks like the
-template diff approach is quite fragile (e.g. changing the gdb version
-and/or the OS version influences the output of irrelevant things which
-are part of the template).
-
-A more flexible template filtering is needed.
-Maybe something like:
-The program under test is outputting its instructions to be filtered in
-special markers e.g.
-#pushf filter_addresses | filter_messages
-... some output
-#pushf an_additional_filter
-... some other output, filtered by both the first and second push
-#popf
-... here output filtered only by the first pushf
-#popf
-
-Advantages of G: much more powerful, well suited to test a gdb with a
-gdbserver, tests can verify specifically some output without being
-impacted by other output, allow to test Valgrind gdbserver with the
-all of the gdb test suite (but a lot of tests will rather test gdb
-than Valgrind gdbserver).
-
-Disadvantages: not an easy beast to understand and master, running the
-whole gdb testsuite with Valgrind gdbserver looks to be a challenge.
-
-Currently, tests are written with vg_regtest. Approach G will be looked at it
-again (e.g. to complement V) once a basic set of tests are available.
-
-
-Manual tests still to automate:
--------------------------------
-
-Validate monitor commands abbreviation recognition
-***************************************************
-mo vg.info all_errors # to show all errors recorded so far
-mo vg.i a # the same
-mo v # must give an error: v can match vg.set vg.info
-mo vg # the same vg
-mo vg. # the same vg.
-
-test of gdb detaching or dying
-******************************
-valgrind --vgdb=yes --vgdb-error=0 --vgdb-poll=500 ./t
-
-in another window
-
-gdb ./t
-set remotetimeout 100
-target remote|vgdb
-detach valgrind continues
-target remote|vgdb reattach
-detach valgrind continues
-target remote|vgdb reattach
-monitor vg.wait no effect
-
-
-
-test of valgrind/gdb output redirection
-***************************************
-valgrind --vgdb=yes --vgdb-error=1 --vgdb-poll=500 ./t
-
-in another window
-
-**** command to type*** ****** expected behaviour
-gdb ./t
-set remotetimeout 1000
-target remote | vgdb
-mo vg.set vgdb-error 1000 # so that valgrind does stop only at error 1000 and after
-mo vg.set gdb_output # to have further valgrind errors output in gdb
-c # continue, some errors will appear
-C-c # interrupt program
-mo vg.set log_output # to set back the valgrind output to normal process log output
-mo mc.l # leak output to appear in log of process
-mo vg.set mixed_output
-mo mc.l # leak output to appear in gdb
-
-
-
-test with a big executable: firefox
-***********************************
-valgrind --vgdb=yes --vgdb-error=1000 --vgdb-poll=50000 --trace-children=yes firefox 2>&1 | tee f.out
-
-wait for some messages from the "big" firefox executable to appear.
-Then:
-
-gdb /usr/lib/firefox-3.5/firefox
-target remote | vgdb
-... then you can do various next/print/bt/bt full/break/... to see it is working
-
-bulk test with the above
-************************
-to verify there is no race condition/no reentrance problem
-between gdbserver code and valgrind:
-start firefox like in the previous test.
-In another window, do:
- while true
- do
- vgdb mc.leak
- sleep 1
- done
-
-NB: this will make firefox run extremely slow, as it will do a leak
-search every second.
-
-
-Test of "jump" functionality
-----------------------------
-... to be done : put two breaks, jump over one.
-... same but when error is encountered
-
-
-* test with --max-invoke-ms=0
------------------------------
-valgrind --vgdb=yes ./t
-... wait till you see "petachounok sleeping 4 of 15
-then try to gdb it
-
-!!!! this often causes gdb to report a protocol timeout.
-use gdb set remotetimeout <a big time> to avoid that.
-The symptoms of a timeout are:
- (gdb) tar rem|vgdb --max-invoke-ms=0
- Remote debugging using |vgdb --max-invoke-ms=0
- relaying data between gdb and process 2930
- Ignoring packet error, continuing...
- warning: unrecognized item "timeout" in "qSupported" response
-
-* tests of shadow registers
-----------------------------
-Show/modify shadow registers
Modified: trunk/gdbserver_tests/filter_stderr
===================================================================
--- trunk/gdbserver_tests/filter_stderr 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/filter_stderr 2011-06-18 08:28:04 UTC (rev 11822)
@@ -3,4 +3,10 @@
dir=`dirname $0`
$dir/../tests/filter_stderr_basic |
-sed -e '/^Copyright (C) /d'
+sed -e '/^Copyright (C) /d' \
+ \
+ -e '/TO DEBUG THIS PROCESS USING GDB/d' \
+ -e '/\/path\/to\/gdb/d' \
+ -e '/and then give GDB the following command/d' \
+ -e '/target remote |/d' \
+ -e '/pid is optional if only one valgrind process is running/d'
Modified: trunk/gdbserver_tests/mcclean_after_fork.stderr.exp
===================================================================
--- trunk/gdbserver_tests/mcclean_after_fork.stderr.exp 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/mcclean_after_fork.stderr.exp 2011-06-18 08:28:04 UTC (rev 11822)
@@ -1,6 +1,8 @@
(action at startup) vgdb me ...
+
+
HEAP SUMMARY:
in use at exit: 0 bytes in 0 blocks
total heap usage: 0 allocs, 0 frees, 0 bytes allocated
Modified: trunk/gdbserver_tests/mcsignopass.stderr.exp
===================================================================
--- trunk/gdbserver_tests/mcsignopass.stderr.exp 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/mcsignopass.stderr.exp 2011-06-18 08:28:04 UTC (rev 11822)
@@ -1,5 +1,7 @@
(action at startup) vgdb me ...
+
+
Test 1: Invalid write of size 4
at 0x........: test1 (faultstatus.c:105)
by 0x........: main (faultstatus.c:168)
Modified: trunk/gdbserver_tests/mcsigpass.stderr.exp
===================================================================
--- trunk/gdbserver_tests/mcsigpass.stderr.exp 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/mcsigpass.stderr.exp 2011-06-18 08:28:04 UTC (rev 11822)
@@ -1,5 +1,7 @@
(action at startup) vgdb me ...
+
+
Test 1: Invalid write of size 4
at 0x........: test1 (faultstatus.c:105)
by 0x........: main (faultstatus.c:168)
Modified: trunk/gdbserver_tests/mcwatchpoints.stderr.exp
===================================================================
--- trunk/gdbserver_tests/mcwatchpoints.stderr.exp 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/mcwatchpoints.stderr.exp 2011-06-18 08:28:04 UTC (rev 11822)
@@ -1,5 +1,7 @@
(action at startup) vgdb me ...
+
+
breakme function called from line 19
before reading 0/4/8
u: Expected value at 0
Modified: trunk/gdbserver_tests/nlcontrolc.stderr.exp
===================================================================
--- trunk/gdbserver_tests/nlcontrolc.stderr.exp 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/gdbserver_tests/nlcontrolc.stderr.exp 2011-06-18 08:28:04 UTC (rev 11822)
@@ -1,6 +1,8 @@
Nulgrind, the minimal Valgrind tool
(action at startup) vgdb me ...
+
+
loops/sleep_ms/burn/threads_spec: 1000000000 1000000000 1000000000 BSBSBSBS
Brussels ready to sleep and/or burn
London ready to sleep and/or burn
Modified: trunk/include/pub_tool_gdbserver.h
===================================================================
--- trunk/include/pub_tool_gdbserver.h 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/include/pub_tool_gdbserver.h 2011-06-18 08:28:04 UTC (rev 11822)
@@ -7,7 +7,7 @@
This file is part of Valgrind, a dynamic binary instrumentation
framework.
- Copyright (C) 2011 Philippe Waroquiers
+ Copyright (C) 2011-2011 Philippe Waroquiers
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
Modified: trunk/none/tests/cmdline1.stdout.exp
===================================================================
--- trunk/none/tests/cmdline1.stdout.exp 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/none/tests/cmdline1.stdout.exp 2011-06-18 08:28:04 UTC (rev 11822)
@@ -18,7 +18,9 @@
--child-silent-after-fork=no|yes omit child output between fork & exec? [no]
--vgdb=no|yes|full activate gdbserver? [yes]
full is slower but provides precise watchpoint/step
- --vgdb-error=<number> invoke gdbserver after <number> errors [999999999]
+ --vgdb-error=<number> invoke gdbserver after <number> errors [999999999]
+ to get started quickly, use --vgdb-error=0
+ and follow the on-screen directions
--track-fds=no|yes track open file descriptors? [no]
--time-stamp=no|yes add timestamps to log messages? [no]
--log-fd=<number> log messages to file descriptor [2=stderr]
Modified: trunk/none/tests/cmdline2.stdout.exp
===================================================================
--- trunk/none/tests/cmdline2.stdout.exp 2011-06-17 08:31:22 UTC (rev 11821)
+++ trunk/none/tests/cmdline2.stdout.exp 2011-06-18 08:28:04 UTC (rev 11822)
@@ -18,7 +18,9 @@
--child-silent-after-fork=no|yes omit child output between fork & exec? [no]
--vgdb=no|yes|full activate gdbserver? [yes]
full is slower but provides precise watchpoint/step
- --vgdb-error=<number> invoke gdbserver after <number> errors [999999999]
+ --vgdb-error=<number> invoke gdbserver after <number> errors [999999999]
+ to get started quickly, use --vgdb-error=0
+ and follow the on-screen directions
--track-fds=no|yes track open file descriptors? [no]
--time-stamp=no|yes add timestamps to log messages? [no]
--log-fd=<number> log messages to file descriptor [2=stderr]
|