Bypass gcc 4.4/4.5 compilation bug by moving -fomit-frame-pointer to Makefile.all.am
gcc 4.4 and 4.5 has a bug which causes miscompilation of mc_main.c:
args are not correctly given to VG_(am_munmap_valgrind).
This causes the secondary map entries to not be unmapped
(which can cause unlimited memory growth)
and/or causes the assert on VG_(am_munmap_valgrind) result to fail.
Removing the pragma optimize from mc_main.c and inserting it instead
in Makefile.all.am for x86 solves the gcc bug.
Add assertion that the munmap of the secmap succeeds.
It is suspected that there is a bug in the call to VG_(am_munmap_valgrind).
At first sight, it looks like a bug in gcc version 4.4.5 (Debian 4.4.5-8)
which seems to pass wrong arguments from mc_main.c to aspace mgr function.
Some tests are failing on gcc20 with this assert a.o.
./vg-in-place ./perf/bz2 x
gives an assert.
The bug does not happen if Valgrind is compiled with gcc 4.7.0.
On gcc20, the new tests failing with this assert are:
memcheck/tests/linux/lsframe1 (stderr)
memcheck/tests/linux/lsframe2 (stderr)
memcheck/tests/linux/stack_switch (stderr)
memcheck/tests/origin5-bz2 (stdout)
memcheck/tests/vcpu_bz2 (stdout)
memcheck/tests/vcpu_bz2 (stderr)
The assert is committed so as to see other platforms
where this is failing.
fix 219156 support static malloc or alternate malloc lib (e.g. tcmalloc) with new option --soname-synonyms
* pub_tool_redir.h : define the prefix to be used for "soname synonym"
place holder
* vg_replace_malloc.c : define synonym place holder for malloc related
functions
* m_redir.c : when detecting a soname synonym place holder redir spec, search
in clo_soname_synonyms if there is a synonym pattern.
If yes, replace the soname pattern. If not, ignore the redir spec.
* various files: implement or document the new clo --soname-synonyms
* new test memcheck/tests/static_malloc.vgtest
Florian Krohm [Sun, 6 May 2012 03:51:00 +0000 (03:51 +0000)]
Avoid regtest failures on x86_64 and ppc64 when toolchains for the
seconday platform (x86 and ppc32, respectively) is not available.
Add -DVGA_SEC_xxxxx and -DVGP_SEC_... to the GCC command line
indicating that a seconday platform is supported. Make arch_test.c
recognise those flags.
Fixes bugzilla #296983.
Florian Krohm [Sun, 6 May 2012 03:37:25 +0000 (03:37 +0000)]
Require automake-1.10 for proper handling of include file dependencies
in .S files. Also included here is some cleanup, including a reversion
of r10378. Fixes bugzilla #197914.
Improve m_redir.c debug trace by adding filename.
Many objects (shared or non shared) have no soname.
In such case, showing the filename clarifies where the
redir spec is coming from.
Test cases for POWER Power Decimal Floating Point (DFP) test class,
test group and test exponent instructions dtstdc, dtstdcq, dtstdg,
dtstdgq, dtstex and dtstexq. Bug #298862. (Carl Love,
carll@us.ibm.com and Maynard Johnson, maynardj@us.ibm.com)
add optional arg [aspacemgr] to v.info memory to show aspacemgr segments.
When investigating Valgrind out of memory situation,
it is useful to be able to output the list of segments of the
aspacemgr at any moment.
The GDB monitor command "v.info memory" has now an optional
argument allowing to output this list of segments
For --profile-flags=, weight the counts by the number of guest insns
in each IRSB, rather than considering each IRSB to have a weight of 1.
This probably gives more representative profiles, especially post
t-chain merge, which made inter-SB transitions more or less free
compared to what they were before.
Be lenient if the machine model could not be determined. Assume it's
a new machine as opposed to a too old machine.
Patch by Christian Borntraeger (borntraeger@de.ibm.com) with additional
commentary. Fixes 298394.
Consolidate and update information about dependencies of
VG_(machine_get_hwcaps) for all architectures in pub_core_machine.h
and avoid double maintenance.
Last optimisation for the day: change VG_(stats__n_xindirs) in such a
way that the fast-path through VG_(disp_cp_xindir) only has to
increment a 32 bit counter, saving memory bandwidth on 32 bit
platforms compared to a 64-bit inc. The overall numbers of XIndirs
can still be 64 bit though.
add some .globl or used attribute to avoid link failures with gold linker + LTO
When doing experiment with gcc 4.7.0 and link time optimisation,
encountered link failures on amd64 which were solved by adding
.globl and used attribute.
=> added .globl in similar places for arm/x86/ppc32/s390.
Did not touch darwin (which asm seems somewhat different).
Change permission mask for FIFOs and shared memory to 0600 instead of 0666
Following a discussion about which user can debug which VAlgrind gdbserver:
The default umask will remove the "other" and "group" write bits.
Without the w bits, nothing works in any case.
Moreover, if the vgdb process does not belong to the user running the
V gdbserver, connections are also not possible.
=> remove useless/confusing bits.
patch fixing 297991: mmap changing a file descriptor current position
Bug caused by the following problem:
for each mmap, Valgrind reads the 1st 1024 bytes to detect
if this is an mmap-ed file containing debug info to decode.
Reading this 1Kb is done with VG_(pread). VG_(pread) should be
the equivalent of syscall pread but on linux, it is implemented as
a seek+read.
The patch implements VG_(pread) in terms of the underlying pread syscall.
Test mmap_fcntl_bug.c completed to also verify the fd current position
before and after the mmap.
tested on linux x86/amd64/ppc32/ppc64/s390.
(not tested on Darwin)
(manually tested on arm-android)
TCHAIN: avoid calls to search_transtab and return to scheduer by first using tt_fast
This slightly improves some perf tests (e.g. heap).
Some not explained "real time" slow down of bz2 between trunk/svn tchain
and this patch analyzed with callgrind/cachegrind.
realtime slowdown attributed to Pentium 4 self modifying code unfriendly cache.
(callgrind/cachegrind cache simulation do not understand self modifying
code).
Android's libc includes advertise a "malloc_usable_size", but the
libc.so contains no such symbol; rather a "dlmalloc_usable_size"
(great, huh :-) So intercept that too, on Android.
outer/inner setup: new perf/vg_perf options to run perf tests + support translation chaining in inner.
* perf/vg_perf:
Similarly to tests/vg_regtest, perf/vg_perf now accepts the 3
optional arguments:
--outer-valgrind
--outer-tool
--outer-args
This allows easy analysis or comparison of performance between
different Valgrind versions (e.g. using callgrind, or cachegrind/cg_diff).
* See README_DEVELOPERS for more details.
* vg_regtest modified so as to use the 'in-place' build of inner, rather
than the installed version.
* added option --smc-check=all-non-file to vg_perf and vg_regtest
outer default arguments (needed when evaluating a Valgrind which does
translation chaining).
TCHAIN: remove caused_discard* argument to VG_(translate)
This is the followup to rev 12488.
With this revision, translation chaining is not done
if the translation with 'from address' is not existing
anymore (discarded or erased).
The assumption documented in 12488 comment has been checked by:
* first reproduce a crash in Firefox when always setting
caused discard to False
* then upgrade to rev 12488
* with this upgrade, no crash anymore.
=> this verifies that the caused discard logic is properly
replaced by revision 12488.
Fix assert due to gdbserver discarding translation
The fix consists in checking if the translation
of the 'from' address is still existing.
Patch also contains a big comment explaining why it is
safe to discard/erase the current translation being
executed.
In a follow-up patch, the Bool in VG_(translate) will
be removed :
Bool VG_(translate) ( /*OUT*/Bool* caused_discardP,
(if experiment confirms the hypothesis that it is
safe to discard current translation).
drd, free() intercept: Swap freeing and cleaning memory.
Note: since the big lock is held while the malloc() and free() intercepts are
running, and since mmap() is treated by Valgrind as a non-blocking system call,
this code change is not expected to result in a behavior change of drd.
Further fix 297078 : implement conversion between vki and gdb real time sig nr.
* gdbserver_tests/nlpasssigalrm
modify test so as to test also a real time signal
* coregrind/m_gdbserver/signals.c
- implement translation between gdb real time signal numbers
and vki real time signal numbers
- ensure non-convertible signals are giving an error
Fix bug 297078 gdbserver signal handling problems caused by diff vki nr/gdb nr and
non reset of "C-ontinued" signal
* To allow vki signame to be used in debuglog:
- pub_core_signals.h : added prototype for Char *VG_(signame)
- m_signals.c : changed static const Char *signame(Int sigNo)
to const Char *VG_(signame)(Int sigNo)
* valgrind-low.c : when the signal to report to gdb has
been reported, clear it so that it is not reported anymore
afterwards.
* m_gdbserver.c: when checking in pass_signals if signal
can be passed without gdb interaction, do a conversion
from vki nr to gdb nr when indexing
(as pass_signals[] is indexed by gdb_nr).
* various gdbserver files:
- used vki_ prefix for some args and variables to clarify
- better debuglog tracing
* modified nlpasssigalrm.vgtest to test SIGCHLD signal
handling followed by a break (to see SIGTRAP is properly
given to gdb).
Julian Seward [Tue, 27 Mar 2012 10:19:39 +0000 (10:19 +0000)]
/* Do expensive interpretation for Iop_Add32 and Iop_Add64 on
Darwin. 10.7 is mostly built with LLVM, which uses these for
bitfield inserts, and we get a lot of false errors if the cheap
interpretation is used, alas. Could solve this much better if
we knew which of such adds came from x86/amd64 LEA instructions,
since these are the only ones really needing the expensive
interpretation, but that would require some way to tag them in
the _toIR.c front ends, which is a lot of faffing around. So
for now just use the slow and blunt-instrument solution. */
Pertains to, although does not completely solve, #242137.
Julian Seward [Tue, 27 Mar 2012 10:06:31 +0000 (10:06 +0000)]
Add a nasty kludge in the handling of mmap on Darwin. Does not apply
to any other platforms. Prevent mmap(ANON) from returning zero (zero
with success, that is) since (a) some programs are observed to be
spooked by getting zero from a successful call to mmap, and (b) it's
pretty stupid from the point of view of program safety and possibly
security, since it causes page zero to become accessible. So don't.