- On Linux, whether Valgrind properly intercepts the system calls that access
/proc/self/cmdline, /proc/<pid>/cmdline, /proc/self/exe and /proc/<pid>/exe.
- On Darwin, whether Valgrind does not modify the behavior of the system calls
that access the aforementioned files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10871
is mounted to compile-time logic in order to minimize the differences
in behavior with Valgrind version 3.5.0.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10868
VG_(is_procfs_mounted)(). The old name was derived from the name
of the preprocessor macro HAVE_PROC while the new name is a more
accurate description of what this function does.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10867
in r10156) broke cross-compilation. This patch converts the configure-time
test into a runtime test. Should fix bug #204843.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10860
to make drd/tests/qt4_mutex pass on Fedora 11 x86_64). Further
analysis has shown that this is an issue in libQtCore that should be
fixed instead of suppressed. Will file a bug report in the Fedora
bugzilla instead.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10853
the ABI in the ELF files it generates instead of ELFOSABI_SYSV as
has been used to date.
This was causing us to use the 64 bit backend to run 32 bit
programs as the launcher failed to identify them as 32 bit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10841
of ' delineated constants, due to gnu as bug 6878. This caused
warnings on Fedora 10.
This addresses bug 203937.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10839
by hand-coding the 32-bit fldcw instructions,
as the assembler gives an error when
trying to assemble them. The generated binary
is identical to one generated on a system
with working binutils.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10838
generated suppression, and hence the problem of having to split it
into multiple CDATA blocks is moot.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10832
mapped rw-. Fixes#190820. Really, this logic is still pretty ropey; we
could do a lot better here.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10828
for not testing properly. Added a regtest for it too. Fixes bug 200760
(again, properly this time).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10826
spotted by Ashley Pittman:
* If I specify --xml-file=<file> but not --xml=yes I get partial
output in the xml file.
* Using log file qualifiers with XML results in the xml for the
qualifier being put to stdout.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10823
both wrapped up in XML tags (as before) but also in plain text in a
sequence of CDATA blocks. Normally only one, but in the worst case
the raw data will have ]]> in it, in which case it needs to be split
across two CDATA blocks.
This apparently simple change involved a lot of refactoring of the
suppression printing machinery:
* in the core-tool iface, change "print_extra_suppression_info" (which
prints any auxiliary info) to "get_extra_suppression_info", which
parks the text in a caller-supplied buffer. Adjust tools to match.
* VG_(apply_StackTrace): accept a void* argument, which is passed to
each invokation of the functional parameter (a poor man's closure
implementation).
* move PRINTF_CHECK into put_tool_basics.h, where it should have been
all along
* move private printf-into-an-XArray-of-character functions from
m_debuginfo into m_xarray, and make them public
* gen_suppression itself: use all the above changes. Basically we
always generate the plaintext version into an XArray. In text mode
that's just printed. In XML mode, we print the XMLery as before,
but the plaintext version is dumped into a CDATA block too.
* update the Protocol 4 specification to match all this.
This still isn't 100% right in the sense that the CDATA block data
needs to be split across multiple blocks if it should ever contain the
CDATA end mark "]]>". The Protocol 4 spec has this right even though
the implementation currently doesn't.
Fixes#191189.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10822
