arm64 Improve fpsr gdbsrv handling.
let the compiler handle the ULong to UInt conversion rather than
play with addresses.
Tested manually GDB+vgdb that reading and setting fpsr works, using
code such as (provided by Julian, I cannot write a single line of
arm64 asm :)
void set_fpsr ( uint32_t val ) {
__asm__ __volatile__( "msr fpsr, %0" : : "r"(val) : "cc" );
}
Carl Love [Fri, 8 Aug 2014 22:29:10 +0000 (22:29 +0000)]
This commit is for Bugzilla 334834.
A performance regression was found due to the
-02 -m64 flags not being included when compiling
the VEX PPC64 code. This commit fixes the Makefile
to pass the needed flags when compiling VEX PPC64
code.
This patch implements reading the directory information for source
files in the dwarf3 reader.
Basically, the change consists in replacing in the DiInlLoc struct
const HChar* filename; /* caller source filename */
by
UInt fndn_ix; /* index in di->fndnpool of caller source
dirname/filename */
A similar change is done in DiVariable struct, as the
read_filename_Table code is shared between the inline info reader
and the varinfo reader.
Note however that outputting dirname in variable description
is not done. Unclear if that is desired or not.
It should be trivially doable however.
Replacing filename by fndn_ix implies a bunch of semi-mechanical
changes.
The code to read the directory names is in the new function
static
XArray* read_dirname_xa (struct _DebugInfo* di, const HChar *compdir,
Cursor *c,
Bool td3 )
Note that readdwarf.c and readdwarf3.c have significant duplicated
logic. Would be nice to integrate these 2 dwarf readers in one
single reader. This function is directly inspired from
an equivalent piece of code in readdwarf.c.
Modified memcheck/tests/varinfo5.vgtest to test the dirname appears
in the inlined functions.
Impact on memory is neglectable (a few Kb on a big executable).
Carl Love [Thu, 7 Aug 2014 23:49:27 +0000 (23:49 +0000)]
This commit is for Bugzilla 334836. The Bugzilla contains patch 3 of 3
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334834. Note, there are no VEX changes in this patch.
PP64 Little Endian test case fixes.
This patch adds new LE and BE expect files where needed. In other
cases, the test was fixed to run correctly on LE and BE using based on
testing to see which platform is being used.
Where practical, the test cases have been changed so that the output
produced for BE and LE will be identical. The test cases that require
a major rewrite to make the output identical for BE and LE simply
had an additional expect file added.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14240
Carl Love [Thu, 7 Aug 2014 23:35:54 +0000 (23:35 +0000)]
This commit is for Bugzilla 334834. The Bugzilla contains patch 2 of 3
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334836.
POWER PC, add the functional Little Endian support, patch 2
The IBM POWER processor now supports both Big Endian and Little Endian.
The ABI for Little Endian also changes. Specifically, the function
descriptor is not used, the stack size changed, accessing the TOC
changed. Functions now have a local and a global entry point. Register
r2 contains the TOC for local calls and register r12 contains the TOC
for global calls. This patch makes the functional changes to the
Valgrind tool. The patch makes the changes needed for the
none/tests/ppc32 and none/tests/ppc64 Makefile.am. A number of the
ppc specific tests have Endian dependencies that are not fixed in
this patch. They are fixed in the next patch.
Per Julian's comments renamed coregrind/m_dispatch/dispatch-ppc64-linux.S
to coregrind/m_dispatch/dispatch-ppc64be-linux.S Created new file for LE
coregrind/m_dispatch/dispatch-ppc64le-linux.S. The same was done for
coregrind/m_syswrap/syscall-ppc-linux.S.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14239
Carl Love [Thu, 7 Aug 2014 23:17:29 +0000 (23:17 +0000)]
This commit is for Bugzilla 334384. The Bugzilla contains patch 1 of 3
to add PPC64 LE support. The other two patches can be found in Bugzillas
334834 and 334836. The commit does not have a VEX commit associated with it.
POWER PC, add initial Little Endian support
The IBM POWER processor now supports both Big Endian and Little Endian.
This patch renames the #defines with the name ppc64 to ppc64be for the BE
specific code. This patch adds the Little Endian #define ppc64le to the
Additionally, a few functions are renamed to remove BE from the name if the
function is used by BE and LE. Functions that are BE specific have BE put
in the name.
The goals of this patch is to make sure #defines, function names and
variables consistently use PPC64/ppc64 if it refers to BE and LE,
PPC64BE/ppc64be if it is specific to BE, PPC64LE/ppc64le if it is LE
specific. The patch does not break the code for PPC64 Big Endian.
The test files memcheck/tests/atomic_incs.c, tests/power_insn_available.c
and tests/power_insn_available.c are also updated to the new #define
definition for PPC64 BE.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14238
Julian Seward [Wed, 6 Aug 2014 19:52:12 +0000 (19:52 +0000)]
pre_mem_read_sockaddr: properly handle the NETLINK address family
rather than throwing to the default case. This stops Memcheck
reporting false positives for the NETLINK case.
fix 338024 inlined functions are not shown if DW_AT_ranges is used
Based on investigation and patch by Matthias Schwarzott.
(no small test found that reproduced the problem,
but the equivalent patch given in bug 338024 fixed the inlined stack
trace in a big shared lib).
Would be nice however to have a small test case ...
Bart Van Assche [Tue, 5 Aug 2014 11:35:48 +0000 (11:35 +0000)]
Linux system call wrappers: truncate ioctl request number to 32 bits
As explained in https://bugs.kde.org/show_bug.cgi?id=331829, when passing
an ioctl request number as an int to a function the request number will
be sign-extended to 64 bits on 64-bit systems. Avoid that this causes
Valgrind to fail to recognize an ioctl by truncating the request number
to 32 bits.
Fix dangling ref in m_errormgr.c + report all uninit fields in a syscall param
Some syscall verification code is allocating memory to generate
the string used to build an error, e.g. syswrap-generic.c verifying fields of
e.g socket addresses (pre_mem_read_sockaddr) or sendmsg/recvmsg args
(msghdr_foreachfield)
The allocated pointer was copied in the error created by VG_(maybe_record_error).
This was wrong for 2 reasons:
1. If the error is a new error, it is stored in a list of errors,
but the string memory was freed by pre_mem_read_sockaddr, msghdr_foreachfield, ...
This causes a dangling reference. Was at least visible when giving -v, which
re-prints all errors at the end of execution.
Probably this could have some consequences during run while generating new errors,
and comparing for equality with a recorded error having a dangling reference.
2. the same allocated string is re-used for each piece/field of the verified struct.
The code in mc_errors.c that checks that 2 errors are identical was then wrongly
considereing that 2 successive errors for 2 different fields for the same syscall
arg are identical, just because the error string happened to be produced at
the same address.
(it is believed that initially, the error string was assumed to be a static
string, which is not the case anymore, causing the above 2 problems).
Changes:
* The fix consists in duplicating in m_errormgr.c the given error string when
the error is recorded. In other words, the error string is now duplicated similarly
to the (optional) extra component of the error.
* memcheck/tests/linux/rfcomm.c test modified as now an error is reported
for each uninit field.
* socketaddr unknown family is also better reported (using sa_data field name,
rather than an empty field name.
* minor reformatting in m_errormgr.c, to be below 80 characters.
Some notes:
1. the string is only duplicated if the error is recorded
(ie. printed or the first time an error matches a suppression).
The string is not duplicated for duplicated errors or following errors
matching the first (suppressed) error.
The string is also not duplicated for 'unique errors' (that are printed
and then not recorded).
2. duplicating the string for each recorded error is not deemed to
use a lot of memory:
* error strings are usually NULL or short (often 10 bytes or so).
* we expect no program has a huge number of errors
If ever this string duplicate would be significant, having a DedupPoolAlloc
in m_errormgr.c for these strings would reduce this memory (as we expect to
have very few different strings, even with millions of errors).
* Add lock announcements in various helgrind errors that were not
announcing the locks
* ensure locks are also announced in xml (note that this is compatible
with xml protocol version 4, so no impact on GUI which properly
implement the protocol)
Changes done:
* Like other HG record_error functions, HG_(record_error_LockOrder) is
now passing Lock* rather than lock guest addresses.
* update exp files for tests that were showing locks without announcing them
* change tc14_laog_dinphils.c and tc15_laog_lockdel.c so as to
have same sizes on 32 and 64 bits systems for allocated or symbol sizes.
* factorise all code that was announcing first lock observation
* enable xml lock announcement
glibc 2.3.4 does not appear to define PTRACE_GETSIGINFO. This was
observed on a RHEL5 system on s390. Provide a suitable definition.
Tweak gdbserver_tests/filter_stderr to ignore messages related to
interrupted poll system calls.
Describe the lock address in a lock announcement message.
(note that some error messages are not announcing the lock,
which is not that nice).
At least the lock order violation message do not announce locks.
That should be improved/fixed
Factor out VG_(exit_now) to contain the syscall incantation to terminate
the process. Make ML_(am_exit) and VG_(exit) use it, thereby avoiding
double maintenance.
Introduce libcbase_assert macro and use it in VG_(strncpy_safely) to
document the case that function cannot handle.
Add stub functions to memcheck/tests/unit_libcbase.c to satisfy new
dependencies.
optimise readpdb.c filename and dirname handling, following r14158
r14158 introduced a dedup pool to store pairs (filename,dirname).
The windows debug info reader (readpdb.c) performance was still to be
improved, as calls to ML_(addFnDn) were done for each line loc to add.
With this patch, the nr of calls to ML_(addFnDn) should be reduced
significantly.
Code has been compiled and regtested on linux, but no windows/wine test
was done.
Add a new heuristic 'length64' to detect interior pointers
pointing at offset 64bit of a block, when the first 8 bytes contains
the block size - 8. This is e.g. used by sqlite3MemMalloc.
Patch adding (or showing the proper/not confusing) helgrind thread nr for block
and stack address description.
* A race condition on an allocated block shows the stacktrace, but
does not show the thread # that allocated the block.
This patch adds the output of the thread # that allocated the block.
* The patch also fixes the confusion that might appear between
the core threadid and the helgrind thread nr in Stack address description:
A printed stack addrinfo was containing a thread id, while all other helgrind
messages are using (supposed to use) an 'helgrind thread #' which
is used in the thread announcement.
Basically, the idea is to let a tool set a "tool specific thread nr'
in an addrinfo.
The pretty printing of the addrinfo is then by preference showing this
thread nr (if it was set, i.e. different of 0).
Currently, only helgrind uses this addrinfo tnr.
Note: in xml mode, the output is matching the protocol description.
I.e., GUI should not be impacted by this change, if they properly implement
the xml protocol.
* Also, make the output produced by m_addrinfo consistent:
The message 'block was alloc'd at' is changed to be like all other
output : one character indent, and starting with an uppercase
Mark Wielaard [Thu, 17 Jul 2014 13:29:43 +0000 (13:29 +0000)]
Omit frame pointer also for main in ppc ldst_multiple test.
Other functions already explicitly omitted the frame pointer. Also
do that for main to prevent gcc 4.8.2 complaining:
ldst_multiple.c: In function ‘main’:
ldst_multiple.c:180:5: error: frame pointer required, but reserved
int main(void)
^
ldst_multiple.c:31:18: note: for ‘r31’
register HWord_t r31 asm("r31");
Mark Wielaard [Thu, 17 Jul 2014 10:56:26 +0000 (10:56 +0000)]
ppc64 ifunc_wrapper add casts suggested by gcc warning.
vg_preloaded.c: In function ‘_vgnU_ifunc_wrapper’:
vg_preloaded.c:91:13: warning: assignment makes integer from pointer without a cast [enabled by default]
arm64: get_Dwarf_Reg: at least handle the case of requesting XSP
instead of failing. This makes some of the memcheck/tests/varinfo*
tests work somewhat correctly on arm64-linux.
Mark Wielaard [Tue, 15 Jul 2014 15:07:01 +0000 (15:07 +0000)]
Bug 337094 ifunc wrapper is broken on ppc64.
ppc64 uses function descriptors, so we need to get the actual function
entry address for the VG_USERREQ__ADD_IFUNC_TARGET client request, but
we need to return the function descriptor itself from the ifunc_wrapper.
So, peak dinfo memory decreases by about 36Mb, and final by 15Mb.
(for info, valgrind 3.9.0 uses
dinfo: 158941184/109666304 max/curr mmap'd, 156775944/107590656 max/curr
So, compared to 3.9.0, dinfo peak decreases by about 40%, and the final
memory is divided by more than 2).
The memory decrease is obtained by:
* using a dedup pool to store filename/dirname pair for the loctab source/line
information.
As typically, there is not a lot of such pairs, typically a UShort is
good enough to identify a fn/dn pair in a dedup pool.
To avoid losing memory due to alignment, the fndn indexes are stored
in a "parallel" array to the DiLoc loctab array, with entries having
1, or 2 or 4 bytes according to the nr of fn/dn pairs in the dedup pool.
See priv_storage.h comments for details.
(there was a extensible WordArray local implementation in readdwarf.c.
As with this change, we use an xarray, the local implementation was
removed).
* the memory needed for --read-inline-info is slightly decreased (-2Mb)
by removing the (unused) dirname from the DiInlLoc struct.
Handling dirname for inlined function caller implies to rework
the dwarf3 parser read_filename_table common to the var and inlinfo parser.
Waiting for this to be done, the dirname component is removed from DiInlLoc.
* the stabs reader (readstabs.c) is broken since 3.9.0.
For this change, the code has been updated to make it compile with the new
DiLoc/FnDn dedup pool. As the code is completely broken, a vg_assert(0)
has been put at the begin of the stabs reader.
* the pdb reader (readpdb.c) has been trivially updated and should still work.
It has not been tested (how do we test this ?).
A follow-up patch will be done to avoid doing too many calls to
ML_(addFnDn) : instead of having one call per ML_(addLineInfo), one
should have a single call done when reading the filename table.
This has also be tested in an outer/inner setup, to verify no
memory leak/bugs.
Rollback the (functional) effect of 13944 and 14134
Re-opening the FIFO before closing it gives (difficult to understand)
problems => rollback the change that keeps the FIFO opened.
Rather handle the race condition by retrying at vgdb side.
See extensive comments in remote-utils.c
Apply text_debug_bias to inline IP extracted from dwarf3
Without this biasing, inline info is not correct for shared objects.
Updated test varinfo5 to use --read-inline-info=yes and added
an inline test case.
Note: the varinfo reader does not understand the inlining info, and
so variables in inlined functions are not properly described.
OSX 10.9/10.8: Debuginfo reading FSM: enable recording of r-- mappings
so as to enable arrival at acceptance states via calls to
VG_(di_notify_vm_protect).
Darwin only: don't tell aspacemgr about the kernel commpage -- only
tell the tool. This is because telling the aspacemgr about it causes
the sync checker to fail entirely on Darwin.
Add -Wno-tautological-compare to the standard compile flags, if that
is accepted. With XCode 5.5.1 -Wtautological-compare appears to come
as standard, and it generates a lot of mostly useless noise.
Follow up to rev 13944
13944 objective was to avoid having a vgdb that connects to a just forked child
that would have the FIFO still opened, while its parent would close it.
However, in case a previous vgdb closed the FIFO, the read FIFO in the parent
is put in 'eof status' by the kernel. So, readchar will then return eof
in the parent unless another vgdb re-opens the FIFO in write.
So, gdbsrv does not stop anymore on error if needed, due to this readchar
giving eof.
The only way to reset this eof condition is to close the fd.
But we must always have the FIFO open (to avoid the race condition that
rev 13944 fixed)
=> in case of error, first re-open the FIFO, before closing the (previous)
FIFO fd (which is in eof state and cannot be properly used anymore).
projects / thirdparty / valgrind.git / log
