All entries are added disabled - enabling them will be done later.
Patch by Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16230
Extend valgrind_get_tls_addr() with static TLS calculation for MIPS.
Related issue #375514.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16215
Return correct Dtv location. Top of MIPS tcbhead structure is located
0x7000 bytes before the value of ULR. Dtv is the first of two pointers
in the tcbhead structure.
This fixes gdbserver_tests/hgtls on some MIPS platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16212
* 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
either to keep the free stacktrace and/or to compute full xtree memory.
Also, properly compute avg nr of IP per execontext: the avg must
be computed using the real nr of execontext stored, not the hash
table size.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16199
KCachegrind currently uses a quick format detection before
actually loading a file, and checks for a line starting with
"events:" in the first 2kB for that. This obviously is fragile,
as shown by an internal bug report by Philippe: before the
"events" line, Callgrind puts a "cmd:" line with the command
line. If this is very long, the detection fails and the file
does not get loaded at all.
While KCachegrind would not need to have this quick format
check at all, it is useful if multiple input format filters
get supported at some point, to automatically select the
correct filter.
Further, for the "file" command, for file managers and
desktop environments, having an unique way to detect a
file format is important.
It is not too late to fix this issue for the callgrind format.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16196
Remove the following warnings from the build:
m_coredump/coredump-elf.c:521:31: warning: cast discards 'const'
qualifier from pointer target type [-Wcast-qual]
Related BZ#370028
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16190
Fix 373192 Calling posix_spawn in glibc 2.24 completely broken
Functionally, this patch just does the following 2 changes to the
fork clone handling:
* It does not mask anymore CLONE_VFORK :
The only effect of this flag is to suspend the parent, waiting for
the child to either exit or execve.
If some applications depends on this synchronisation, better keep it,
as it will not harm to suspend the parent valgrind waiting for the
child valgrind to exit or execve.
* In case the guest calls the clone syscall providing a non zero client stack,
set the child guest SP after the syscall, before executing guest instructions.
Not setting the guest stack ptr was the source of the problem reported
in the bugs.
This also adds a test case none/tests/linux/clonev.
Before this patch, test gives a SEGV, which is fixed by the patch.
The patch is however a lot bigger : this fix was touching some (mostly
identical/duplicated) code in all the linux platforms.
So, the clone/fork code has been factorised as much as possible.
This removes about 1700 lines of code.
This has been tested on:
* amd64
* x86
* ppc64 be and le
* ppc32
* arm64
This has been compiled on but *not really tested* on:
* mips64 (not too clear how to properly build and run valgrind on gcc22)
It has *not* been compiled and *not* tested on:
* arm
* mips32
* tilegx
* darwin (normally, no impact)
* solaris (normally, no impact)
The changes are relatively mechanical, so it is not impossible that
it will compile and work out of the box on these platforms.
Otherwise, questions welcome.
A few points of interest:
* Some platforms did have a typedef void vki_modify_ldt_t,
and some platforms had no definition for this type at all.
To make it easier to factorise, for such platforms, the following has
been used:
typedef char vki_modify_ldt_t;
When the sizeof vki_modify_ldt_t is > 1, then the arg syscall is checked.
This is somewhat a hack, but was simplifying the factorisation.
* for mips32/mips64 and tilegx, there is a strange unconditional assignment
of 0 to a register (guest_r2 on mips, guest_r0 on tilegx).
Unclear what this is, in particular because this is assigned whatever
the result of the syscall (success or not).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16186
When definition of VG_(gdbserver_report_signal) was changed in r15248,
the function VG_(synth_sigfpe) was omitted from the update.
This change fixes:
gdbserver_tests/mcsignopass (stderr)
gdbserver_tests/mcsignopass (stdoutB)
gdbserver_tests/mcsigpass (stderr)
gdbserver_tests/mcsigpass (stdoutB)
on MIPS platforms.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16180
MIPS32 implementation missed to set up a correct (zero) return address.
This led to incorrect execution of get_StackTrace_wrk as it was not
able to unwind stack correctly.
This change fixes memcheck/tests/leak-autofreepool-5.
MIPS64 implementation missed clearing all integer registers before
entering the function.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16166
Use platform specific pre-wrapper for fadvise64 system call and respect
size of parameters, instead of using generic wrapper written for 32bit
architectures.
Issue reported by Marcin Juszkiewicz.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16163
For fadvise64 system call, 7th 32-bit argument slot (third on the stack)
will also be used due to MIPS O32 calling convention in passing 64-bit
values.
sys_fadvise64(int fd, loff_t offset, loff_t len, int advice);
NR_fadvise64 -> v0 (sysno)
fd -> a0 (ARG1)
offset -> a2, a3 (ARG3, ARG4)
len -> SP + 16, SP + 20 (ARG5, ARG6)
advise -> SP + 24 (ARG7)
Change the code according to it.
Patch by Aleksandar Rikalo.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16162
