We incorrectly stored the archinfo_host argument of iselSB_S390 into
a global variable not realising it points to a stack-allocated variable.
This caused s390_archinfo_host->hwcaps member to change its value
randomly over time. It could have caused invalid code to be generated.
Curious that it did not surface.
More fixes:
- A few dummy_put_IA's were missing, causing asserts to fire.
Mostly for the "load/store conditional" kind of insns
- EX needed some finishing touches
- Assignments to irsb->next are forbidden. We had a few in the "special
opcodes" section. Now fixed, I hope.
With this patch most regressions run through. I see 3 failures in none
and a few more in the memcheck bucket.
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.
Fix s390_tchain_patch_load64; some bytes were mixed up.
Fix unchainXDirect_S390; modified place_to_unchain address
before patching the code there.
Add some convenience functions for insn verification in
chain/unchain machinery.
Avoid magic constants.
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)
Extend CSE to cover CSEing of clean helper calls. This gives a
significant performance improvement in the baseline simulator (20%) on
some pieces of ARM code.
POWER Processor decimal floating point instruction support: part 2
(bug #297497) (Carl Love, carll@us.ibm.com) (VEX side)
This commit adds the second set of patches to add decimal floating
point (DFP) support for POWER to Valgrind. Bugzilla 295221 contains
the first set of patches for the adding the POWER support for the DFP
32, 64 and 128-bit sizes. The first set of patches also added support
for the 64 and 128-bit DFP arithmetic instructions and user test code
for the new DFP instructions. The second set of patches, being
submitted in this bugzilla include support for the DFP shift
instructions and format conversion instructions. Specifically, the
list of Power instructions is: dctdp, drsp, dctfix, dcffix, dctqpq,
dctfixq, drdpq, dcffixq, dscri, dscriq, dscli, dscliq.
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.
Improve the behaviour of 64-to/from-80 bit QNaN conversions, so that
the QNaN produced is "canonical". SNaN conversions are unchanged
(because I don't have a definition of what a canonical SNaN is)
although there are some comment updates. Fixes Mozilla bug #738117.
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.
Initial support for POWER Processor decimal floating point instruction
support -- VEX side changes. See #295221.
This patch adds the DFP 64-bit and 128-bit support, support for the
new IEEE rounding modes and the Add, Subtract, Multiply and Divide
instructions for both 64-bit and 128-bit instructions to Valgrind.
Carl Love (carll@us.ibm.com) and Maynard Johnson (maynardj@us.ibm.com)
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.
projects / thirdparty / valgrind.git / log
