Florian Krohm [Sat, 11 Oct 2014 14:48:38 +0000 (14:48 +0000)]
Merge the memory allocation bits from libvex.h into main_util.c.
This is to avoid linkage problems due to unresolved symbols for
some compilers. See also valgrind r14600 and BZ #339542.
Carl Love [Thu, 9 Oct 2014 21:08:25 +0000 (21:08 +0000)]
This patch makes the needed changes to the lxvw4x for Little Endian.
The data was being loaded in the Big Endian data order for most
cases. The code in host_ppc_isel.c was changed to do a right
shift and to permute the hi and lo registers in the other order
to ensure the data was always loaded in BE order. The lxvw4x
emulation in guest_ppc_toIR.c was changed to permute the data from
the BE order to LE order when running on an LE system.
follow up to fix for 339721 assertion 'check_sibling == sibling' failed in readdwarf3.c ...
The fix committed in revision 14603 is properly fixing the bug 339721.
However, when enabling the dwarf tracing, the DW_FORM_ref_sig8 causes
a segmentation violation, as the tracing code is shared with the
reading code. But the DW_FORM_ref_sig8 reading code is dereferencing
some data structure that is only initialised when --read-var-info=yes.
So, in case DW_FORM_ref_sig8 form reading is done and --read-var-info=no,
then check that we are tracing, and avoid dereferencing the (not initialised)
signature hash table.
Florian Krohm [Tue, 7 Oct 2014 18:36:28 +0000 (18:36 +0000)]
Merge revisions 14372 and 14607 from the BUF_REMOVAL branch to trunk.
This change makes VG_(clo_suppressions), VG_(clo_fullpath_after),
and VG_(clo_req_tsyms) XArrays. They used to be arrays of fixed size.
Carl Love [Tue, 7 Oct 2014 18:20:39 +0000 (18:20 +0000)]
This commit just makes white space changes to the three files in commit
r2966 so I can fix the commit message for that commit. The previous
commit message was "msg". The "msg" was the file with the commit message below.
The first attempt to fix the false positive message "Invalid read of size"
was to change to a V128 read instead of four 32-bit reads. Unfortunately,
this caused some regression test failures that were not caught before
committing the change.
This patch implements the V128 read without creating any regression failures.
The issue with the previous fix is that the lvx instruction was used to
do the V128 fetch. Unfortunately, that instruction takes the effective
address masks it to make it 16 byte aligned and then does the fetch. So,
non-aligned fetches do not work correctly. The fix in this patch does
two aligned fetches with the lvx instruction, calculates a how to permute
the data from the two loads and then permutes the data so the result in the
vector register is the correct value for an unaligned fetch.
Florian Krohm [Tue, 7 Oct 2014 14:28:52 +0000 (14:28 +0000)]
Merge revisions 14230, 14602, and 14604 from the BUF_REMOVAL branch to trunk.
The change eliminates the fixed size buffers in gen_suppression and
show_used_suppressions. This is achieved by changing the return type from
VG_TDICT_CALL(tool_get_extra_suppression_info and
VG_TDICT_CALL(tool_print_extra_suppression_use from Bool to SizeT.
A return value of 0 indicates that nothing (except the terminating '\0'
which is always inserted) was written to the buffer. This corresponds to the
previous False return value. A return value which is equal to the buffer
size (that was passed in as function argument) indicates that the buffer was
not large enough. The caller then resizes the buffer and retries.
Otherwise, the buffer was large enough.
Regtested with a resize value of 1.
fix 339721 assertion 'check_sibling == sibling' failed in readdwarf3.c ...
The skip code was wrongly skipping 16 bytes, while only 8 are read
for a DW_FORM_ref_sig8.
Note that the problem is made visible by an assert when using
--trace-symtab=yes but in fact this is a real bug in the dwarf reader,
that was introduced in one of the optimisations done for the inline info.
It can manifest itself with other symptoms:
One of the 2 following assertions can fail:
vg_assert (check_sibling == sibling);
vg_assert (get_position_of_Cursor (&check_skip)
== get_position_of_Cursor (&c));
Or the following error can be given:
--29973-- WARNING: Serious error when reading debug info
--29973-- When reading debug info from /home/philippe/valgrind/trunk_untouched/memcheck/tests/dw4:
--29973-- Overrun whilst reading .debug_info section
Florian Krohm [Mon, 6 Oct 2014 21:04:14 +0000 (21:04 +0000)]
Followup to r14600. Copy the contents of pub_core_guest.h to pub_tool_guest.h
to make it available to tools. This allows to remove quite a bit of
ifdeffery from memcheck's mc_machine.c
Florian Krohm [Mon, 6 Oct 2014 16:41:14 +0000 (16:41 +0000)]
Entangle header files a bit. Specifically, pub_core_basics.h no longer
includes libvex.h. It isn't needed to successfully compile pub_core_basics.h
standalone and the declarations libvex.h provides aren't used as broadly as
the comment in the code implied.
Move the guest-specific includes and some ifdeffery to the new file
pub_core_guest.h
For the curious reader: The change above avoids a problem when linking the
linux-launcher which previously included libvex.h indirectly. libvex.h also
defines the inline function LibVEX_Alloc which, when emitted, causes the
link step to fail due to unresoled references (as the launcher does not link
against libvex.a). See also BZ #339542.
Julian Seward [Thu, 2 Oct 2014 16:15:30 +0000 (16:15 +0000)]
guest_amd64_spechelper: fill in a number of missing cases for
conditions after SUBQ/SUBL/SUBW. Also, add cases for
Overflow-after-ADDL/SUBL for the benefit of code generated by
Javascript JITs.
Julian Seward [Thu, 2 Oct 2014 16:13:20 +0000 (16:13 +0000)]
Add folding rules for: Sar64(x,0) and Sar32(x,0). Immediate
shifts by zero seem to have a surprisingly large perf hit on
Intels, possibly due to the bizarre eflags/rflags semantics
involved.
Julian Seward [Thu, 2 Oct 2014 11:32:39 +0000 (11:32 +0000)]
guest_amd64_spechelper: number (in comments) and reorder the spec
cases for arbitrary-condition-after-sub32/sub64. This makes it easier
to see which cases are missing. No functional change.
Florian Krohm [Wed, 1 Oct 2014 14:16:05 +0000 (14:16 +0000)]
Merge revisions 14337, 14596 from the BUF_REMOVAL branch to trunk.
Change callgrind's init_cmdbuf function to allocate a large enough
buffer for the command line.
Merge six easy pieces from the BUF_REMOVAL branch:
r14271 Audit a few buffer sizes, increase one.
r14280 Audit buffer size.
r14296 Remove a few unneeded header files.
r14310 Replace fixed size buffers with a large enough buffers.
r14338 Remove a dead assignment in print_bbcs and make global variable
print_fd a local variable.
r14359 Remove a benign macro redefinition in cachegrind.
Merge revisions 14216,14591,14593 from the BUF_REMOVAL branch to trunk.
Chang the semantics of VG_(getgroups) to support querying the number
of supplementary group IDs which simplifies obtaining them and gets
rid of fixed size buffers.
Carl Love [Mon, 29 Sep 2014 19:33:00 +0000 (19:33 +0000)]
ppc64: lxvw4x instruction uses four 32-byte loads. When run on an
application that does partial loads an error message is generated by
valgrind about Invalid read of size 4. Valgrind is incorrectly
detecting the invalid read. The four loads were replaced
by a single 128-bit load. The invalid read message can now be
suppressed using the command line option " --partial-loads-ok=yes ".
Merge revisions 14212 and 14586 from the BUF_REMOVAL branch to trunk.
The change eliminates the use of fixed size buffers for path names.
There was a comment in the code that dynamic memory allocation could
not be used. But that is no longer true.
Clean up #includes.
Merge r14229 from the BUF_REMOVAL branch to trunk.
Function MC_(snprintf_delta) requires a buffer of size 31 or larger to
avoid overflow.Add an assert, change and document the buffer size and
fix all call sites. Remove magic constants along the way.
Merge r14208 from BUF_REMOVAL branch to trunk.
In function read_dot_valgrindrc use a large enough buffer
allocated on the stack.
Also assert that the passed in directory is not NULL. This is
true at all call sites. The old code would have attempted to read
/.valgrindrc for dir == NULL and I don't think we want that.
Merge 14206,14207,14261,14577,14578 from BUF_REMOVAL branch to trunk.
This changes VG_(record_startup_wd) to dynamically allocate a large
enough buffer for the directory name. As the dynamic memory manager has
started up a while ago, this is quite safe. Also rewrite VG_(get_startup_wd)
to simply return the directory name. No more messing with copying it
around. Adapt call sites.
Merge revisions 14203,14574,14575 from the BUF_REMOVAL
branch to trunk.
This change eliminates the fixed size buffers in VG_(basename)
and VG_(dirname).
Remove unneeded header file which does not exist on Darwin.
Disable test for darwin as pthread_setname_np is not implemented.
But setting and observing the threadname is what this test is all about.
Petar Jovanovic [Sat, 27 Sep 2014 05:18:21 +0000 (05:18 +0000)]
mips: extend mips_features with a check for FPU
Extend mips_features with "hard-float" query to which mips_features will
respond whether or not the platform is meant to have a floating point unit.
The query is not a runtime check, but a built-time check.
Carl Love [Thu, 25 Sep 2014 15:57:31 +0000 (15:57 +0000)]
The function mk_AvDuplicateRI() stores 16 bytes to memory and then
fetches the data into a vector register. The load was being
generated as a lvewx instead of a lvx instruction by the code:
/* Effectively splat the r_src value to dst */
addInstr(env, PPCInstr_AvLdSt( True/*ld*/, 4, dst, am_offset_zero ) );
The second argument controls which load instruction is generated. The
second argument should have been 16 to generate the lvx instruction not
the lvewx instruction. The issue was reported on the Freescale processor
for the vsptlb instruction. The issue was not detected before because
the backend code generation used the same vector register to load into
as was used previously to create the data. However, the code generation
is dependent on the HW/Distro/compiler. If the same register isn't used
the bug appears. The issue was found with Valgrind 3.10.0 on the Freescale
processor as the Valgrind code generation didn't happen to pick the same
register to do the load into.
The testbuckets none/tests/ppc{32,64} did not build in case the
toolchain did not support -maltivec -mabi=altivec.
This should work now. Fixes BZ #338731
Carl Love [Tue, 23 Sep 2014 16:22:36 +0000 (16:22 +0000)]
The PPC64 store quad instruction is updating the address register with the
effective address of the store. The instruction should not update the
address register. The issue is due to the two putIReg() calls at the end of
the instruction. The two putIReg() calls were removed to fix the bug.
Remove the valgrind_support parameter from LibVEX_Init. It's unused
and looks like an anachronism. VEX is also cleaner without valgrind things
creeping in.
Handle explicitely all enum values in 'switch' on AddrInfo tag
(reported by Florian)
Note that Addr_Undescribed will cause an assert if such
an undescribed addrinfo is pretty printed, as normally
such addrinfo should always be described before being pretty printed.
Mark Wielaard [Thu, 18 Sep 2014 12:24:53 +0000 (12:24 +0000)]
Old STABS code is still being compiled, but never used. Remove it.
Since valgrind 3.9.0 the STABS support was already disabled completely.
But the code was still there being compiled and we were still searching
for stabs sections in binaries. Completely remove all sources, tests and
references. Add a note to coregrind/m_debuginfo/README.txt to mention
the old code can be found in the subversion repository.
Prepare NEWS sections for the next release 3.11.0
+ add fixed bug
339020 - ppc64: memcheck/tests/ppc64/power_ISA2_05 failing in nightly build
in the fixed bugs section.
Carl Love [Wed, 17 Sep 2014 17:43:08 +0000 (17:43 +0000)]
Valgrind regression test fix for stfdpx instruction.
There is a bug in the stfdpx instruction test for ppc32 and ppc64.
The inline assembly to move the arguments into the registers before
the store instruction were moving from the register not to the
register. The error has been fixed. This results in a change in
the expected output.
Additionally, it was noted that the inline assembly was using "f" rather
then "d" for the double arguments. Similarly, the prints should have
been %lf not %f for doubles. These changes were made but they did not
change the output of the tests.
Couple of fixes:
- deepCopyIRConst failed to copy Ico_V256 constants
- deepCopyIRExpr did not copy Iex_Binder expressions
- handle_gets_Stmt should also handle an Ist_Put statement
coregrind files shall use vg_assert not tl_assert.
Tool files shall use tl_assert not vg_assert.
Fix code accordingly.
Adapted check_headers_and_includes to make sure the code
stays clean in that respect.
Remove a comment that is no longer valid. The real reason we (now)
don't provide strtoll etc is that we don't need the flexibility and
are too lazy to implement the general case :) But that does not
warrant a comment in the code.
Tidy up m_wordfm.
First, as the allocator function does not fail, there is no need
to assert its return value.
Second, remove commented out (since r8765) function VG_(isEmptyFM).
Third, remove VG_(getNodeSizeFM) from the API. The details of the
implementation do not need to be exposed.
Fourth, for consistency require that the copy functions for keys and
values in VG_(dopyFM) (which are essentially like allocators) return
non-NULL values for non-NULL arguments if they return.
Fifth, document NULL-ness of return values for VG_(newFM), VG_(dopyFM),
and VG_(newBag). Remove pointless asserts at call sites.
Six, change avl_dopy to assert that the node the function is
supposed to copy is not NULL. It is called that way anyhow. With
that change the function never returns NULL which allows us to
simplify the call sites. Checking the return value is no longer needed.
projects / thirdparty / valgrind.git / log
