Some linux os make softlink from customized directory like lib64xxx
into standard system lib64 directory.
https://bugs.kde.org/show_bug.cgi?id=467839
Contributed-by: JojoR <rjiejie@gmail.com>
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.
In the memcheck monitor 'leak_search', add a "new" keyword corresponding
to the delta leak search mode LCD_New.
Add a new client request VALGRIND_DO_NEW_LEAK_CHECK.
When doing a delta leak search, new loss records are marked with "new"
(whatever the delta leak search mode).
Note that trailing white spaces were removed in mc_main.c.
A much small diff can be looked at by using the -w diff option.
Note that this modifies files on darwin/solaris/bsd but I only did a linux
build so possibly this commit might cause a compilation error, that should
then be trivial to fix.
Also added memmem test in the list of ignored files.
I tried to test drd/tests/pth_mutex_signal on Solaris
(you never know) but encountered a missing syscall
wrapper. So this adds a very basic wrapper for lwp_mutex_unlock.
Also update a Solaris expected that I missed amongst the FreeBSD changes.
On some systems the gdbserver_tests would fail because the filter
for the optimized hwcaps subdir didn't match because the file is
called slightly differently, with the version number before .so
instead of after. For example: /lib64/glibc-hwcaps/power9/libc-2.28.so
Add one extra filter for this pattern.
cachegrind callgrind dhat exp-bbv gdbserver_tests massif none mpi shared
Mostly these are just updates (and new testcases) under new/tests
The other directories have just #ifdef changes
Files in the root directory
Several Makefile.am files that have dependencies on FreeBSD autoconf
variables. Included a few new filter files to act as placeholders
to create new freebsd subdirectories.
Updated NEWS with the FreeBSD bugzilla items plus a couple of other
items fixed indirectly.
Older ubuntu arm64 setups used eglibc 2.19 and gdb 7.7.1. In that
case select.c could be under linux/generic and the select argument
list could be split up differently over several lines. Adjust
filter_gdb to catch those differences.
Also checked against an Debian arm64 with glibc 2.31 and gdb 10.1.
With newer glibc/gdb we might see a __select call without anything
following on the line. Also when gdb cannot find a file it might
now print "Inappropriate ioctl for device" instead of the message
"No such file or directory"
This test verifies that GDB can interrupt a process with all threads
blocked in a long select syscall.
The test used to terminate by having GDB modifying the select argument.
However, modifying the select argument works only for specific arch
and/or specific versions of glibc.
The test then blocks on other architectures/glibc versions.
The previous version of the test was:
* first launching sleepers so as to have all threads blocked in long select
* interrupting these threads
* changing the select time arg so that the threads burn cpu
* and then change variables to have the program exit.
The new version does:
* first launches sleepers so that all threads are burning cpu.
* interrupting these threads
* change the local variables of sleepers so that the threads will
block in a long select syscall
* interrupt these threads
* kill the program.
With this new version, we still check the behaviour of gdb+vgdbserver
for both burning and sleep threads, but without having the termination
depending on modifying select syscall argument.
Tested on debian amd64 and on ubuntu arm64 (to check the test does not hang
on an arm64 platform).
gdb can also use debuginfod and is excessively chatty when downloads
fail (even when DEBUGINFOD_URLS isn't set). Filter those messages out
of the gdb output.
The other gdbserver_tests that need to run gdb make sure it is actually
available before trying to run it, otherwise the test is skipped. Do the
same to hgtls.vgtest by adding test -e gdb to the prereq.
Make --track-fds=yes not report on file descriptors 0, 1, and 2 (stdin,
stdout, and stderr) by default. Add a new option --track-fds=all that does
report on the std file descriptors still being open. Update testsuite and
documentation.
Original patch by Peter Kelly <pmk@cs.adelaide.edu.au>
Updated by Daniel Fahlgren <daniel@fahlgren.se>
https://bugs.kde.org/show_bug.cgi?id=140939
This patch changes the option parsing framework to allow a set of
core or tool (currently only memcheck) options to be changed dynamically.
Here is a summary of the new functionality (extracted from NEWS):
* It is now possible to dynamically change the value of many command
line options while your program (or its children) are running under
Valgrind.
To have the list of dynamically changeable options, run
valgrind --help-dyn-options
You can change the options from the shell by using vgdb to launch
the monitor command "v.clo <clo option>...".
The same monitor command can be used from a gdb connected
to the valgrind gdbserver.
Your program can also change the dynamically changeable options using
the client request VALGRIND_CLO_CHANGE(option).
Here is a brief description of the code changes.
* the command line options parsing macros are now checking a 'parsing' mode
to decide if the given option must be handled or not.
(more about the parsing mode below).
* the 'main' command option parsing code has been split in a function
'process_option' that can be called now by:
- early_process_cmd_line_options
(looping over args, calling process_option in mode "Early")
- main_process_cmd_line_options
(looping over args, calling process_option in mode "Processing")
- the new function VG_(process_dynamic_option) called from
gdbserver or from VALGRIND_CLO_CHANGE (calling
process_option in mode "Dynamic" or "Help")
* So, now, during startup, process_option is called twice for each arg:
- once during Early phase
- once during normal Processing
Then process_option can then be called again during execution.
So, the parsing mode is defined so that the option parsing code
behaves differently (e.g. allows or not to handle the option)
depending on the mode.
// Command line option parsing happens in the following modes:
// cloE : Early processing, used by coregrind m_main.c to parse the
// command line options that must be handled early on.
// cloP : Processing, used by coregrind and tools during startup, when
// doing command line options Processing.
// clodD : Dynamic, used to dynamically change options after startup.
// A subset of the command line options can be changed dynamically
// after startup.
// cloH : Help, special mode to produce the list of dynamically changeable
// options for --help-dyn-options.
typedef
enum {
cloE = 1,
cloP = 2,
cloD = 4,
cloH = 8
} Clo_Mode;
The option parsing macros in pub_tool_options.h have now all a new variant
*_CLOM with the mode(s) in which the given option is accepted.
The old variant is kept and calls the new variant with mode cloP.
The function VG_(check_clom) in the macro compares the current mode
with the modes allowed for the option, and returns True if qq_arg
should be further processed.
For example:
// String argument, eg. --foo=yes or --foo=no
(VG_(check_clom) \
(qq_mode, qq_arg, qq_option, \
VG_STREQN(VG_(strlen)(qq_option)+1, qq_arg, qq_option"=")) && \
({const HChar* val = &(qq_arg)[ VG_(strlen)(qq_option)+1 ]; \
if VG_STREQ(val, "yes") (qq_var) = True; \
else if VG_STREQ(val, "no") (qq_var) = False; \
else VG_(fmsg_bad_option)(qq_arg, "Invalid boolean value '%s'" \
" (should be 'yes' or 'no')\n", val); \
True; }))
VG_BOOL_CLOM(cloP, qq_arg, qq_option, qq_var)
To make an option dynamically excutable, it is typically enough to replace
VG_BOOL_CLO(...)
by
VG_BOOL_CLOM(cloPD, ...)
For example:
- else if VG_BOOL_CLO(arg, "--show-possibly-lost", tmp_show) {
+ else if VG_BOOL_CLOM(cloPD, arg, "--show-possibly-lost", tmp_show) {
cloPD means the option value is set/changed during the main command
Processing (P) and Dynamically during execution (D).
Note that the 'body/further processing' of a command is only executed when
the option is recognised and the current parsing mode is ok for this option.
The sed expressions and the comments of these expression were at 2 different
places, making this already horrible list of expressions even more
horrible to understand/maintain.
So, restructure to allow the comments for an expression be close
to the expression.
mcsigpass and mcsignopass tests fails due to the slightly different
gdb output. Filter the tests output to make it the same for different
gdb version. Change mcsigpass and mcsignopass .exp to fit filtered
.out.
More generic regexp by Stefan Maksimovic <stefan.maksimovic@rt-rk.com>.
https://bugs.kde.org/show_bug.cgi?id=406355
commit a214595daed7830a091dcd0f52c5b8073bfd04dd already handled some
of the new differences created by glib 2.27.
This commit should filter the new way gdb shows a select syscall
with glibc 2.27
Some compilers actually do not support -pie and report its usage
as an error. We need to check if it is safe to use it first.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16463
At the beginning of a Valgrind gdbserver test,
2 messages are produced when launching the command
target remote | vgdb
A message output by vgdb:
relaying data between gdb and process <pid>
(this message is read by GDB from the vgdb pipe, and re-output
on stderr)
and a message produced by GDB:
Remote debugging using | ./vgdb
GDB 8.0 changes the order in which the above messages are output.
This causes 2 tests to fail, as the 'relaying' line appears
then in a part of the output deleted by a filter script.
To avoid this, change the filter scripts to always remove
this 'relaying line', which is not particularly interesting to check.
All the .exp files containining such a 'relaying' line are updated
accordingly.
This has been tested with various gdb versions (7.5, 7.7, 7.12, 8.0)
on amd64 and/or ppc64.
Thanks to Mark Wielaard, which helped to investigate this problem
by bisecting the GDB patches in GDB 8.0 causing this change of
behaviour.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16453
GDB reports to be "unable to find the start of the function" and suggests
increasing the range of the search using the 'set heuristic-fence-post'
command. So we did.
It fixes gdbserver_tests/mcmain_pic on some platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16303
and scheduler lock (pipe based or futex based)
See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.pthreads_perf_sched
for background info about cpu freq scaling and valgrind thread scheduler.
To reproduce the interaction, do:
for sched in --fair-sched=yes --fair-sched=no
do
for affinity in 0 1
do
echo $sched $affinity
time ./vg-in-place $sched -q ./gdbserver_tests/sleepers 1000000 0 1000 B-B-B-B- $affinity
done
done
which gives the below output (intel core i5-6402P, debian 8, kernel 3.16.0).
In summary: the fair scheduler is fair, the pipe based scheduler
can be really unfair (e.g. with --fair-sched=no and no affinity,
2 threads are finishing their work, while the 2 other threads are
starting their work only after the first 2 have fully finished).
The difference in timing is significant : 1m14s versus around 47 seconds.
Note: If the governor is set to performance, strangely, the time needed for
--fair-sched=no increases slighltly (to around 48 seconds).
The time for --fair-sched=yes with or without affinity is then also
to around 48 seconds.
Below is timing with on-demand governor:
--fair-sched=yes 0
loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 0
Brussels ready to sleep and/or burn
London ready to sleep and/or burn
Petaouchnok ready to sleep and/or burn
main ready to sleep and/or burn
Brussels finished to sleep and/or burn
London finished to sleep and/or burn
Petaouchnok finished to sleep and/or burn
main finished to sleep and/or burn
real 1m14.582s
user 1m14.348s
sys 0m0.204s
--fair-sched=yes 1
loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 1
Brussels ready to sleep and/or burn
London ready to sleep and/or burn
Petaouchnok ready to sleep and/or burn
main ready to sleep and/or burn
main finished to sleep and/or burn
Brussels finished to sleep and/or burn
Petaouchnok finished to sleep and/or burn
London finished to sleep and/or burn
real 0m46.785s
user 0m46.756s
sys 0m0.032s
--fair-sched=no 0
loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 0
Brussels ready to sleep and/or burn
Brussels finished to sleep and/or burn
London ready to sleep and/or burn
London finished to sleep and/or burn
Petaouchnok ready to sleep and/or burn
main ready to sleep and/or burn
Petaouchnok finished to sleep and/or burn
main finished to sleep and/or burn
real 0m47.742s
user 0m48.224s
sys 0m0.084s
--fair-sched=no 1
loops/sleep_ms/burn/threads_spec/affinity: 1000000 0 1000 B-B-B-B- 1
Brussels ready to sleep and/or burn
London ready to sleep and/or burn
Petaouchnok ready to sleep and/or burn
main ready to sleep and/or burn
Brussels finished to sleep and/or burn
London finished to sleep and/or burn
main finished to sleep and/or burn
Petaouchnok finished to sleep and/or burn
real 0m46.601s
user 0m46.568s
sys 0m0.036s
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16251
* New command line options --xtree-leak=no|yes and --xtree-leak-file=<file>
to produce the end of execution leak report in a xtree callgrind format
file.
* New option 'xtleak' in the memcheck leak_check monitor command, to
produce the leak report in an xtree file.
* File name template arguments (such as --log-file, --xtree-memory-file, ...)
have a new %n format letter that is replaced by a sequence number.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16205
valgrind svn r16173 "Add CLEAR_CALLER_SAVED_REGS in leak-tree test"
added one extra line to memcheck/tests/leak-tree.c which is used in
gdbserver_tests/mcblocklistsearch.vgtest. Adjust the line numbers in
the exp file to match.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16177
