Similar to r12444 (see Log below), but this is doing it for x86 and amd64.
The xmm registers are using uint32 or uint64 for their float
union components. For the i387 80 bits float registers, as there is
no uint80, a struct uint16 + uint64 is defined.
Log:
Change the type of the shadow regs for floating point registers
to be uint64. Previously the value in such a shadow reg would
be interpreted by gdb as a floating point value which would
produce non-sensible output for e.g p/x $f1s1.
This patch covers the power and arm architectures.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12445
to be uint64. Previously the value in such a shadow reg would
be interpreted by gdb as a floating point value which would
produce non-sensible output for e.g p/x $f1s1.
This patch covers the power and arm architectures.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12444
di->soname was not freed, so was leaked when debug info is removed.
free(soname) added in free_Debuginfo, after having verified
and then ensured that all soname are allocated in dinfo.
regtested on deb6/amd64
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12442
A '3 lines how to':
perl tests/vg_regtest --outer-valgrind=../trunk_untouched/install/bin/valgrind --all
(the outer results for a test xxx is in xxx.outer.log)
To run with another tool (e.g. drd), add the argument --outer-tool=drd
Still to do/things to improve:
* Most (inner) tests are successful when running under an outer
memcheck. Need to analyse the reasons of remaining failures.
* The memcheck annotations in m_mallocfree.c can be improved:
- A superblock is marked 'undefined', it should rather be marked
'no access'.
- When a free block is splitted, the remaining free block is
not made 'no access'. Instead, it is made 'undefined'.
=> this decreases the chance to find bugs.
=> this is not very efficient (e.g. the rest of a superblock
is often marked undefined repetitively).
Similarly, the free block created by VG_(arena_memalign)
is marked 'undefined'. 'No access' would be preferrable.
- mkInuseBlock marks the new block as undefined. This is probably
not needed, as VALGRIND_MALLOCLIKE_BLOCK will do it already.
- VG_(arena_malloc) should give the requested size to
VALGRIND_MALLOCLIKE_BLOCK, not the malloc usable size,
as this decreases the chance to find buffer overrun bugs.
But giving the requested size is tricky (see comments in
the code).
* need to do memcheck annotations in m_poolalloc.c
so as to allow leak checking for pool allocated elements.
* vg_regtest.in
- should analyse the results of the outer and should
produce a separate result for the tests for which
the outer detects an error or a memory leak or ...
Changes done:
README_DEVELOPERS: document the new outer/inner features.
manual-core.xml: document the new sim-hint no-inner-prefix
tests/outer_inner.supp: new file, containing the suppressions for inner.
vg_regtest.in: implement new args --outer-valgrind, --outer-tool, --outer-args.
m_mallocfree.c: annotations for memcheck.
m_libcprint.c: handle the new sim-hint no-inner-prefix
m_main.c: do an (early) parse of --sim-hints
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12441
With --trace-children=yes, none/test/execve exec ve forever.
This avoids an infinite loop when running outer on inner regression
tests (for which --trace-children=yes is mandatory for the outer).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12440
* Redzones for custom alloc were not protected by VALGRIND_MALLOCLIKE_BLOCK.
mc_main.c client request handling completed with protection
of the redzones.
* custom_alloc.c test modified to test this case.
* mc_errors.c modified so as to first search for a malloc-ed block
bracketting the error : for a custom allocator, a recently freed
block can have just been re-allocated.
In such a case, describing the address (e.g. in case of error)
points to the block freed rather than to the block just allocated.
If there is *also* a recently freed block bracketting the address,
the block description is changed to indicate that.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12439
is failing on a 64 bit host.
The bug might or might not be related to some
errors "failed in UME with error 22"
(such as bug https://bugs.kde.org/show_bug.cgi?id=138424).
The bug is: when aspacem_maxAddr is very close to the upper limit,
and aspacem_minAddr is somewhat not close to 0, then
the computation of
aspacem_vStart = VG_PGROUNDUP((aspacem_minAddr + aspacem_maxAddr + 1) / 2);
can overflow.
The vStart value will then silently wrap around.
(please, give me my Ada language back :).
When overflowing, vStart will then be below the client cStart.
At least when running outer on inner on a 32 bit application on
a 64 bit system, this was causing strange problems.
I suppose that on a 64 bit system, a 32 bit application can use more
of the 4 Gb, and then the max address is higher and can more easily
overflow than on a 32 bit system.
Tested on f12/x86, debian6/amd64 (bi-arch).
+ run a few outer on inner x86 regression tests : these were all failing
and are now succesfully running.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12438
negatives, by marking the V bits that come from out of range parts of
the access as undefined; and hence any use of them leads to an value
error. Prior to this they were marked as defined and could be used
without error.
Behaviour of --partial-loads-ok=no (the default case) is unchanged.
Also add some testing thereof.
Fixes#294523. Modified version of a patch and testcase by Patrick
J. LoPresti (lopresti@gmail.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12430
since gcc complains about "statement with no effect" or some such for
the simple "0" version. Also, make the formal parameter names a bit
more unique.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12426
remove_mapping_callback: if the kernel tells us of a gap that
partially, but does not exactly, overlap a V segment, only record
directives to remove that part of the segment that actually falls
within the gap. Removing the entire V segment is incorrect and can
cause Memcheck to believe that memory not within the hole is
inaccessible, leading to floods of invalid errors. Fixes
https://bugzilla.mozilla.org/show_bug.cgi?id=715750
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12422
(found by running regression tests with an outer memcheck).
(validated by running all regression tests "natively" on x86 and amd64,
and re-running regressions tests with outer memcheck).
==7500== 160 bytes in 2 blocks are definitely lost in loss record 75 of 246
==7500== at 0x2803CEF7: vgPlain_arena_malloc (m_mallocfree.c:1599)
==7500== by 0x280AAFA5: vgModuleLocal_dinfo_zalloc (misc.c:48)
==7500== by 0x2804E2A4: vgPlain_newXA (m_xarray.c:68)
==7500== by 0x280B3CD6: unitary_range_list (readdwarf3.c:703)
==7500== by 0x280B66CF: parse_var_DIE (readdwarf3.c:1631)
==7500== by 0x280BA0A6: read_DIE (readdwarf3.c:3248)
==7500== by 0x280BA170: read_DIE (readdwarf3.c:3269)
==7500== by 0x280BABC4: T.364 (readdwarf3.c:3611)
==7500== by 0x280BC634: vgModuleLocal_new_dwarf3_reader (readdwarf3.c:4035)
==7500== by 0x280609F4: vgModuleLocal_read_elf_debug_info (readelf.c:2529)
==7500== by 0x2805BD31: vgPlain_di_notify_mmap (debuginfo.c:610)
==7500== by 0x280362E3: valgrind_main (m_main.c:1944)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12419
* make a reference to --vex-iropt-precise-memory-exns=yes
to obtain up to date registers values.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12416
* manual-core.xml : fix a typo
* include/pub_tool_inner.h : new file, defining macros for inner annotation
include/Makefile.am : reference this new file.
* syswrap-linux.c : when ENABLE_INNER, register the stacks for the outer.
(otherwise, nothing works properly).
* m_redir.c : avoid inner interpreting the outer vgpreload instructions.
* sema.c : annotate the semaphore with RWLOCK annotations for helgrind
* ticket-lock-linux.c : similar.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12414
Buffers should not be re-allocated in such a case.
(memory leak detected by running memcheck on memcheck)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12410
Previously it looked for the debuginfo object for "/system/X" in
"/sdcard/symbols/system/X". This commit removes the requirement for
"system" as the first path component, so the mapping is now "/X" (viz,
any absolute path) to "/sdcard/symbols/X".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12406
once place. This was breaking vg-in-place on platforms
needing gdbserver target description files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12401