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 by Matthias Schwarzott (with small modif)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14179
old glibc defined kernel user_pt_regs, but newer glibc instead
define user_regs_struct. Add a configure test to see what we need.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14176
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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14175
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");
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14173
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]
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14172
instead of failing. This makes some of the memcheck/tests/varinfo*
tests work somewhat correctly on arm64-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14164
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14163
* Mention --read-inline-info=yes as an alternative to compile without inlining.
* Mention that stabs debuginfo reader is not working anymore since 3.9.0
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14160
On a big executable, the trunk needs:
dinfo: 134873088/71438336 max/curr mmap'd, 134607808/66717872 max/curr
With the patch, we have:
dinfo: 99065856/56836096 max/curr mmap'd, 97883776/51663656 max/curr
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14158
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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14147
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14146
tell the tool. This is because telling the aspacemgr about it causes
the sync checker to fail entirely on Darwin.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14137
is accepted. With XCode 5.5.1 -Wtautological-compare appears to come
as standard, and it generates a lot of mostly useless noise.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14136
(called very often, and has a fast/slow case)
This slightly improve the performance of reading the image.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14135
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).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14134
* Avoid printing the size of a null dedup pool
* Avoid warnings of 2 unused variables on some platforms
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14132
