Several issues with vector floating point instructions have gone unnoticed
due to a lack of test coverage in this area. Add a test case that
improves the coverage, particuarly when dealing with short and extended
floating point formats.
When trying to execute any of the vector float multiply-and-add family
instructions, Valgrind panics with the message "Iex_Qop with F128 data".
So far all F128 operations were implemented with instructions that operate
on FP register pairs. However, such instructions don't exist for
Iop_MAddF128 and Iop_MSubF128, so they must be implemented with vector
instructions instead. This was missed when emitting them in
"guest_s390_toIR.c".
Add the missing support. This also involves adding a few new features to
host_s390_defs:
* a new vector operation S390_VEC_INIT_FROM_FPRS
* the capability to move the left half of a VR to an FPR
* S390_VEC_FLOAT_MADD/_MSUB for 128-bit sizes
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.
.. and some debug printing associated with them. I don't think this affects
anything apart from debug printing. Noticed when running a x86 (32-bit)
Firefox build.
amd64:
S and NS after LOGICQ (per comments from Eyal Soha on the dev list)
S after SHLQ
NZ after SHLL
x86:
NZ after SHRL
Z after SHLL
I would have liked to have added the inverse conditions in all cases (eg, both
S and NS, or both Z and NZ), but finding use cases for some of these is almost
impossible, hence they are sometimes omitted. All of the added cases have
been tested.
With origin tracking enabled, 8- and 16-bit stores could sometimes lose origin
info unnecessarily. This patch removes this avoidable lossage. (Since MC
only stores 1 origin value for each 32-bit word of address space, there is
still unavoidable lossage of origins in some cases; this patch does not help
in those cases since it's a fundamental design limitation.)
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.
Extend hg04_race to have more entries in the conflicting stacktrace,
and make another test hg04_race_h9 to test with one more entry than
the default of 8.
The process_option_state is functionally needed during initial parsing
of CLO options. When later changing them, only changing the CLO
itself is good enough.
But the processing of option needs to have a state.
