You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
|
2
(1) |
3
(1) |
4
(5) |
5
|
6
(1) |
7
|
|
8
(10) |
9
(7) |
10
(2) |
11
(10) |
12
(1) |
13
|
14
(1) |
|
15
(3) |
16
|
17
|
18
|
19
|
20
|
21
(5) |
|
22
(2) |
23
(2) |
24
(4) |
25
(2) |
26
|
27
(7) |
28
(4) |
|
29
(5) |
30
(5) |
31
(1) |
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2023-01-08 21:56:40
|
On Sun, 2023-01-08 at 22:25 +0100, Mark Wielaard wrote: > Hi Philippe, > > On Sun, Jan 08, 2023 at 09:28:32PM +0100, Philippe Waroquiers wrote: > > On Sun, 2023-01-08 at 21:17 +0100, Mark Wielaard wrote: > > > > Possibly, we might complete the below message : > > > > ==2984378== (action at startup) vgdb me ... > > > > ==2984378== > > > > ==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this > > > > ==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem > > > > ==2984378== and then give GDB the following command > > > > ==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378 > > > > ==2984378== --pid is optional if only one valgrind process is running > > > > > > > > with: > > > > ==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins. > > > > ==2984378== Alternatively, you might load it before with the GDB command: > > > > ==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py > > > > > > Sasha's has been working on adding a --multi option to vgdb. > > > https://bugs.kde.org/show_bug.cgi?id=434057 > > > > > > That way you can start a program under valgrind from gdb. The idea > > > was that we would use this to have a special kind of target valgrind > > > in gdb which can/should setup a couple of things for the user to make > > > the gdb/valgrind integration a bit smoother. Such a "target valgrind" > > > could then also automatically load valgrind-monitor.py > > > > Effectively, if GDB knows it is speaking with a valgrind gdbserver, > > then GDB can itself load the python code before valgrind starts its > > execution. GDB however will have to find the location of this > > python code, at it depends on the version of valgrind it (will) > > connect to. > > O, I forgot that the install location of the script can differ. Hmmm. > > Do you think it might make sense to ask for a gdb remote protocol > extension? So gdb may ask the remote target for a script to load to > extend the functionality of the target? Implementing an extension to the protocol will effectively allow GDB to load a file or get the python code to evaluate at connect time. > > BTW. I wanted to ask you about the --vgdb-shadow-registers=no > default. Is this because older GDB versions might not understand this? > If so, is there a way to detect a newer GDB/remote protocol version to > turn the default to yes? IIRC, that was effectively because old GDB versions or GDB compiled without expat/xml support will not work. Another reason is that info reg and company will show a lot more info if we put yes by default. > > Thanks, > > Mark |
|
From: Philippe W. <phi...@sk...> - 2023-01-08 21:28:09
|
On Sun, 2023-01-08 at 21:51 +0100, Paul Floyd wrote: > Hi > > The python loading doesn't seem to work on FreeBSD. > > Possibly a bug in gdb? > > I've tried putting in .gdbinit > > set debug auto-load > set auto-load safe-path / > > I still get things like The gdbserver tests are started with --nx, meaning to not load any .gdbinit. When I start my (locally built) gdb with --nx I see this: (gdb) show auto-load safe-path List of directories from which it is safe to auto-load files is :/auto-load. (gdb) In the meantime, what we might do is to add additional patterns in gdbserver_tests/filter_gdb.in to also delete the messages when the python code cannot be loaded. That will at least ensure the tests are working with or without python code loaded. Philippe > > > --- mcleak.stdoutB.exp 2022-12-31 08:58:43.734255000 +0100 > +++ mcleak.stdoutB.out 2023-01-08 21:39:59.656817000 +0100 > @@ -1,5 +1,14 @@ > Breakpoint 1 at 0x........: file leak-delta.c, line 10. > Continuing. > +To enable execution of this file add > + add-auto-load-safe-path > /usr/home/paulf/tools/valgrind/libexec/valgrind/valgrind-monitor.py > +line to your configuration file "/home/paulf/.gdbinit". > +To completely disable this security protection add > + set auto-load safe-path / > +line to your configuration file "/home/paulf/.gdbinit". > +For more information about this security protection see the > +"Auto-loading safe path" section in the GDB manual. E.g., run from the > shell: > + info "(gdb)Auto-loading safe path" > > and > > --- mcleak.stderrB.exp 2022-12-31 08:58:43.733901000 +0100 > +++ mcleak.stderrB.out 2023-01-08 21:39:59.747972000 +0100 > @@ -1,4 +1,5 @@ > vgdb-error value changed from 0 to 999999 > +warning: File > "/usr/home/paulf/tools/valgrind/libexec/valgrind/valgrind-monitor.py" > auto-loading has been declined by your `auto-load safe-path' set to > "$debugdir:$datadir/auto-load". > 10 bytes in 1 blocks are still reachable in loss record ... of ... > at 0x........: malloc (vg_replace_malloc.c:...) > by 0x........: f (leak-delta.c:15) > > A+ > Paul > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Mark W. <ma...@kl...> - 2023-01-08 21:25:51
|
Hi Philippe, On Sun, Jan 08, 2023 at 09:28:32PM +0100, Philippe Waroquiers wrote: > On Sun, 2023-01-08 at 21:17 +0100, Mark Wielaard wrote: > > > Possibly, we might complete the below message : > > > ==2984378== (action at startup) vgdb me ... > > > ==2984378== > > > ==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this > > > ==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem > > > ==2984378== and then give GDB the following command > > > ==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378 > > > ==2984378== --pid is optional if only one valgrind process is running > > > > > > with: > > > ==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins. > > > ==2984378== Alternatively, you might load it before with the GDB command: > > > ==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py > > > > Sasha's has been working on adding a --multi option to vgdb. > > https://bugs.kde.org/show_bug.cgi?id=434057 > > > > That way you can start a program under valgrind from gdb. The idea > > was that we would use this to have a special kind of target valgrind > > in gdb which can/should setup a couple of things for the user to make > > the gdb/valgrind integration a bit smoother. Such a "target valgrind" > > could then also automatically load valgrind-monitor.py > > Effectively, if GDB knows it is speaking with a valgrind gdbserver, > then GDB can itself load the python code before valgrind starts its > execution. GDB however will have to find the location of this > python code, at it depends on the version of valgrind it (will) > connect to. O, I forgot that the install location of the script can differ. Hmmm. Do you think it might make sense to ask for a gdb remote protocol extension? So gdb may ask the remote target for a script to load to extend the functionality of the target? BTW. I wanted to ask you about the --vgdb-shadow-registers=no default. Is this because older GDB versions might not understand this? If so, is there a way to detect a newer GDB/remote protocol version to turn the default to yes? Thanks, Mark |
|
From: Paul F. <pj...@wa...> - 2023-01-08 20:51:39
|
Hi
The python loading doesn't seem to work on FreeBSD.
Possibly a bug in gdb?
I've tried putting in .gdbinit
set debug auto-load
set auto-load safe-path /
I still get things like
--- mcleak.stdoutB.exp 2022-12-31 08:58:43.734255000 +0100
+++ mcleak.stdoutB.out 2023-01-08 21:39:59.656817000 +0100
@@ -1,5 +1,14 @@
Breakpoint 1 at 0x........: file leak-delta.c, line 10.
Continuing.
+To enable execution of this file add
+ add-auto-load-safe-path
/usr/home/paulf/tools/valgrind/libexec/valgrind/valgrind-monitor.py
+line to your configuration file "/home/paulf/.gdbinit".
+To completely disable this security protection add
+ set auto-load safe-path /
+line to your configuration file "/home/paulf/.gdbinit".
+For more information about this security protection see the
+"Auto-loading safe path" section in the GDB manual. E.g., run from the
shell:
+ info "(gdb)Auto-loading safe path"
and
--- mcleak.stderrB.exp 2022-12-31 08:58:43.733901000 +0100
+++ mcleak.stderrB.out 2023-01-08 21:39:59.747972000 +0100
@@ -1,4 +1,5 @@
vgdb-error value changed from 0 to 999999
+warning: File
"/usr/home/paulf/tools/valgrind/libexec/valgrind/valgrind-monitor.py"
auto-loading has been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
10 bytes in 1 blocks are still reachable in loss record ... of ...
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: f (leak-delta.c:15)
A+
Paul
|
|
From: Philippe W. <phi...@sk...> - 2023-01-08 20:28:44
|
Hello Mark, Thanks for the feedback, reply below. On Sun, 2023-01-08 at 21:17 +0100, Mark Wielaard wrote: > Hi Philippe, > > On Tue, Dec 27, 2022 at 11:11:51PM +0100, Philippe Waroquiers wrote: > > This commit implements in python a set of GDB commands corresponding > > to the Valgrind gdbserver monitor commands. Basically, the idea is > > that one GDB command is defined for each valgrind gdbserver > > subcommand and will generate and send a monitor command to valgrind. > > > > The python code is auto-loaded by GDB as soon as GDB observes that > > the valgrind preload core shared lib is loaded > > (e.g. vgpreload_core-amd64-linux.so). This automatic loading is > > done thanks to the .debug_gdb_scripts section added in > > vg_preloaded.c file. Sadly, the auto-load only happens once > > valgrind has started to execute the code of ld that loads this > > vg_preload file. > > I see you add it to the vg_preload file with an asm statement. > Is that easier than using a linker script? I just followed the recommendation given in the GDB python documentation. Note that the section must be in an "early" loaded valgrind shared object. > > The asm statement is also added to m_main.c, why is that? This was a leftover of a failed trial to have the python code auto-loaded by GDB before valgrind started its execution. It has been removed in the version that was pushed this afternoon. > > > I have tried 2 approaches to have the python code > > auto-loaded when attaching at startup to valgrind: > > > > * have valgrind gdbserver reporting first to GDB that the > > executable file is the tool executable (with a > > .debug_gdb_scripts section) and then reporting the real (guest) > > executable file. The drawback of this approach is that it > > triggers a warning/question in GDB according to the GDB setting > > 'set exec-file-mismatch'. > > > > * have valgrind gdbserver pretending to be multiprocess enabled, > > and report a fake process using the tool executable with a > > .debug_gdb_scripts section. The drawback of this is that this > > always creates a second inferior in GDB, which will be > > confusing. > > > > Possibly, we might complete the below message : > > ==2984378== (action at startup) vgdb me ... > > ==2984378== > > ==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this > > ==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem > > ==2984378== and then give GDB the following command > > ==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378 > > ==2984378== --pid is optional if only one valgrind process is running > > > > with: > > ==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins. > > ==2984378== Alternatively, you might load it before with the GDB command: > > ==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py > > Sasha's has been working on adding a --multi option to vgdb. > https://bugs.kde.org/show_bug.cgi?id=434057 > > That way you can start a program under valgrind from gdb. The idea > was that we would use this to have a special kind of target valgrind > in gdb which can/should setup a couple of things for the user to make > the gdb/valgrind integration a bit smoother. Such a "target valgrind" > could then also automatically load valgrind-monitor.py Effectively, if GDB knows it is speaking with a valgrind gdbserver, then GDB can itself load the python code before valgrind starts its execution. GDB however will have to find the location of this python code, at it depends on the version of valgrind it (will) connect to. > > > At this point, you might ask yourself: "what is the interest ?". > > > > Using GDB valgrind commands provides several advantages compared to > > the valgrind gdbserver monitor commands. > > > > Evaluation of arguments by GDB: > > ------------------------------- > > For relevant arguments, the GDB command will evaluate its arguments using > > the usual GDB evaluation logic, for example, instead of printing/copying > > the address and size of 'some_mem', the following will work: > > (gdb) memcheck xb &some_mem sizeof(some_mem) > > ff ff ff ff ff > > 0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00 > > (gdb) > > > > or: > > (gdb) p some_mem > > $4 = "\000\000\000\000" > > (gdb) memcheck xb &$4 > > ff ff ff ff ff > > 0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00 > > (gdb) > > > > This is both easier to use interactively and easier to use in GDB scripts, > > as you can directly use variable names in the GDB valgrind commands. > > This is so useful! Thanks for working on this. > > Cheers, > > Mark |
|
From: Mark W. <ma...@kl...> - 2023-01-08 20:17:40
|
Hi Philippe, On Tue, Dec 27, 2022 at 11:11:51PM +0100, Philippe Waroquiers wrote: > This commit implements in python a set of GDB commands corresponding > to the Valgrind gdbserver monitor commands. Basically, the idea is > that one GDB command is defined for each valgrind gdbserver > subcommand and will generate and send a monitor command to valgrind. > > The python code is auto-loaded by GDB as soon as GDB observes that > the valgrind preload core shared lib is loaded > (e.g. vgpreload_core-amd64-linux.so). This automatic loading is > done thanks to the .debug_gdb_scripts section added in > vg_preloaded.c file. Sadly, the auto-load only happens once > valgrind has started to execute the code of ld that loads this > vg_preload file. I see you add it to the vg_preload file with an asm statement. Is that easier than using a linker script? The asm statement is also added to m_main.c, why is that? > I have tried 2 approaches to have the python code > auto-loaded when attaching at startup to valgrind: > > * have valgrind gdbserver reporting first to GDB that the > executable file is the tool executable (with a > .debug_gdb_scripts section) and then reporting the real (guest) > executable file. The drawback of this approach is that it > triggers a warning/question in GDB according to the GDB setting > 'set exec-file-mismatch'. > > * have valgrind gdbserver pretending to be multiprocess enabled, > and report a fake process using the tool executable with a > .debug_gdb_scripts section. The drawback of this is that this > always creates a second inferior in GDB, which will be > confusing. > > Possibly, we might complete the below message : > ==2984378== (action at startup) vgdb me ... > ==2984378== > ==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this > ==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem > ==2984378== and then give GDB the following command > ==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378 > ==2984378== --pid is optional if only one valgrind process is running > > with: > ==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins. > ==2984378== Alternatively, you might load it before with the GDB command: > ==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py Sasha's has been working on adding a --multi option to vgdb. https://bugs.kde.org/show_bug.cgi?id=434057 That way you can start a program under valgrind from gdb. The idea was that we would use this to have a special kind of target valgrind in gdb which can/should setup a couple of things for the user to make the gdb/valgrind integration a bit smoother. Such a "target valgrind" could then also automatically load valgrind-monitor.py > At this point, you might ask yourself: "what is the interest ?". > > Using GDB valgrind commands provides several advantages compared to > the valgrind gdbserver monitor commands. > > Evaluation of arguments by GDB: > ------------------------------- > For relevant arguments, the GDB command will evaluate its arguments using > the usual GDB evaluation logic, for example, instead of printing/copying > the address and size of 'some_mem', the following will work: > (gdb) memcheck xb &some_mem sizeof(some_mem) > ff ff ff ff ff > 0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00 > (gdb) > > or: > (gdb) p some_mem > $4 = "\000\000\000\000" > (gdb) memcheck xb &$4 > ff ff ff ff ff > 0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00 > (gdb) > > This is both easier to use interactively and easier to use in GDB scripts, > as you can directly use variable names in the GDB valgrind commands. This is so useful! Thanks for working on this. Cheers, Mark |
|
From: Paul F. <pa...@so...> - 2023-01-08 16:53:18
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=d320fc123b942a31cd22b22f3a10a3278d37ad47 commit d320fc123b942a31cd22b22f3a10a3278d37ad47 Author: Paul Floyd <pj...@wa...> Date: Sun Jan 8 17:52:48 2023 +0100 FreeBSD: clang-tidy corrections Diff: --- coregrind/m_libcfile.c | 22 ++++++++++++++-------- coregrind/m_scheduler/scheduler.c | 28 ++++++++++++++-------------- coregrind/m_syswrap/syswrap-amd64-freebsd.c | 4 ++-- coregrind/m_syswrap/syswrap-x86-freebsd.c | 22 ++++++++++++++-------- 4 files changed, 44 insertions(+), 32 deletions(-) diff --git a/coregrind/m_libcfile.c b/coregrind/m_libcfile.c index 4fdfcbd28b..95fa4bce4f 100644 --- a/coregrind/m_libcfile.c +++ b/coregrind/m_libcfile.c @@ -124,7 +124,8 @@ Bool VG_(resolve_filename) ( Int fd, const HChar** result ) Int mib[4]; SysRes sres; vki_size_t len; - Char *bp, *eb; + Char *bp; + Char *eb; struct vki_kinfo_file *kf; static HChar *buf = NULL; static SizeT bufsiz = 0; @@ -150,14 +151,16 @@ Bool VG_(resolve_filename) ( Int fd, const HChar** result ) eb = filedesc_buf + len; while (bp < eb) { kf = (struct vki_kinfo_file *)bp; - if (kf->vki_kf_fd == fd) + if (kf->vki_kf_fd == fd) { break; + } bp += kf->vki_kf_structsize; } - if (bp >= eb || *kf->vki_kf_path == '\0') + if (bp >= eb || *kf->vki_kf_path == '\0') { VG_(strncpy)( buf, "[unknown]", bufsiz ); - else + } else { VG_(strncpy)( buf, kf->vki_kf_path, bufsiz ); + } *result = buf; return True; #else @@ -210,7 +213,8 @@ Bool VG_(resolve_filename) ( Int fd, const HChar** result ) * so that filedesc_buf is still valid for fd */ Bool VG_(resolve_filemode) ( Int fd, Int * result ) { - Char *bp, *eb; + Char *bp; + Char *eb; struct vki_kinfo_file *kf; /* Walk though the list. */ @@ -218,14 +222,16 @@ Bool VG_(resolve_filemode) ( Int fd, Int * result ) eb = filedesc_buf + sizeof(filedesc_buf); while (bp < eb) { kf = (struct vki_kinfo_file *)bp; - if (kf->vki_kf_fd == fd) + if (kf->vki_kf_fd == fd) { break; + } bp += kf->vki_kf_structsize; } - if (bp >= eb) + if (bp >= eb) { *result = -1; - else + } else { *result = kf->vki_kf_flags; + } return True; } #else diff --git a/coregrind/m_scheduler/scheduler.c b/coregrind/m_scheduler/scheduler.c index 5ecb39076b..788018c3e9 100644 --- a/coregrind/m_scheduler/scheduler.c +++ b/coregrind/m_scheduler/scheduler.c @@ -754,20 +754,20 @@ void VG_(scheduler_init_phase2) ( ThreadId tid_main, /* Use gcc's built-in setjmp/longjmp. longjmp must not restore signal mask state, but does need to pass "val" through. jumped must be a volatile UWord. */ -#define SCHEDSETJMP(tid, jumped, stmt) \ - do { \ - ThreadState * volatile _qq_tst = VG_(get_ThreadState)(tid); \ - \ - (jumped) = VG_MINIMAL_SETJMP(_qq_tst->sched_jmpbuf); \ - if ((jumped) == ((UWord)0)) { \ - vg_assert(!_qq_tst->sched_jmpbuf_valid); \ - _qq_tst->sched_jmpbuf_valid = True; \ - stmt; \ - } else if (VG_(clo_trace_sched)) \ - VG_(printf)("SCHEDSETJMP(line %d) tid %u, jumped=%lu\n", \ - __LINE__, tid, jumped); \ - vg_assert(_qq_tst->sched_jmpbuf_valid); \ - _qq_tst->sched_jmpbuf_valid = False; \ +#define SCHEDSETJMP(tid, jumped, stmt) \ + do { \ + ThreadState * volatile _qq_tst = VG_(get_ThreadState)(tid); \ + \ + (jumped) = VG_MINIMAL_SETJMP(_qq_tst->sched_jmpbuf); \ + if ((jumped) == ((UWord)0)) { \ + vg_assert(!_qq_tst->sched_jmpbuf_valid); \ + _qq_tst->sched_jmpbuf_valid = True; \ + stmt; \ + } else if (VG_(clo_trace_sched)) \ + VG_(printf)("SCHEDSETJMP(line %d) tid %u, jumped=%lu\n", \ + __LINE__, tid, jumped); \ + vg_assert(_qq_tst->sched_jmpbuf_valid); \ + _qq_tst->sched_jmpbuf_valid = False; \ } while(0) diff --git a/coregrind/m_syswrap/syswrap-amd64-freebsd.c b/coregrind/m_syswrap/syswrap-amd64-freebsd.c index 52eeb808cc..dfbca4d7b5 100644 --- a/coregrind/m_syswrap/syswrap-amd64-freebsd.c +++ b/coregrind/m_syswrap/syswrap-amd64-freebsd.c @@ -1081,7 +1081,7 @@ PRE(sys_fake_sigreturn) { ThreadState* tst; struct vki_ucontext *uc; - int rflags; + ULong rflags; PRINT("sys_sigreturn ( %#" FMT_REGWORD "x )", ARG1); PRE_REG_READ1(long, "sigreturn", @@ -1118,7 +1118,7 @@ PRE(sys_fake_sigreturn) the guest registers written by VG_(sigframe_destroy). */ rflags = LibVEX_GuestAMD64_get_rflags(&tst->arch.vex); SET_STATUS_from_SysRes( VG_(mk_SysRes_amd64_freebsd)( tst->arch.vex.guest_RAX, - tst->arch.vex.guest_RDX, (rflags & 1) != 0 ? True : False) ); + tst->arch.vex.guest_RDX, (rflags & 1U) != 0U ? True : False) ); /* * Signal handler might have changed the signal mask. Respect that. diff --git a/coregrind/m_syswrap/syswrap-x86-freebsd.c b/coregrind/m_syswrap/syswrap-x86-freebsd.c index cd7db23646..e28183d943 100644 --- a/coregrind/m_syswrap/syswrap-x86-freebsd.c +++ b/coregrind/m_syswrap/syswrap-x86-freebsd.c @@ -317,15 +317,16 @@ out: /* Translate a struct modify_ldt_ldt_s to a VexGuestX86SegDescr */ static -void translate_to_hw_format ( /* IN */ void* base, - /* OUT */ VexGuestX86SegDescr* out) +void translate_to_hw_format( /* IN */ void* base, + /* OUT */ VexGuestX86SegDescr* out) { UInt entry_1, entry_2; UInt base_addr = (UInt) base; vg_assert(8 == sizeof(VexGuestX86SegDescr)); - if (0) + if (0) { VG_(printf)("translate_to_hw_format: base %p\n", base ); + } /* Allow LDTs to be cleared by the user. */ if (base == 0) { @@ -372,8 +373,9 @@ static void copy_LDT_from_to ( VexGuestX86SegDescr* src, Int i; vg_assert(src); vg_assert(dst); - for (i = 0; i < VEX_GUEST_X86_LDT_NENT; i++) + for (i = 0; i < VEX_GUEST_X86_LDT_NENT; i++) { dst[i] = src[i]; + } } /* Copy contents between two existing GDTs. */ @@ -383,8 +385,9 @@ static void copy_GDT_from_to ( VexGuestX86SegDescr* src, Int i; vg_assert(src); vg_assert(dst); - for (i = 0; i < VEX_GUEST_X86_GDT_NENT; i++) + for (i = 0; i < VEX_GUEST_X86_GDT_NENT; i++) { dst[i] = src[i]; + } } /* Free this thread's DTs, if it has any. */ @@ -392,10 +395,11 @@ static void deallocate_LGDTs_for_thread ( VexGuestX86State* vex ) { vg_assert(sizeof(HWord) == sizeof(void*)); - if (0) + if (0) { VG_(printf)("deallocate_LGDTs_for_thread: " "ldt = 0x%llx, gdt = 0x%llx\n", vex->guest_LDT, vex->guest_GDT ); + } if (vex->guest_LDT != (HWord)NULL) { free_LDT_or_GDT( (VexGuestX86SegDescr*)vex->guest_LDT ); @@ -432,12 +436,14 @@ static SysRes sys_set_thread_area ( ThreadId tid, Int *idxptr, void *base) Wine). */ for (idx = 1; idx < VEX_GUEST_X86_GDT_NENT; idx++) { if (gdt[idx].LdtEnt.Words.word1 == 0 - && gdt[idx].LdtEnt.Words.word2 == 0) + && gdt[idx].LdtEnt.Words.word2 == 0) { break; + } } - if (idx == VEX_GUEST_X86_GDT_NENT) + if (idx == VEX_GUEST_X86_GDT_NENT) { return VG_(mk_SysRes_Error)( VKI_ESRCH ); + } } else if (idx < 0 || idx == 0 || idx >= VEX_GUEST_X86_GDT_NENT) { /* Similarly, reject attempts to use GDT[0]. */ return VG_(mk_SysRes_Error)( VKI_EINVAL ); |
|
From: Paul F. <pa...@so...> - 2023-01-08 16:52:28
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=1cea0e151b9d62f8c630de72a736dac6a6d51ed1 commit 1cea0e151b9d62f8c630de72a736dac6a6d51ed1 Author: Paul Floyd <pj...@wa...> Date: Sun Jan 8 17:51:37 2023 +0100 Cleanup of warnings, mostly -Wno-unused-but-set-variable Diff: --- configure.ac | 3 +++ drd/tests/Makefile.am | 13 +++++++------ helgrind/tests/Makefile.am | 1 + helgrind/tests/bug322621.cpp | 3 +-- memcheck/tests/Makefile.am | 2 +- memcheck/tests/freebsd/Makefile.am | 4 +++- memcheck/tests/freebsd/scalar.c | 2 +- perf/Makefile.am | 1 + 8 files changed, 18 insertions(+), 11 deletions(-) diff --git a/configure.ac b/configure.ac index 467c98e023..cffb22774b 100755 --- a/configure.ac +++ b/configure.ac @@ -2546,6 +2546,9 @@ AC_GCC_WARNING_SUBST_NO([static-local-in-inline], [FLAG_W_NO_STATIC_LOCAL_IN_INL AC_GCC_WARNING_SUBST_NO([mismatched-new-delete], [FLAG_W_NO_MISMATCHED_NEW_DELETE]) AC_GCC_WARNING_SUBST_NO([infinite-recursion], [FLAG_W_NO_INFINITE_RECURSION]) AC_GCC_WARNING_SUBST_NO([expansion-to-defined], [FLAG_W_NO_EXPANSION_TO_DEFINED]) +AC_GCC_WARNING_SUBST_NO([unused-but-set-variable], [FLAG_W_NO_UNUSED_BUT_SET_VARIABLE]) +AC_GCC_WARNING_SUBST_NO([non-power-of-two-alignment], [FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT]) +AC_GCC_WARNING_SUBST_NO([sign-compare], [FLAG_W_NO_SIGN_COMPARE]) AC_GCC_WARNING_SUBST([write-strings], [FLAG_W_WRITE_STRINGS]) AC_GCC_WARNING_SUBST([empty-body], [FLAG_W_EMPTY_BODY]) diff --git a/drd/tests/Makefile.am b/drd/tests/Makefile.am index 771f47ccce..e3366a18a0 100755 --- a/drd/tests/Makefile.am +++ b/drd/tests/Makefile.am @@ -526,7 +526,8 @@ AM_CXXFLAGS += $(AM_FLAG_M3264_PRI) @FLAG_W_EXTRA@ @FLAG_FALIGNED_NEW@ \ LDADD = -lpthread - +annotate_sem_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ +annotate_rwlock_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ bug322621_SOURCES = bug322621.cpp condvar_SOURCES = condvar.cpp condvar_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x @@ -604,7 +605,7 @@ if HAVE_PTHREAD_BARRIER matinv_LDADD = $(LDADD) -lm endif -rwlock_test_CFLAGS = $(AM_CFLAGS) +rwlock_test_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ if VGCONF_OS_IS_SOLARIS rwlock_test_CFLAGS += -D__EXTENSIONS__ endif @@ -613,16 +614,16 @@ shared_timed_mutex_SOURCES = shared_timed_mutex.cpp shared_timed_mutex_CXXFLAGS = $(AM_CXXFLAGS) -std=c++1y std_atomic_SOURCES = std_atomic.cpp -std_atomic_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x -Wno-sign-compare +std_atomic_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x @FLAG_W_NO_SIGN_COMPARE@ std_list_SOURCES = std_list.cpp -std_list_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x -Wno-sign-compare +std_list_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x @FLAG_W_NO_SIGN_COMPARE@ std_mutex_SOURCES = std_mutex.cpp -std_mutex_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x -Wno-sign-compare +std_mutex_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x @FLAG_W_NO_SIGN_COMPARE@ std_string_SOURCES = std_string.cpp -std_string_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x -Wno-sign-compare +std_string_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x @FLAG_W_NO_SIGN_COMPARE@ # Note: -Wl,--no-as-needed is a workaround for # https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1228201 diff --git a/helgrind/tests/Makefile.am b/helgrind/tests/Makefile.am index 721749f1ce..0a8bd5744b 100755 --- a/helgrind/tests/Makefile.am +++ b/helgrind/tests/Makefile.am @@ -233,6 +233,7 @@ endif if HAVE_BUILTIN_ATOMIC check_PROGRAMS += annotate_rwlock +annotate_rwlock_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ endif AM_CFLAGS += $(AM_FLAG_M3264_PRI) diff --git a/helgrind/tests/bug322621.cpp b/helgrind/tests/bug322621.cpp index 08292dd33a..9e80b53317 100644 --- a/helgrind/tests/bug322621.cpp +++ b/helgrind/tests/bug322621.cpp @@ -71,13 +71,12 @@ int main() pthread_attr_destroy(&attr); int buf = 0; - int res = 0; for (int i = 0; i < NR_RUNS; i++) { std::cerr << "Main at barrier " << i << "\n"; pthread_barrier_wait(&ls_barrier); std::cerr << "Main after barrier " << i << "\n"; buf = buf ^ 1; - res += read_buffer(buf); + (void)read_buffer(buf); } pthread_join(ls_thread,NULL); diff --git a/memcheck/tests/Makefile.am b/memcheck/tests/Makefile.am index 24cfa020cd..53483e55cb 100644 --- a/memcheck/tests/Makefile.am +++ b/memcheck/tests/Makefile.am @@ -539,7 +539,7 @@ reach_thread_register_LDADD = -lpthread thread_alloca_LDADD = -lpthread threadname_LDADD = -lpthread -error_counts_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@ +error_counts_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ execve1_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_NONNULL@ diff --git a/memcheck/tests/freebsd/Makefile.am b/memcheck/tests/freebsd/Makefile.am index 5a6f29549f..daf14f2f8e 100644 --- a/memcheck/tests/freebsd/Makefile.am +++ b/memcheck/tests/freebsd/Makefile.am @@ -119,4 +119,6 @@ endif scalar_CFLAGS = ${AM_CFLAGS} -g -errno_aligned_allocs_CFLAGS = ${AM_CFLAGS} -Wno-non-power-of-two-alignment +errno_aligned_allocs_CFLAGS = ${AM_CFLAGS} @FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT@ + +extattr_CFLAGS = ${AM_CFLAGS} @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ diff --git a/memcheck/tests/freebsd/scalar.c b/memcheck/tests/freebsd/scalar.c index d75a894b09..c6a7ff2d5c 100644 --- a/memcheck/tests/freebsd/scalar.c +++ b/memcheck/tests/freebsd/scalar.c @@ -1586,7 +1586,7 @@ int main(void) GO(SYS_sctp_generic_recvmsg, "6s 4m"); SY(SYS_sctp_generic_recvmsg, x0+1, x0+2, x0+300, x0+4, &fromlen, x0+6, x0+7); FAIL; - iov.iov_base = x0+8; + iov.iov_base = (void*)(x0+8); iov.iov_len = x0+9; GO(SYS_sctp_generic_recvmsg, "6s 6m"); diff --git a/perf/Makefile.am b/perf/Makefile.am index ab504e9375..7f5c6eed00 100644 --- a/perf/Makefile.am +++ b/perf/Makefile.am @@ -30,6 +30,7 @@ AM_CXXFLAGS += -O $(AM_FLAG_M3264_PRI) bz2_CFLAGS = $(AM_CFLAGS) -Wno-inline fbench_CFLAGS = $(AM_CFLAGS) -O2 +ffbench_CFLAGS = $(AM_CFLAGS) @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ ffbench_LDADD = -lm memrw_LDADD = -lpthread |
|
From: Philippe W. <phi...@so...> - 2023-01-08 15:04:43
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=39a063513cf36d0454bc91ca5bec762a66213d99 commit 39a063513cf36d0454bc91ca5bec762a66213d99 Author: Philippe Waroquiers <phi...@sk...> Date: Tue Dec 27 21:51:30 2022 +0100 Implement front end GDB commands for Valgrind gdbserver monitor commands. This commit implements in python a set of GDB commands corresponding to the Valgrind gdbserver monitor commands. Basically, the idea is that one GDB command is defined for each valgrind gdbserver subcommand and will generate and send a monitor command to valgrind. The python code is auto-loaded by GDB as soon as GDB observes that the valgrind preload core shared lib is loaded (e.g. vgpreload_core-amd64-linux.so). This automatic loading is done thanks to the .debug_gdb_scripts section added in vg_preloaded.c file. Sadly, the auto-load only happens once valgrind has started to execute the code of ld that loads this vg_preload file. I have tried 2 approaches to have the python code auto-loaded when attaching at startup to valgrind: * have valgrind gdbserver reporting first to GDB that the executable file is the tool executable (with a .debug_gdb_scripts section) and then reporting the real (guest) executable file. The drawback of this approach is that it triggers a warning/question in GDB according to the GDB setting 'set exec-file-mismatch'. * have valgrind gdbserver pretending to be multiprocess enabled, and report a fake process using the tool executable with a .debug_gdb_scripts section. The drawback of this is that this always creates a second inferior in GDB, which will be confusing. Possibly, we might complete the below message : ==2984378== (action at startup) vgdb me ... ==2984378== ==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem ==2984378== and then give GDB the following command ==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378 ==2984378== --pid is optional if only one valgrind process is running with: ==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins. ==2984378== Alternatively, you might load it before with the GDB command: ==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py The following GDB setting traces the monitor commands sent by a GDB valgrind command to the valgrind gdbserver: set debug valgrind-execute-monitor on How to use the new GDB valgrind commands? ----------------------------------------- The usage of the GDB front end commands is compatible with the monitor command as accepted today by Valgrind. For example, the memcheck monitor command "xb' has the following usage: xb <addr> [<len>] With some piece of code: 'char some_mem [5];' xb can be used the following way: (gdb) print &some_mem (gdb) $2 = (char (*)[5]) 0x1ffefffe8b (gdb) monitor xb 0x1ffefffe8b 5 ff ff ff ff ff 0x4A43040: 0x00 0x00 0x00 0x00 0x00 (gdb) The same action can be done with the new GDB 'memcheck xb' command: (gdb) memcheck xb 0x1ffefffe8b 5 ff ff ff ff ff 0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00 (gdb) At this point, you might ask yourself: "what is the interest ?". Using GDB valgrind commands provides several advantages compared to the valgrind gdbserver monitor commands. Evaluation of arguments by GDB: ------------------------------- For relevant arguments, the GDB command will evaluate its arguments using the usual GDB evaluation logic, for example, instead of printing/copying the address and size of 'some_mem', the following will work: (gdb) memcheck xb &some_mem sizeof(some_mem) ff ff ff ff ff 0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00 (gdb) or: (gdb) p some_mem $4 = "\000\000\000\000" (gdb) memcheck xb &$4 ff ff ff ff ff 0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00 (gdb) This is both easier to use interactively and easier to use in GDB scripts, as you can directly use variable names in the GDB valgrind commands. Command completion by GDB: -------------------------- The usual command completion in GDB will work for the GDB valgrind commands. For example, typing TAB after the letter 'l' in: (gdb) valgrind v.info l will show the 2 "valgrind v.info" subcommands: last_error location (gdb) valgrind v.info l Note that as usual, GDB will recognise a command as soon as it is unambiguous. Usual help and apropos support by GDB: -------------------------------------- The Valgrind gdbserver provides an online help using: (gdb) monitor help However, this gives the help for all monitor commands, and is not searchable. GDB provides a better help and documentation search. For example, the following commands can be used to get various help or search the GDB Valgrind command online documentation: help valgrind help memcheck help helgrind help callgrind help massif to get help about the general valgrind commands or the tool specific commands. Examples of searching the online documentation: apropos valgrind.*location apropos -v validity apropos -v leak User can define aliases for the valgrind commands: -------------------------------------------------- The following aliases are predefined: v and vg for valgrind mc for memcheck hg for helgrind cg for callgrind ms for massif So, the following will be equivalent: (gdb) valgrind v.info location &some_mem (gdb) v v.i lo &some_mem (gdb) alias Vl = valgrind v.info location (gdb) Vl &some_mem Thanks to Hassan El Karouni for the help in factorising the python code common to all valgrind python commands using a decorator. Diff: --- NEWS | 36 ++ callgrind/docs/cl-manual.xml | 11 + coregrind/Makefile.am | 2 + coregrind/m_gdbserver/valgrind-monitor-def.py | 854 ++++++++++++++++++++++++++ coregrind/m_gdbserver/valgrind-monitor.py | 34 + coregrind/vg_preloaded.c | 13 + coregrind/vgdb.c | 3 +- docs/xml/manual-core-adv.xml | 267 +++++++- gdbserver_tests/filter_gdb.in | 4 + helgrind/docs/hg-manual.xml | 37 +- massif/docs/ms-manual.xml | 11 + memcheck/docs/mc-manual.xml | 80 ++- 12 files changed, 1312 insertions(+), 40 deletions(-) diff --git a/NEWS b/NEWS index 3f9e2987de..fb3b05fa9d 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,30 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. * Make the address space limit on FreeBSD amd64 128Gbytes (the same as Linux and Solaris, it was 32Gbytes) +* When GDB is used to debug a program running under valgrind using + the valgrind gdbserver, GDB will automatically load some + python code provided in valgrind defining GDB front end commands + corresponding to the valgrind monitor commands. + These GDB front end commands accept the same format as + the monitor commands directly sent to the Valgrind gdbserver. + These GDB front end commands provide a better integration + in the GDB command line interface, so as to use for example + GDB auto-completion, command specific help, searching for + a command or command help matching a regexp, ... + For relevant monitor commands, GDB will evaluate arguments + to make the use of monitor commands easier. + For example, instead of having to print the address of a variable + to pass it to a subsequent monitor command, the GDB front end + command will evaluate the address argument. It is for example + possible to do: + (gdb) memcheck who_point_at &some_struct sizeof(some_struct) + instead of: + (gdb) p &some_struct + $2 = (some_struct_type *) 0x1130a0 <some_struct> + (gdb) p sizeof(some_struct) + $3 = 40 + (gdb) monitor who_point_at 0x1130a0 40 + * ==================== TOOL CHANGES =================== * Memcheck: @@ -24,11 +48,23 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. Whenever a "delta" leak search is done (i.e. when specifying "new" or "increased" or "changed" in the monitor command), the new loss records have a "new" marker. + - Valgrind now contains python code that defines GDB memcheck + front end monitor commands. See CORE CHANGES. * Helgrind: - The option ---history-backtrace-size=<number> allows to configure the number of entries to record in the stack traces of "old" accesses. Previously, this number was hardcoded to 8. + - Valgrind now contains python code that defines GDB helgrind + front end monitor commands. See CORE CHANGES. + +* Callgrind: + - Valgrind now contains python code that defines GDB callgrind + front end monitor commands. See CORE CHANGES. + +* Massif: + - Valgrind now contains python code that defines GDB massif + front end monitor commands. See CORE CHANGES. * ==================== FIXED BUGS ==================== diff --git a/callgrind/docs/cl-manual.xml b/callgrind/docs/cl-manual.xml index 7b7172ed4b..8b4e50d853 100644 --- a/callgrind/docs/cl-manual.xml +++ b/callgrind/docs/cl-manual.xml @@ -1133,6 +1133,17 @@ Also see <xref linkend="cl-manual.cycles"/>.</para> <title>Callgrind Monitor Commands</title> <para>The Callgrind tool provides monitor commands handled by the Valgrind gdbserver (see <xref linkend="manual-core-adv.gdbserver-commandhandling"/>). +Valgrind python code provides GDB front end commands giving an easier usage of +the callgrind monitor commands (see +<xref linkend="manual-core-adv.gdbserver-gdbmonitorfrontend"/>). To launch a +callgrind monitor command via its GDB front end command, instead of prefixing +the command with "monitor", you must use the GDB <varname>callgrind</varname> +command (or the shorter aliases <varname>cg</varname>). Using the callgrind GDB +front end command provide a more flexible usage, such as auto-completion of the +command by GDB. In GDB, you can use <varname>help callgrind</varname> to get +help about the callgrind front end monitor commands and you can +use <varname>apropos callgrind</varname> to get all the commands mentionning the +word "callgrind" in their name or on-line help. </para> <itemizedlist> diff --git a/coregrind/Makefile.am b/coregrind/Makefile.am index 151f5c2f00..dda0689ddf 100644 --- a/coregrind/Makefile.am +++ b/coregrind/Makefile.am @@ -766,6 +766,8 @@ GDBSERVER_XML_FILES = \ # so as to make sure these get copied into the install tree vglibdir = $(pkglibexecdir) vglib_DATA = $(GDBSERVER_XML_FILES) +vglib_DATA += m_gdbserver/valgrind-monitor.py +vglib_DATA += m_gdbserver/valgrind-monitor-def.py # so as to make sure these get copied into the tarball EXTRA_DIST += $(GDBSERVER_XML_FILES) diff --git a/coregrind/m_gdbserver/valgrind-monitor-def.py b/coregrind/m_gdbserver/valgrind-monitor-def.py new file mode 100644 index 0000000000..da617cb850 --- /dev/null +++ b/coregrind/m_gdbserver/valgrind-monitor-def.py @@ -0,0 +1,854 @@ +# This file is part of Valgrind, a dynamic binary instrumentation +# framework. + +# Copyright (C) 2022-2022 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 +# published by the Free Software Foundation; either version 2 of the +# License, or (at your option) any later version. + +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program; if not, see <http://www.gnu.org/licenses/>. + +# The GNU General Public License is contained in the file COPYING. + +""" +This file defines a series of gdb commands and subcommands to help interfacing +gdb with the Valgrind gdbserver. + +!!! This only works with GDB version >= 9.1, as some command names contains +a dot character only allowed from this version onwards. + +Type "help valgrind" to get help about the top of the command hierarchy. +""" + +from typing import Callable +from enum import Enum +import re + +class _Debug_Valgrind_Execute_Monitor(gdb.Parameter): + """Set valgrind monitor command execution debugging. +Usage: set debug valgrind-execute-monitor [on|off]""" + def __init__(self): + super().__init__("debug valgrind-execute-monitor", + gdb.COMMAND_MAINTENANCE, + gdb.PARAM_BOOLEAN) + +Debug_Valgrind_Execute_Monitor = _Debug_Valgrind_Execute_Monitor() + +def gdb_execute_monitor(monitor_command : str, from_tty : bool) -> None: + """Execute the given monitor command.""" + cmd = "monitor " + monitor_command + if Debug_Valgrind_Execute_Monitor.value: + print('[valgrind-execute-monitor] sending "' + cmd + '" to valgrind') + try: + gdb.execute (cmd, from_tty) + except Exception as inst: + if monitor_command == "v.kill" and str(inst).find('Remote connection closed') >= 0: + print('Remote connection closed') + else: + print('Error sending "' + monitor_command + '" to valgrind: '+ str(inst)) + +class Valgrind_Command(gdb.Command): + """Parent class for all Valgrind commands.""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + """Generic Valgrind Command invoke method to override if needed.""" + # print("generic invoke", self.mname) + if arg_str: + gdb_execute_monitor (self.mname + " " + arg_str, from_tty) + else: + gdb_execute_monitor (self.mname, from_tty) + +def Vinit(toolname : str, + mname : str, + command_class : Enum, + completer_class : Enum, + prefix : bool) -> Callable[[Valgrind_Command], + Valgrind_Command]: + """Class decorator to initialise and register a Valgrind_Command class. +MNAME is the Valgrind monitor name string for this command. +The gdb command is the concatenation of TOOLNAME and MNAME. +TOOLNAME is valgrind for the general valgrind commands.""" + def instantiate(GDB_Command : Valgrind_Command) -> Valgrind_Command: + def adhoc_init (self): + # print("initializing", GDB_Command) + if completer_class: + super(GDB_Command, self).__init__(name = toolname + " " + mname, + command_class = command_class, + completer_class = completer_class, + prefix = prefix) + else: + super(GDB_Command, self).__init__(name = toolname + " " + mname, + command_class = command_class, + prefix = prefix) + self.toolname=toolname + self.mname=mname + GDB_Command.__init__ = adhoc_init + GDB_Command() # register the command + return GDB_Command + return instantiate + +def build_name(command : Valgrind_Command) -> str: + """Returns the GDB full name for the given COMMAND.""" + if command.mname: + return command.toolname + ' ' + command.mname + else: + return command.toolname + +def build_help(command : Valgrind_Command) -> str: + """Returns a string to ask help for the given COMMAND.""" + return "help " + build_name(command) + +def build_type_help(command : Valgrind_Command) -> str: + """Returns a string giving what to type to get helps about the given command""" + return 'Type "' + build_help(command) + '"' + +class Valgrind_Prefix_Command(Valgrind_Command): + """Parent class for all Valgrind prefix commands.""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + """Generic Valgrind prefix Command invoke method to override if needed.""" + # print("generic prefix invoke", self.mname) + if arg_str: + # If it is not a recognised sub-command, raise an error. + raise gdb.GdbError(('Undefined ' + build_name (self) + + ' command: "' + arg_str + '".\n' + + build_type_help(self))) + else: + gdb.execute (build_help(self), from_tty) + +class Valgrind_Prefix_Exec_Command(Valgrind_Prefix_Command): + """Parent class for all Valgrind prefix commands that can be executed without subcommands.""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + """Invoke for a prefix command that can be executed.""" + if arg_str: + super().invoke(arg_str, from_tty) + else: + gdb_execute_monitor (self.mname, from_tty) + +def eval_execute(command : Valgrind_Command, + arg_str : str, + arg_opt : bool, arg_descr : str, format_fn, + from_tty : bool) -> None: + """Evaluates ARG_STR, format the result with FORMAT_FN and +executes the monitor command COMMAND.mname + FORMAT_FN(evaluated ARG_STR). +ARG_OPT True indicates the argument is optional. +ARG_DESCR is used in error messages.""" + if arg_str: + eval_arg_str = gdb.parse_and_eval (arg_str) + gdb_execute_monitor (command.mname + " " + format_fn(eval_arg_str), from_tty) + elif arg_opt: + gdb_execute_monitor (command.mname, from_tty) + else: + raise gdb.GdbError(('Argument "' + arg_descr + '" required.\n' + + build_type_help(command))) + +def eval_execute_2(command : Valgrind_Command, + arg_str : str, + arg1_opt : bool, arg1_descr : str, format_fn1, + arg2_opt : bool, arg2_descr : str, format_fn2, + from_tty : bool) -> None: + """Like eval_execute but allowing 2 arguments to be extracted from ARG_STR). +The second argument starts after the first space in ARG_STR.""" + if arg1_opt and not arg2_opt: + raise gdb.GdbError(('Cannot have arg1_opt True and arg2_opt False' + + ' in definition of ' + + build_name(command))) + if arg_str: + arg_str_v = arg_str.split(' ', 1); + eval_arg1_str = gdb.parse_and_eval (arg_str_v[0]) + if len(arg_str_v) <= 1: + if arg2_opt: + gdb_execute_monitor (command.mname + " " + format_fn1(eval_arg1_str), from_tty) + else: + raise gdb.GdbError(('Argument 2 "' + arg2_descr + '" required.\n' + + build_type_help(command))) + else: + eval_arg2_str = gdb.parse_and_eval (arg_str_v[1]) + gdb_execute_monitor (command.mname + + " " + format_fn1(eval_arg1_str) + + " " + format_fn1(eval_arg2_str), + from_tty) + elif arg1_opt and arg2_opt: + gdb_execute_monitor (command.mname, from_tty) + else: + raise gdb.GdbError(('Argument 1 "' + arg1_descr + '" required.\n' + + ('' if arg2_opt + else 'Argument 2 "' + arg2_descr + '" required.\n') + + build_type_help(command))) + +def def_alias(alias : str, command_name : str) -> None: + """Defines an alias ALIAS = COMMAND_NAME. +Traps the error if ALIAS is already defined (so as to be able to source +this file again).""" + d = "alias " + alias + ' = ' + command_name + try: + gdb.execute (d) + except Exception as inst: + print('"' + d + '" : '+ str(inst)) + +class Valgrind_ADDR(Valgrind_Command): + """Common class for Valgrind commands taking ADDR arg.""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + eval_execute(self, arg_str, + False, "ADDR (address expression)", hex, + from_tty) + +class Valgrind_ADDR_opt(Valgrind_Command): + """Common class for Valgrind commands taking [ADDR] arg.""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + eval_execute(self, arg_str, + True, "ADDR (address expression)", hex, + from_tty) + +class Valgrind_ADDR_LEN_opt(Valgrind_Command): + """Common class for Valgrind commands taking ADDR and [LEN] args. +For compatibility reason with the Valgrind gdbserver monitor command, +we detect and accept usages such as 0x1234ABCD[10].""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + if re.fullmatch("^0x[0123456789ABCDEFabcdef]+\[[^\[\]]+\]$", arg_str): + arg_str = arg_str.replace("[", " ") + arg_str = arg_str.replace("]", " ") + eval_execute_2(self, arg_str, + False, "ADDR (address expression)", hex, + True, "LEN (integer length expression)", str, + from_tty) + +############# The rest of this file defines first the valgrind general commands +# then the tool specific commands. +# The commands are defined in the same order as produced by +# (gdb) monitor help debug + +############# valgrind general commands. + +###### Top of the hierarchy of the valgrind general commands. +@Vinit("valgrind", "", gdb.COMMAND_SUPPORT, gdb.COMPLETE_COMMAND, True) +class Valgrind_Monitor_Command(Valgrind_Prefix_Command): + """Front end GDB command for Valgrind gdbserver monitor commands. +Usage: valgrind VALGRIND_MONITOR_COMMAND [ARG...] +VALGRIND_MONITOR_COMMAND is a valgrind subcommand, matching a +gdbserver Valgrind monitor command. +ARG... are optional arguments. They depend on the VALGRIND_MONITOR_COMMAND.) + +Type "help memcheck" or "help mc" for memcheck specific commands. +Type "help helgrind" or "help hg" for helgrind specific commands. +Type "help callgrind" or "help cg" for callgrind specific commands. +Type "help massif" or "help ms" for massif specific commands. +""" + +def_alias("vg", "valgrind") +def_alias("v", "valgrind") # To avoid 'v' reported as ambiguous for 'vg' and 'valgrind' ! + +@Vinit("valgrind", "help", gdb.COMMAND_SUPPORT, gdb.COMPLETE_COMMAND, True) +class Valgrind_Help_Command(Valgrind_Prefix_Exec_Command): + """Ask Valgrind gdbserver to output the help for its monitor commands. +Usage: valgrind help +This shows the help string reported by the Valgrind gdbserver. +Type "help valgrind" to get help about the GDB front end commands interfacing +to the Valgrind gdbserver monitor commands. +""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + """Invoke for a prefix command that can be executed.""" + if arg_str: + super().invoke(arg_str, from_tty) + else: + gdb_execute_monitor (self.mname, from_tty) + +@Vinit("valgrind", "help debug", gdb.COMMAND_SUPPORT, gdb.COMPLETE_NONE, False) +class Valgrind_Help_Debug_Command(Valgrind_Command): + """Ask Valgrind gdbserver to output the help for its monitor commands (including debugging commands). +Usage: valgrind help debug +This shows the help string reported by the Valgrind gdbserver. +Type "help valgrind" to get help about the GDB front end commands interfacing +to the Valgrind gdbserver monitor commands. +""" + +@Vinit("valgrind", "v.wait", gdb.COMMAND_OBSCURE, gdb.COMPLETE_EXPRESSION, False) +class Valgrind_Wait_Command(Valgrind_Command): + """Have Valgrind gdbserver sleeping for MS (default 0) milliseconds. +Usage: valgrind v.wait [MS] +MS is an integer expression evaluated by GDB. +""" + def invoke(self, arg_str : str, from_tty: bool) -> None: + eval_execute(self, arg_str, + True, "MS (integer expression in milliseconds)", str, + from_tty) + +@Vinit("valgrind", "v.info", gdb.COMMAND_STATUS, gdb.COMPLETE_COMMAND, True) +class Valgrind_Info_Command(Valgrind_Prefix_Command): + """Get various information about Valgrind gdbserver. +Usage: valgrind v.info WHAT [ARG...] +WHAT is the v.info subcommand, specifying the type of information requested. +ARG are optional arguments, depending on the WHAT subcommand. +""" + +@Vinit("valgrind", "v.info all_errors", gdb.COMMAND_STATUS, gdb.COMPLETE_NONE, False) +class Valgrind_Info_All_Errors_Command(Valgrind_Command): + """Show all errors found so far by Valgrind. +Usage: valgrind v.info all_errors +""" + +@Vinit("valgrind", "v.info last_error", gdb.COMMAND_STATUS, gdb.COMPLETE_NONE, False) +class Valgrind_Info_Last_Error_Command(Valgrind_Command): + """Show last error found by Valgrind. +Usage: valgrind v.info last_error +""" + +@Vinit("valgrind", "v.info location", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Valgrind_Info_Location_Command(Valgrind_ADDR): + """Show information known by Valgrind about location ADDR. +Usage: valgrind v.info location ADDR +ADDR is an address expression evaluated by GDB. +""" + +@Vinit("valgrind", "v.info n_errs_found", gdb.COMMAND_STATUS, gdb.COMPLETE_NONE, False) +class Valgrind_Info_N_Errs_Found_Command(Valgrind_Command): + """Show the nr of errors found so far by Valgrind and the given MSG. +Usage: valgrind v.info n_errs_found [MSG] +The optional MSG is made of all what follows n_errs_found and is not evaluated. +""" + +@Vinit("valgrind", "v.info open_fds", gdb.COMMAND_DATA, gdb.COMPLETE_NONE, False) +class Valgrind_Info_Open_Fds_Command(Valgrind_Command): + """Show open file descriptors tracked by Valgrind (only if --track-fds=yes). +Usage: valgrind v.info open_fds +""" + +@Vinit("valgrind", "v.kill", gdb.COMMAND_RUNNING, gdb.COMPLETE_NONE, False) +class Valgrind_Kill_Command(Valgrind_Command): + """Instruct valgrind gdbserver to kill the valgrind process. +Usage: valgrind v.kill +""" + +@Vinit("valgrind", "v.clo", gdb.COMMAND_RUNNING, gdb.COMPLETE_NONE, False) +class Valgrind_Clo_Command(Valgrind_Command): + """Change one or more Valgrind dynamic command line options. +Usage: valgrind v.clo [VALGRIND_OPTION]... +VALGRIND_OPTION is the command line option to change. +Example: (gdb) valgrind v.clo --stats=yes --show-below-main=yes + +Without VALGRIND_OPTION, shows the dynamically changeable options. +""" + +@Vinit("valgrind", "v.set", gdb.COMMAND_STATUS, gdb.COMPLETE_COMMAND, True) +class Valgrind_Set_Command(Valgrind_Prefix_Command): + """Modify various setting of Valgrind gdbserver. +Usage: valgrind v.set WHAT [ARG]... +WHAT is the v.set subcommand, specifying the setting to change. +ARG are optional arguments, depending on the WHAT subcommand. +""" + +@Vinit("valgrind", "v.set gdb_output", gdb.COMMAND_STATUS, gdb.COMPLETE_NONE, False) +class Valgrind_Set_Gdb_Output_Command(Valgrind_Command): + """Set Valgrind output to gdb. +Usage: valgrind v.set gdb_output +""" + +@Vinit("valgrind", "v.set log_output", gdb.COMMAND_STATUS, gdb.COMPLETE_NONE, False) +class Valgrind_Set_Log_Output_Command(Valgrind_Command): + """Set Valgrind output to Valgrind log. +Usage: valgrind v.set log_output +""" + +@Vinit("valgrind", "v.set mixed_output", gdb.COMMAND_STATUS, gdb.COMPLETE_NONE, False) +class Valgrind_Set_Mixed_Output_Command(Valgrind_Command): + """Set Valgrind output to Valgrind log, interactive output to gdb. +Usage: valgrind v.set mixed_output +""" + +@Vinit("valgrind", "v.set merge-recursive-frames", gdb.COMMAND_STATUS, gdb.COMPLETE_EXPRESSION, False) +class Valgrind_Set_Merge_Recursive_Frames_Command(Valgrind_Command): + """Set the number of frames for recursive calls merging in Valgrind stacktraces. +Usage: valgrind v.set merge-recursive-frames NUM +NUM is an integer expression evaluated by GDB. +""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + eval_execute(self, arg_str, + False, "NUM (number of frames for recursive calls merging)", + str, + from_tty) + +@Vinit("valgrind", "v.set vgdb-error", gdb.COMMAND_RUNNING, gdb.COMPLETE_EXPRESSION, False) +class Valgrind_Set_Vgdb_Error_Command(Valgrind_Command): + """Set the number of errors at which Valgrind gdbserver gives control to gdb. +Usage: valgrind v.set vgdb-error NUM +NUM is an integer expression evaluated by GDB. +""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + eval_execute(self, arg_str, + False, "NUM (number of errors)", + str, + from_tty) + +@Vinit("valgrind", "v.do", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_COMMAND, True) +class Valgrind_Do_Command(Valgrind_Prefix_Command): + """Ask Valgrind gdbserver to do an internal/maintenance action. +Usage: valgrind v.do WHAT +WHAT is the valgrind v.do subcommand, specifying the type of action requested. +""" + +@Vinit("valgrind", "v.do expensive_sanity_check_general", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Do_Expensive_Sanity_Check_General_Command(Valgrind_Command): + """Do an expensive Valgrind sanity check now. +Usage: valgrind v.do expensive_sanity_check_general +""" + +@Vinit("valgrind", "v.info gdbserver_status", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Info_Gdbserver_Status_Command(Valgrind_Command): + """Show gdbserver status. +Usage: valgrind v.info gdbserver_status +""" + +@Vinit("valgrind", "v.info memory", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_COMMAND, True) +class Valgrind_Info_Memory_Status_Command(Valgrind_Prefix_Exec_Command): + """Show valgrind heap memory stats. +Usage: valgrind v.info memory +""" + +@Vinit("valgrind", "v.info memory aspacemgr", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Info_Memory_Aspacemgr_Command(Valgrind_Command): + """Show Valgrind heap memory stats and show Valgrind segments on log output. +Usage: valgrind v.info memory aspacemgr +""" + +@Vinit("valgrind", "v.info exectxt", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Info_Exectxt_Command(Valgrind_Command): + """Show stacktraces and stats of all execontexts record by Valgrind. +Usage: valgrind v.info exectxt +""" + +@Vinit("valgrind", "v.info scheduler", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Info_Scheduler_Command(Valgrind_Command): + """Show Valgrind thread state and stacktrace. +Usage: valgrind v.info scheduler +""" + +@Vinit("valgrind", "v.info stats", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Info_Stats_Command(Valgrind_Command): + """Show various Valgrind and tool stats. +Usage: valgrind v.info stats +""" + +@Vinit("valgrind", "v.info unwind", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_EXPRESSION, False) +class Valgrind_Info_Unwind_Command(Valgrind_ADDR_LEN_opt): + """Show unwind debug info for ADDR .. ADDR+LEN. +Usage: valgrind v.info unwind ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. +""" + +@Vinit("valgrind", "v.set debuglog", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_EXPRESSION, False) +class Valgrind_Set_Debuglog_Command(Valgrind_Command): + """Set Valgrind debug log level to LEVEL. +Usage: valgrind v.set LEVEL +LEVEL is an integer expression evaluated by GDB. +""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + eval_execute(self, arg_str, + False, "LEVEL (valgrind debug log level)", + str, + from_tty) +@Vinit("valgrind", "v.set hostvisibility", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_COMMAND, True) +class Valgrind_Set_Hostvisibility_Command(Valgrind_Prefix_Exec_Command): + """Set visibility of the internal Valgrind 'host' state. +Without arguments, enables the host visibility. +Host visibility allows to examine with GDB the internal status and memory +of Valgrind. +Usage: valgrind v.set hostvisibility +""" + +@Vinit("valgrind", "v.set hostvisibility yes", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Set_Hostvisibility_Yes_Command(Valgrind_Command): + """Enable visibility of the internal Valgrind 'host' state. +Usage: valgrind v.set hostvisibility yes +See "help v.set hostvisibility". +""" + +@Vinit("valgrind", "v.set hostvisibility no", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_NONE, False) +class Valgrind_Set_Hostvisibility_No_Command(Valgrind_Command): + """Disable visibility of the internal Valgrind 'host' state. +Usage: valgrind v.set hostvisibility no +See "help v.set hostvisibility". +""" + +def base2(value : int) -> str: + """Image of value in base 2 prefixed with 0b.""" + "0b" + "{0:b}".format(value) + +@Vinit("valgrind", "v.translate", gdb.COMMAND_MAINTENANCE, gdb.COMPLETE_EXPRESSION, False) +class Valgrind_Translate_Command(Valgrind_Command): + """Show the translation of instructions at ADDR with TRACEFLAGS. +Usage: valgrind v.translate ADDR [TRACEFLAG] +For TRACEFLAG values, type in shell "valgrind --help-debug". +An additional flag 0b100000000 allows one to show gdbserver instrumentation. +ADDR is an address expression evaluated by GDB. +TRACEFLAG is an integer expression (used as a bitmask) evaluated by GDB. +""" + def invoke(self, arg_str : str, from_tty : bool) -> None: + eval_execute_2(self, arg_str, + False, "ADDR (address expression)", hex, + True, "TRACEFLAGS (bit mask expression)", base2, + from_tty) + +############# memcheck commands. + +###### Top of the hierarchy of the memcheck commands. +@Vinit("memcheck", "", gdb.COMMAND_SUPPORT, gdb.COMPLETE_COMMAND, True) +class Memcheck_Command(Valgrind_Prefix_Command): + """Front end GDB command for Valgrind memcheck gdbserver monitor commands. +Usage: memcheck MEMCHECK_MONITOR_COMMAND [ARG...] +MEMCHECK_MONITOR_COMMAND is a memcheck subcommand, matching +a gdbserver Valgrind memcheck monitor command. +ARG... are optional arguments. They depend on the MEMCHECK_MONITOR_COMMAND. +""" + +def_alias("mc", "memcheck") + +@Vinit("memcheck", "xtmemory", gdb.COMMAND_DATA, gdb.COMPLETE_FILENAME, False) +class Memcheck_Xtmemory_Command(Valgrind_Command): + """Dump xtree memory profile in FILENAME (default xtmemory.kcg.%p.%n). +Usage: memcheck xtmemory [FILENAME] + +Example: (gdb) memcheck xtmemory my_program_xtree.kcg +""" + +@Vinit("memcheck", "xb", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Xb_Command(Valgrind_ADDR_LEN_opt): + """Print validity bits for LEN (default 1) bytes at ADDR. + bit values 0 = valid, 1 = invalid, __ = unaddressable byte +Prints the bytes values below the corresponding validity bits +in a layout similar to the gdb command 'x /LENxb ADDR +Usage: memcheck xb ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck xb &p sizeof(p) +""" + +@Vinit("memcheck", "get_vbits", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Get_Vbits_Command(Valgrind_ADDR_LEN_opt): + """Print validity bits for LEN (default 1) bytes at ADDR. + bit values 0 = valid, 1 = invalid, __ = unaddressable byte +Usage: memcheck get_vbits ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck get_vbits &p sizeof(p) + +Note: the command 'memcheck xb ADDR [LEN]' prints the value +and validity bits of ADDR [LEN] bytes in an easier to read format. +""" + +@Vinit("memcheck", "make_memory", gdb.COMMAND_DATA, gdb.COMPLETE_COMMAND, True) +class Memcheck_Make_Memory_Command(Valgrind_Prefix_Command): + """Prefix command to change memory accessibility.""" + +@Vinit("memcheck", "make_memory noaccess", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Make_Memory_Noaccess_Command(Valgrind_ADDR_LEN_opt): + """Mark LEN (default 1) bytes at ADDR as noaccess. +Usage: memcheck make_memory noaccess ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck make_memory noaccess &p sizeof(p) +""" + +@Vinit("memcheck", "make_memory undefined", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Make_Memory_Undefined_Command(Valgrind_ADDR_LEN_opt): + """Mark LEN (default 1) bytes at ADDR as undefined. +Usage: memcheck make_memory undefined ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck make_memory undefined &p sizeof(p) +""" + +@Vinit("memcheck", "make_memory defined", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Make_Memory_Defined_Command(Valgrind_ADDR_LEN_opt): + """Mark LEN (default 1) bytes at ADDR as defined. +Usage: memcheck make_memory defined ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck make_memory defined &p sizeof(p) +""" + +@Vinit("memcheck", "make_memory Definedifaddressable", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Make_Memory_Definedifaddressable_Command(Valgrind_ADDR_LEN_opt): + """Mark LEN (default 1) bytes at ADDR as Definedifaddressable. +Usage: memcheck make_memory Definedifaddressable ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck make_memory Definedifaddressable &p sizeof(p) +""" + +@Vinit("memcheck", "check_memory", gdb.COMMAND_DATA, gdb.COMPLETE_COMMAND, True) +class Memcheck_Check_Memory_Command(Valgrind_Prefix_Command): + """Command to check memory accessibility.""" + +@Vinit("memcheck", "check_memory addressable", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Check_Memory_Addressable_Command(Valgrind_ADDR_LEN_opt): + """Check that LEN (default 1) bytes at ADDR are addressable. +Usage: memcheck check_memory addressable ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck check_memory addressable &p sizeof(p) +""" + +@Vinit("memcheck", "check_memory defined", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Check_Memory_Defined_Command(Valgrind_ADDR_LEN_opt): + """Check that LEN (default 1) bytes at ADDR are defined. +Usage: memcheck check_memory defined ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) memcheck check_memory defined &p sizeof(p) +""" + +@Vinit("memcheck", "leak_check", gdb.COMMAND_DATA, gdb.COMPLETE_NONE, False) +class Memcheck_Leak_Check_Command(Valgrind_Command): + """Execute a memcheck leak search. +Usage: leak_check [full*|summary|xtleak] + [kinds KIND1,KIND2,...|reachable|possibleleak*|definiteleak] + [heuristics HEUR1,HEUR2,...] + [new|increased*|changed|any] + [unlimited*|limited MAX_LOSS_RECORDS_OUTPUT] + * = defaults + +full: outputs stacktraces of all leaks followed by a summary. +summary: outputs only the leak summary. +xtleak: produce an xtree full leak result in xtleak.kcg.%p.%n + +KIND indicates which kind of leaks to report, and is one of: + definite indirect possible reachable all none + +HEUR indicates an heuristic to activate when doing leak search and is one of: + stdstring length64 newarray multipleinheritance all none* + +new: only outputs the new leak loss records since last leak search. +increased: only outputs the leak loss records with an increase since + last leak search. +changed: also outputs the leak loss records with a decrease. +any: also outputs the leak loss records that did not change. + +unlimited: outputs all matching loss records. +limited: outputs only the first matching MAX_LOSS_RECORDS_OUTPUT. + +This command auto-completes the user input by providing the full list of +keywords still relevant according to what is already typed. For example, if the +"summary" keyword has been provided, the following TABs to auto-complete other +items will not propose anymore "full" and "xtleak". Note that KIND and HEUR +values are not part of auto-completed elements. + +Examples: (gdb) memcheck leak_check + (gdb) memcheck leak_check summary any + (gdb) memcheck leak_check full kinds indirect,possible + (gdb) memcheck leak_check full reachable any limited 100 + + """ + + def complete(self, text, word): + # print('/' + text + ' ' + word + '/\n') + leak_check_mode = ["full", "summary", "xtleak"] + leak_kind = ["kinds", "reachable", "possibleleak", "definiteleak"] + leak_heuristic = ["heuristics"] + leak_check_delta_mode = ["new", "increased", "changed", "any"] + leak_check_loss_record_limit = ["unlimited", "limited"] + kwd_lists = [leak_check_mode, leak_kind, leak_heuristic, + leak_check_delta_mode, leak_check_loss_record_limit] + # Build the list of still allowed keywords. + # We append all the keywords of a list unless we find already one + # existing word in text that starts with the first letter of a keyword + # of the list. Checking the first letter is ok (currently!) + # as all keywords of leak_check monitor command starts with a different + # letter. + keywords = [] + command_words = text.split() + for kwd_list in kwd_lists: + list_ok = True + # print('list:/' + str(kwd_list) + '/') + for kwd in kwd_list: + for command_word in command_words: + # print('word:/' + command_word + '/' + kwd) + if kwd[0] == command_word[0]: + # print("setting to false") + list_ok = False + if (kwd.startswith(word) and + word != kwd + and kwd not in command_words + ): + # print('/' + word + '/' + kwd + '/') + keywords.append(kwd) + if list_ok: + for kwd in kwd_list: + keywords.append(kwd) + result = [] + for keyword in keywords: + if keyword.startswith(word): + result.append(keyword) + return result + +@Vinit("memcheck", "block_list", gdb.COMMAND_DATA, gdb.COMPLETE_NONE, False) +class Memcheck_Block_List_Command(Valgrind_Command): + """Show the list of blocks for a leak search loss record. +Usage: memcheck block_list LOSS_RECORD_NR|LOSS_RECORD_NR_FROM..LOSS_RECORD_NR_TO + unlimited*|limited MAX_BLOCKS + [heuristics HEUR1,HEUR2,...] + * = defaults + +After a leak search, use block_list to show the list of blocks matching a loss +record or matching a range of loss records. + +unlimited: outputs all blocks matching the selected loss records. +limited: outputs only the first matching MAX_BLOCKS. + +Use heuristics to only output the blocks found via one of the given heuristics, +where HEUR is one of: + stdstring length64 newarray multipleinheritance all none* + """ + +@Vinit("memcheck", "who_points_at", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Memcheck_Who_Points_At_Command(Valgrind_ADDR_LEN_opt): + """Show places pointing inside LEN (default 1) bytes at ADDR. +Usage: memcheck who_points_at ADDR [MEN] +With LEN 1, only shows "start pointers" pointing exactly to ADDR. +With LEN > 1, will also show "interior pointers" +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. +""" + +############# helgrind commands. + +###### Top of the hierarchy of the helgrind commands. +@Vinit("helgrind", "", gdb.COMMAND_SUPPORT, gdb.COMPLETE_COMMAND, True) +class Helgrind_Command(Valgrind_Prefix_Command): + """Front end GDB command for Valgrind helgrind gdbserver monitor commands. +Usage: helgrind HELGRIND_MONITOR_COMMAND [ARG...] +HELGRIND_MONITOR_COMMAND is a helgrind subcommand, matching +a gdbserver Valgrind helgrind monitor command. +ARG... are optional arguments. They depend on the HELGRIND_MONITOR_COMMAND. +""" + +def_alias("hg", "helgrind") + +@Vinit("helgrind", "info", gdb.COMMAND_STATUS, gdb.COMPLETE_COMMAND, True) +class Helgrind_Info_Command(Valgrind_Prefix_Command): + """Get various information about helgrind tool status. +Usage: helgrind info WHAT +WHAT is the helgrind info subcommand, specifying the type of information requested. +""" + +@Vinit("helgrind", "info locks", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Helgrind_Info_Locks_Command(Valgrind_ADDR_opt): + """Show the status of one or all locks recorded by helgrind. +Usage: helgrind info locks [ADDR] +ADDR is an address expression evaluated by GDB. +When ADDR is provided, shows the status of the lock located at ADDR, +otherwise shows the status of all locks. +""" + +@Vinit("helgrind", "accesshistory", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) +class Helgrind_Accesshistory_Command(Valgrind_ADDR_LEN_opt): + """Show access history recorded for LEN (default 1) bytes at ADDR. +Usage: helgrind accesshistory ADDR [LEN] +ADDR is an address expression evaluated by GDB. +LEN is an integer expression evaluated by GDB. + +Example: (gdb) helgrind accesshistory &p sizeof(p) +""" + +@Vinit("helgrind", "xtmemory", gdb.COMMAND_DATA, gdb.COMPLETE_FILENAME, False) +class Helgrind_Xtmemory_Command(Valgrind_Command): + """Dump xtree memory profile in FILENAME (default xtmemory.kcg.%p.%n). +Usage: helgrind xtmemory [FILENAME] + +Example: (gdb) helgrind xtmemory my_program_xtree.kcg +""" + +############# callgrind commands. + +###### Top of the hierarchy of the callgrind commands. +@Vinit("callgrind", "", gdb.COMMAND_SUPPORT, gdb.COMPLETE_COMMAND, True) +class Callgrind_Command(Valgrind_Prefix_Command): + """Front end GDB command for Valgrind callgrind gdbserver monitor commands. +Usage: callgrind CALLGRIND_MONITOR_COMMAND [ARG...] +CALLGRIND_MONITOR_COMMAND is a callgrind subcommand, matching +a gdbserver Valgrind callgrind monitor command. +ARG... are optional arguments. They depend on the CALLGRIND_MONITOR_COMMAND. +""" + +def_alias("cg", "callgrind") + +@Vinit("callgrind", "dump", gdb.COMMAND_DATA, gdb.COMPLETE_COMMAND, False) +class Callgrind_Dump_Command(Valgrind_Command): + """Dump the callgrind counters. +Usage: callgrind dump [DUMP_HINT] +DUMP_HINT is a message stored in the resulting callgrind dump file. +""" + +@Vinit("callgrind", "zero", gdb.COMMAND_DATA, gdb.COMPLETE_COMMAND, False) +class Callgrind_Zero_Command(Valgrind_Command): + """Set the callgrind counters to zero. +Usage: callgrind zero +""" + +@Vinit("callgrind", "status", gdb.COMMAND_STATUS, gdb.COMPLETE_NONE, False) +class Callgrind_Status_Command(Valgrind_Command): + """Show the status of callgrind. +Usage: callgrind status +""" + +@Vinit("callgrind", "instrumentation", gdb.COMMAND_STATUS, gdb.COMPLETE_COMMAND, False) +class Callgrind_Instrumentation_Command(Valgrind_Command): + """Get or set the callgrind instrumentation state. +Usage: callgrind instrumentation [on|off] +Without argument, shows the current state of instrumentation, +otherwise changes the instrumentation state to the given argument. +""" + +############# massif commands. + +###### Top of the hierarchy of the massif commands. +@Vinit("massif", "", gdb.COMMAND_SUPPORT, gdb.COMPLETE_COMMAND, True) +class Massif_Command(Valgrind_Prefix_Command): + """Front end GDB command for Valgrind massif gdbserver monitor commands. +Usage: massif MASSIF_MONITOR_COMMAND [ARG...] +MASSIF_MONITOR_COMMAND is a massif subcommand, matching +a gdbserver Valgrind massif monitor command. +ARG... are optional arguments. They depend on the MASSIF_MONITOR_COMMAND. +""" + +def_alias("ms", "massif") + +@Vinit("massif", "snapshot", gdb.COMMAND_DATA, gdb.COMPLETE_FILENAME, False) +class Massif_Dump_Command(Valgrind_Command): + """Take a massif snapshot in FILENAME (default massif.vgdb.out). +Usage: massif snapshot [FILENAME] +""" + +@Vinit("massif", "detailed_snapshot", gdb.COMMAND_DATA, gdb.COMPLETE_FILENAME, False) +class Massif_Dump_Command(Valgrind_Command): + """Take a massif detailed snapshot in FILENAME (default massif.vgdb.out). +Usage: massif detailed_snapshot [FILENAME] +""" + +@Vinit("massif", "all_snapshots", gdb.COMMAND_DATA, gdb.COMPLETE_FILENAME, False) +class Massif_Dump_Command(Valgrind_Command): + """Save all snapshot(s) taken so far in FILENAME (default massif.vgdb.out). +Usage: massif all_snapshots [FILENAME] +""" + +@Vinit("massif", "xtmemory", gdb.COMMAND_DATA, gdb.COMPLETE_FILENAME, False) +class Massic_Xtmemory_Command(Valgrind_Command): + """Dump xtree memory profile in FILENAME (default xtmemory.kcg.%p.%n). +Usage: massif xtmemory [FILENAME] + +Example: (gdb) massif xtmemory my_program_xtree.kcg +""" diff --git a/coregrind/m_gdbserver/valgrind-monitor.py b/coregrind/m_gdbserver/valgrind-monitor.py new file mode 100644 index 0000000000..713319d18e --- /dev/null +++ b/coregrind/m_gdbserver/valgrind-monitor.py @@ -0,0 +1,34 @@ +# This file is part of Valgrind, a dynamic binary instrumentation +# framework. + +# Copyright (C) 2022-2022 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 +# published by the Free Software Foundation; either version 2 of the +# License, or (at your option) any later version. + +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program; if not, see <http://www.gnu.org/licenses/>. + +# The GNU General Public License is contained in the file COPYING. + +""" +Loads valgrind-monitor-def.py if not yet loaded. +The purpose of this file is to avoid re-defining the python commands +by reloading valgrind-monitor-def.py, as such redefinition causes a +segmentation violation in GDB <= 13. +""" + +import os + +if gdb.convenience_variable("valgrind_monitor_loaded") == None: + gdb.execute("source " + os.path.dirname(__file__) + "/valgrind-monitor-def.py") + gdb.set_convenience_variable ("valgrind_monitor_loaded", 1) + print("Loaded "+ __file__) + print("""Type "help valgrind" for more info.""") diff --git a/coregrind/vg_preloaded.c b/coregrind/vg_preloaded.c index 3809811aed..75a3b7ed0c 100644 --- a/coregrind/vg_preloaded.c +++ b/coregrind/vg_preloaded.c @@ -49,6 +49,19 @@ #include <features.h> #endif +/* Instruct GDB via a .debug_gdb_scripts section to load the valgrind and tool + front-end commands. */ +/* Note: The "MS" section flags are to remove duplicates. */ +#define DEFINE_GDB_PY_SCRIPT(script_name) \ + asm("\ +.pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n\ +.byte 1 /* Python */\n\ +.asciz \"" script_name "\"\n\ +.popsection \n\ +"); + +DEFINE_GDB_PY_SCRIPT(VG_LIBDIR "/valgrind-monitor.py") + #if defined(VGO_linux) || defined(VGO_solaris) || defined(VGO_freebsd) /* --------------------------------------------------------------------- diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index 83f49c840d..9a9b90e585 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -1167,8 +1167,9 @@ void usage(void) " -d arg tells to show debug info. Multiple -d args for more debug info\n" "\n" " -h --help shows this message\n" +" The GDB python code defining GDB front end valgrind commands is:\n %s\n" " To get help from the Valgrind gdbserver, use vgdb help\n" -"\n", vgdb_prefix_default() +"\n", vgdb_prefix_default(), VG_LIBDIR "/valgrind-monitor.py" ); invoker_restrictions_msg(); } diff --git a/docs/xml/manual-core-adv.xml b/docs/xml/manual-core-adv.xml index 6991a95e06..1609ee2a95 100644 --- a/docs/xml/manual-core-adv.xml +++ b/docs/xml/manual-core-adv.xml @@ -591,7 +591,7 @@ works across all devices and scenarios. xreflabel="Monitor command handling by the Valgrind gdbserver"> <title>Monitor command handling by the Valgrind gdbserver</title> -<para> The Valgrind gdbserver provides additional Valgrind-specific +<para>The Valgrind gdbserver provides additional Valgrind-specific functionality via "monitor commands". Such monitor commands can be sent from the GDB command line or from the shell command line or requested by the client program using the VALGRIND_MONITOR_COMMAND @@ -628,11 +628,11 @@ command: ]]></screen> </para> -<para>GDB will send the <computeroutput>leak_check</computeroutput> -command to the Valgrind gdbserver. The Valgrind gdbserver will -execute the monitor command itself, if it recognises it to be a Valgrind core -monitor command. If it is not recognised as such, it is assumed to -be tool-specific and is handed to the tool for execution. For example: +<para>GDB sends as a single string all what follows 'monitor' to the Valgrind +gdbserver. The Valgrind gdbserver parses the string and will execute the +monitor command itself, if it recognises it to be a Valgrind core monitor +command. If it is not recognised as such, it is assumed to be tool-specific and +is handed to the tool for execution. For example: </para> <programlisting><![CDATA[ (gdb) monitor leak_check full reachable any @@ -650,9 +650,9 @@ be tool-specific and is handed to the tool for execution. For example: (gdb) ]]></programlisting> -<para>As with other GDB commands, the Valgrind gdbserver will accept -abbreviated monitor command names and arguments, as long as the given -abbreviation is unambiguous. For example, the above +<para>Similarly to GDB, the Valgrind gdbserver will accept abbreviated monitor +command names and arguments, as long as the given abbreviation is unambiguous. +For example, the above <computeroutput>leak_check</computeroutput> command can also be typed as: <screen><![CDATA[ @@ -705,6 +705,130 @@ continue: the program execution is controlled explicitly using GDB </sect2> +<sect2 id="manual-core-adv.gdbserver-gdbmonitorfrontend" + xreflabel="GDB front end commands for Valgrind gdbserver monitor commands"> +<title>GDB front end commands for Valgrind gdbserver monitor commands</title> + +<para>As explained in + <xref linkend="manual-core-adv.gdbserver-commandhandling"/>, valgrind monitor + commands consist in strings that are not interpreted by GDB. GDB has no + knowledge of these valgrind monitor commands. The GDB 'command line + interface' infrastructure however provides interesting functionalities to help + typing commands such as auto-completion, command specific help, searching for + a command or command help matching a regexp, ... +</para> + +<para>To have a better integration of the valgrind monitor commands in the GDB + command line interface, Valgrind provides python code defining a GDB front end + command for each valgrind monitor command. Similarly, for each tool specific + monitor command, the python code provides a matching GDB front end command. +</para> + +<para>Like other GDB commands, the GDB front end Valgrind monitor commands are + hierarchically structured starting from 5 "top" GDB commands. Subcommands are + defined below these "top" commands. To ease typing, shorter aliases are also + provided. + + <itemizedlist> + <listitem> + <para><computeroutput>valgrind</computeroutput> (aliased + by <computeroutput>vg</computeroutput> + and <computeroutput>v</computeroutput>) is the top GDB command providing + front end commands to the Valgrind general monitor commands.</para> + </listitem> + <listitem> + <para><computeroutput>memcheck</computeroutput> (aliased + by <computeroutput>mc</computeroutput>) is the top GDB command + providing the front end commands corresponding to the memcheck specific + monitor commands.</para> + </listitem> + <listitem> + <para><computeroutput>callgrind</computeroutput> (aliased + by <computeroutput>cg</computeroutput>) is the top GDB command + providing the front end commands corresponding to the callgrind specific + monitor commands.</para> + </listitem> + <listitem> + <para><computeroutput>massif</computeroutput> (aliased + by <computeroutput>ms</computeroutput>) is the top GDB command + providing the front end commands corresponding to the massif specific + monitor commands.</para> + </listitem> + <listitem> + <para><computeroutput>helgrind</computeroutput> (aliased + by <computeroutput>hg</computeroutput>) is the top GDB command + providing the front end commands corresponding to the helgrind specific + monitor commands.</para> + </listitem> + </itemizedlist> +</para> + +<para>The usage of a GDB front end command is compatible with a direct usage of + the Valgrind monitor command. The below example shows a direct usage of the + Memcheck monitor command <computeroutput>xb</computeroutput> to examine the + definedness status of the some_mem array and equivalent usages based on the GDB + front end commands. + +<programlisting><![CDATA[ +(gdb) list +1 int main() +2 { +3 char some_mem[5]; +4 return 0; +5 } +(gdb) p &some_mem +$2 = (char (*)[5]) 0x1ffefffe5b +(gdb) p sizeof(some_mem) +$3 = 5 +(gdb) monitor xb 0x1ffefffe5b 5 + ff ff ff ff ff +0x1FFEFFFE5B: 0x00 0x00 0x00 0x00 0x00 +(gdb) memcheck xb 0x1ffefffe5b 5 + ff ff ff ff ff +0x1FFEFFFE5B: 0x00 0x00 0x00 0x00 0x00 +(gdb) mc xb &some_mem sizeof(some_mem) + ff ff ff ff ff +0x1FFEFFFE5B: 0x00 0x00 0x00 0x00 0x00 +(gdb) +]]></programlisting> + +It is worth noting down that the third command uses the +alias <computeroutput>mc</computeroutput>. This command also shows a +significant advantage of using the GDB front end commands: as GDB "understands" +the structure of these front end commands, where relevant, these front end +commands will evaluate their arguments. In the case of +the <computeroutput>xb</computeroutput> command, the +GDB <computeroutput>xb</computeroutput> command evaluates its second argument +(which must be an address expression) and its optional second argument (which +must be an integer expression). +</para> + +<para>GDB will auto-load the python code defining the Valgrind front end + commands as soon as GDB detects that the executable being debugged is running + under valgrind. This detection is based on observing that the Valgrind + process has loaded a specific Valgrind shared library. The loading of this + library is done by the dynamic loader very early on in the execution of the + process. If GDB is used to connect to a Valgrind process that has not yet + started its execution (such as when Valgrind was started with the + option <computeroutput>--vgdb-stop-at=startup</computeroutput> + or <computeroutput>--vgdb-error=0</computeroutput>), then the GDB front end + commands will not yet be auto-loaded. To have the GDB front end commands + auto-loaded, you can put a breakpoint e.g. in main and use the GDB + command <computeroutput>continue</computeroutput>. Alternatively, you can add + in your .gdbinit a line that loads the python code at GDB startup such as: +<programlisting><![CDATA[ +source /path/to/valgrind/python/code/valgrind-monitor.py +]]></programlisting> +</para> +<para> +The exact path to use in the source command depends on your Valgrind +installation. The output of the shell command <computeroutput>vgdb +--help</comput... [truncated message content] |
|
From: Philippe W. <phi...@so...> - 2023-01-08 10:53:16
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=3a046ec1c19d01eec8b22b0338cd236ccf64a4d5 commit 3a046ec1c19d01eec8b22b0338cd236ccf64a4d5 Author: Philippe Waroquiers <phi...@sk...> Date: Sun Jan 8 11:50:07 2023 +0100 Avoid doing mempool specific leak search activities if there are no mempools For most memcheck users, no mempools are used, but the leak search logic was doing in any case special handling, leading to useless work such as sorting again an already sorted array and making a copy of an array without modifying it. This slightly optimises the perf reg tests of memcheck. perl perf/vg_perf --tools=memcheck --vg=. --vg=../trunk_untouched perf -- Running tests in perf ---------------------------------------------- -- bigcode1 -- bigcode1 . :0.08s me: 3.0s (38.1x, -----) bigcode1 trunk_untouched:0.08s me: 3.1s (38.6x, -1.3%) -- bigcode2 -- bigcode2 . :0.07s me: 7.4s (105.9x, -----) bigcode2 trunk_untouched:0.07s me: 7.5s (107.4x, -1.5%) -- bz2 -- bz2 . :0.40s me: 5.2s (12.9x, -----) bz2 trunk_untouched:0.40s me: 5.4s (13.6x, -5.0%) -- fbench -- fbench . :0.15s me: 2.8s (18.8x, -----) fbench trunk_untouched:0.15s me: 2.9s (19.0x, -1.1%) -- ffbench -- ffbench . :0.16s me: 2.7s (16.8x, -----) ffbench trunk_untouched:0.16s me: 2.7s (17.1x, -1.9%) -- heap -- heap . :0.06s me: 4.0s (66.5x, -----) heap trunk_untouched:0.06s me: 4.1s (68.7x, -3.3%) -- heap_pdb4 -- heap_pdb4 . :0.07s me: 6.2s (89.1x, -----) heap_pdb4 trunk_untouched:0.07s me: 6.6s (94.9x, -6.4%) -- many-loss-records -- many-loss-records . :0.01s me: 1.2s (122.0x, -----) many-loss-records trunk_untouched:0.01s me: 1.2s (125.0x, -2.5%) -- many-xpts -- many-xpts . :0.03s me: 1.2s (41.7x, -----) many-xpts trunk_untouched:0.03s me: 1.3s (43.7x, -4.8%) -- memrw -- memrw . :0.06s me: 1.2s (19.8x, -----) memrw trunk_untouched:0.06s me: 1.2s (20.2x, -1.7%) -- sarp -- sarp . :0.02s me: 1.8s (91.5x, -----) sarp trunk_untouched:0.02s me: 2.1s (103.5x,-13.1%) -- tinycc -- tinycc . :0.11s me: 7.1s (64.4x, -----) tinycc trunk_untouched:0.11s me: 7.1s (64.3x, 0.1%) -- Finished tests in perf ---------------------------------------------- == 12 programs, 24 timings ================= Diff: --- memcheck/mc_leakcheck.c | 150 ++++++++++++++++++++++++++---------------------- 1 file changed, 81 insertions(+), 69 deletions(-) diff --git a/memcheck/mc_leakcheck.c b/memcheck/mc_leakcheck.c index b2a133f3fe..b06e77f605 100644 --- a/memcheck/mc_leakcheck.c +++ b/memcheck/mc_leakcheck.c @@ -332,15 +332,10 @@ Int find_chunk_for ( Addr ptr, static MC_Chunk** -find_active_chunks(Int* pn_chunks) +get_sorted_array_of_active_chunks(Int* pn_chunks) { - // Our goal is to construct a set of chunks that includes every - // mempool chunk, and every malloc region that *doesn't* contain a - // mempool chunk. - MC_Mempool *mp; - MC_Chunk **mallocs, **chunks, *mc; - UInt n_mallocs, n_chunks, m, s; - Bool *malloc_chunk_holds_a_pool_chunk; + UInt n_mallocs; + MC_Chunk **mallocs; // First we collect all the malloc chunks into an array and sort it. // We do this because we want to query the chunks by interior @@ -353,73 +348,98 @@ find_active_chunks(Int* pn_chunks) } VG_(ssort)(mallocs, n_mallocs, sizeof(VgHashNode*), compare_MC_Chunks); - // Then we build an array containing a Bool for each malloc chunk, - // indicating whether it contains any mempools. - malloc_chunk_holds_a_pool_chunk = VG_(calloc)( "mc.fas.1", - n_mallocs, sizeof(Bool) ); - n_chunks = n_mallocs; + // If there are no mempools (for most users, this is the case), + // n_mallocs and mallocs is the final result + // otherwise we need to do special handling for mempools. + + if (VG_(HT_count_nodes)(MC_(mempool_list)) > 0) { + // Our goal is to construct a set of chunks that includes every + // mempool chunk, and every malloc region that *doesn't* contain a + // mempool chunk. + MC_Mempool *mp; + MC_Chunk **chunks, *mc; + UInt n_chunks, m, s; + Bool *malloc_chunk_holds_a_pool_chunk; + + // We build an array containing a Bool for each malloc chunk, + // indicating whether it contains any mempools. + malloc_chunk_holds_a_pool_chunk = VG_(calloc)( "mc.fas.1", + n_mallocs, sizeof(Bool) ); + n_chunks = n_mallocs; + + // Then we loop over the mempool tables. For each chunk in each + // pool, we set the entry in the Bool array corresponding to the + // malloc chunk containing the mempool chunk. + VG_(HT_ResetIter)(MC_(mempool_list)); + while ( (mp = VG_(HT_Next)(MC_(mempool_list))) ) { + VG_(HT_ResetIter)(mp->chunks); + while ( (mc = VG_(HT_Next)(mp->chunks)) ) { - // Then we loop over the mempool tables. For each chunk in each - // pool, we set the entry in the Bool array corresponding to the - // malloc chunk containing the mempool chunk. - VG_(HT_ResetIter)(MC_(mempool_list)); - while ( (mp = VG_(HT_Next)(MC_(mempool_list))) ) { - VG_(HT_ResetIter)(mp->chunks); - while ( (mc = VG_(HT_Next)(mp->chunks)) ) { - - // We'll need to record this chunk. - n_chunks++; - - // Possibly invalidate the malloc holding the beginning of this chunk. - m = find_chunk_for(mc->data, mallocs, n_mallocs); - if (m != -1 && malloc_chunk_holds_a_pool_chunk[m] == False) { - tl_assert(n_chunks > 0); - n_chunks--; - malloc_chunk_holds_a_pool_chunk[m] = True; - } + // We'll need to record this chunk. + n_chunks++; - // Possibly invalidate the malloc holding the end of this chunk. - if (mc->szB > 1) { - m = find_chunk_for(mc->data + (mc->szB - 1), mallocs, n_mallocs); + // Possibly invalidate the malloc holding the beginning of this chunk. + m = find_chunk_for(mc->data, mallocs, n_mallocs); if (m != -1 && malloc_chunk_holds_a_pool_chunk[m] == False) { tl_assert(n_chunks > 0); n_chunks--; malloc_chunk_holds_a_pool_chunk[m] = True; } + + // Possibly invalidate the malloc holding the end of this chunk. + if (mc->szB > 1) { + m = find_chunk_for(mc->data + (mc->szB - 1), mallocs, n_mallocs); + if (m != -1 && malloc_chunk_holds_a_pool_chunk[m] == False) { + tl_assert(n_chunks > 0); + n_chunks--; + malloc_chunk_holds_a_pool_chunk[m] = True; + } + } } } - } - tl_assert(n_chunks > 0); + tl_assert(n_chunks > 0); - // Create final chunk array. - chunks = VG_(malloc)("mc.fas.2", sizeof(VgHashNode*) * (n_chunks)); - s = 0; + // Create final chunk array. + chunks = VG_(malloc)("mc.fas.2", sizeof(VgHashNode*) * (n_chunks)); + s = 0; - // Copy the mempool chunks and the non-marked malloc chunks into a - // combined array of chunks. - VG_(HT_ResetIter)(MC_(mempool_list)); - while ( (mp = VG_(HT_Next)(MC_(mempool_list))) ) { - VG_(HT_ResetIter)(mp->chunks); - while ( (mc = VG_(HT_Next)(mp->chunks)) ) { - tl_assert(s < n_chunks); - chunks[s++] = mc; + // Copy the mempool chunks and the non-marked malloc chunks into a + // combined array of chunks. + VG_(HT_ResetIter)(MC_(mempool_list)); + while ( (mp = VG_(HT_Next)(MC_(mempool_list))) ) { + VG_(HT_ResetIter)(mp->chunks); + while ( (mc = VG_(HT_Next)(mp->chunks)) ) { + tl_assert(s < n_chunks); + chunks[s++] = mc; + } } - } - for (m = 0; m < n_mallocs; ++m) { - if (!malloc_chunk_holds_a_pool_chunk[m]) { - tl_assert(s < n_chunks); - chunks[s++] = mallocs[m]; + for (m = 0; m < n_mallocs; ++m) { + if (!malloc_chunk_holds_a_pool_chunk[m]) { + tl_assert(s < n_chunks); + chunks[s++] = mallocs[m]; + } } - } - tl_assert(s == n_chunks); + tl_assert(s == n_chunks); - // Free temporaries. - VG_(free)(mallocs); - VG_(free)(malloc_chunk_holds_a_pool_chunk); + // Free temporaries. + VG_(free)(mallocs); + VG_(free)(malloc_chunk_holds_a_pool_chunk); - *pn_chunks = n_chunks; + *pn_chunks = n_chunks; + + // Sort the array so blocks are in ascending order in memory. + VG_(ssort)(chunks, n_chunks, sizeof(VgHashNode*), compare_MC_Chunks); + + // Sanity check -- make sure they're in order. + for (int i = 0; i < n_chunks-1; i++) { + tl_assert( chunks[i]->data <= chunks[i+1]->data); + } - return chunks; + return chunks; + } else { + *pn_chunks = n_mallocs; + return mallocs; + } } /*------------------------------------------------------------*/ @@ -2020,7 +2040,7 @@ void MC_(detect_memory_leaks) ( ThreadId tid, LeakCheckParams* lcp) VG_(free)(lc_chunks); lc_chunks = NULL; } - lc_chunks = find_active_chunks(&lc_n_chunks); + lc_chunks = get_sorted_array_of_active_chunks(&lc_n_chunks); lc_chunks_n_frees_marker = MC_(get_cmalloc_n_frees)(); if (lc_n_chunks == 0) { tl_assert(lc_chunks == NULL); @@ -2040,14 +2060,6 @@ void MC_(detect_memory_leaks) ( ThreadId tid, LeakCheckParams* lcp) return; } - // Sort the array so blocks are in ascending order in memory. - VG_(ssort)(lc_chunks, lc_n_chunks, sizeof(VgHashNode*), compare_MC_Chunks); - - // Sanity check -- make sure they're in order. - for (i = 0; i < lc_n_chunks-1; i++) { - tl_assert( lc_chunks[i]->data <= lc_chunks[i+1]->data); - } - // Sanity check -- make sure they don't overlap. One exception is that // we allow a MALLOCLIKE block to sit entirely within a malloc() block. // This is for bug 100628. If this occurs, we ignore the malloc() block @@ -2262,7 +2274,7 @@ void MC_(who_points_at) ( Addr address, SizeT szB) VG_(umsg) ("Searching for pointers pointing in %lu bytes from %#lx\n", szB, address); - chunks = find_active_chunks(&n_chunks); + chunks = get_sorted_array_of_active_chunks(&n_chunks); // Scan memory root-set, searching for ptr pointing in address[szB] scan_memory_root_set(address, szB); |