To implement QGetTlsAddr, gdbsrv has to know how to get the glibc dtv
address and the module id from the link_map.
These 2 things are dependent on the internals of glibc.
The dependency is mostly isolated in a few lines of arch dependent
code or in an external utility that used a hack + -ldl lib to find
the offset of the modid in the link_map structure.
Tested on x86/amd64/ppc64/s390x. Somewhat tested on ppc32 and arm64.
Untested/a few #ifdef-ed lines not compiled on arm/mips32/mips64
and darwin.
For more background info about thread local storage handling, see
'ELF Handling For Thread-Local Storage' http://www.akkadia.org/drepper/tls.pdf
Changes:
* auxprogs/getoff.c new auxilliary program to get platform specific offsets
(currently only the offset for the module id in struct link_map).
* configure.ac : check for dlinfo(RTLD_DI_TLS_MODID) needed for getoff.c
* new gdbserver_tests/hgtls, testing various types of __thread variables
* various m_gdbserver files:
- implement decoding of the QGetTlsAddr query
- for each platform: platform specific code to get the dtv
- call to external program getoff-<platform> the first time an
__thread variable is printed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14283
of memcheck and helgrind in a common module:
pub_tool_addrinfo.h pub_core_addrinfo.h m_addrinfo.c
At the same time, the factorised code is made usable by other
tools also (and is used by the gdbserver command 'v.info location'
which replaces the helgrind 'describe addr' introduced 1 week ago
and which is now callable by all tools).
The new address description code can describe more addresses
(e.g. for memcheck, if the block is not on the free list anymore,
but is in an arena free list, this will also be described).
Similarly, helgrind address description can now describe more addresses
when --read-var-info=no is given (e.g. global symbols are
described, or addresses on the stack are described as
being on the stack, freed blocks in the arena free list are
described, ...).
See e.g. the change in helgrind/tests/annotate_rwlock.stderr.exp
or locked_vs_unlocked2.stderr.exp
The patch touches many files, but is basically a lot of improvements
in helgrind output files.
The code changes are mostly refactorisation of existing code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13965
Most of the time, Valgrind masks async signals, and polls for such
signals at regular interval.
There is a very narrow range of code (around client syscall logic)
where such signals are unmasked (as they must be able to interrupt
syscalls).
This is the only range of code where Valgrind is expecting to
receive such a signal.
When gdbserver is ptraced invoked, Valgrind is artificially made
to jump out of this code portion. Signals are not masked.
When ptraceing valgrind, vgdb will get these signals but cannot
transmit them immediately, otherwise they arrive in range
of code where they are not expected (causing internal error
in syscall logic) and/or causing gdbserver syscalls to be
interrupted.
3 solutions to solve that were looked at:
1. have the gdbserver code masking signals "as quickly as possible".
Easy to implement, but this leaves still a small window
of code where signals are not masked and would cause a problem.
2. have vgdb setting the SIGMASK of valgrind before invoking
gdbserver.
This would be easy to implement, but changing the SIGMASK
of the ptrace-d process is only available on very recent kernels.
3. have vgdb queuing signals, and only transmitting them once
gdbserver invocation is finished.
This 3rd solution has been implemented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13896
Assertion
valgrind: m_transtab.c:674 (find_TTEntry_from_hcode):
Assertion '(UChar*)sec->tt[tteNo].tcptr <= (UChar*)hcode' failed.
failure (encountered on some platforms while running gdbsrv tests).
The problem is related to invalidated entries and the host_extents
mapping between hostcode and the translation table entry.
The problem: when an entry is invalidated, the translation table
entry is changed to status Deleted. However, the host extent array
element is not cleaned up.
If a search for a host code address (find_TTEntry_from_hcode)
finds this entry, the translation table entry in Deleted status
is considered as a 'not found', which ensures that the invalidated
entry is not used (e.g. for chaining).
This is all ok.
However, it might be that this Deleted entry is re-used
(see function VG_(add_to_transtab), searching for a Empty
or Deleted entry.
If the Deleted entry is re-used, then a search for the
dead host code can give a result pointing to the re-used
entry. That is clearly wrong.
Note that it is unclear if this bug can only be triggered
while using gdbsrv or if this bug can be triggered with
just the "normal" invalidation logic of translation.
gdbsrv being a heavy "user" of invalidation, it might
be it helps to trigger the code. Alternatively, as gdbsrv
invalidation is special (e.g. invalidation of some entries
is done during translation of other entries), it might be
the bug is specific to gdbsrv.
In any case, to avoid the bug:
searching for an host code address must not only
ignore Deleted entries, but must also ignore an entry
found via a host_extent element which is for a Deleted
entry that was re-used afterwards (pointed to by a
newer host_extent element).
Multiple solutions are possible for fixing the bug:
Sol1: cleanup the host_extents array when an entry is deleted.
The cleanup is however deemed costly:
Each invalidate operation must do a search in the host_extents.
The host_extents array must then be "compacted" to remove
the "dead" host extent element from the array.
The compact operation can be avoided if instead of removing
the element, one marks instead the element as "dead"
e.g. by using one bit of UInt len for that:
UInt len : 31;
Bool dead : 1;
This avoids the compact, but still incurrs the cost of
search and modify the host_extent for each entry invalidated.
Invalidating entries seems to be a critical operation
(e.g. specific ECLASS related data structures have been
done to allow fast deletion).
=> it is deemed that a solution not incurring cost during
invaliation is preferrable.
* Sol 2: detect in find_TTEntry_from_hcode
that the host_extent element is re-used, and handle it similarly
to an host_extents which points at a Deleted entry.
This detection is possible as if an entry is re-used after
having been deleted, this implies that its host code will be
after the end of the host code of the deleted entry
(as host code of a sector is not re-used).
The attached patch implements this solution.
* Sol 3: avoid re-using an entry : the entry would then stay
in Deleted state. This is deemed not ok as it would
imply that invalidation of entries will cause a sector to
become full faster.
The patch:
* adds a new function
Bool HostExtent__is_dead (const HostExtent* hx, const Sector* sec)
telling if the host extent hx from sector sec is a dead entry.
* this function is used in find_TTEntry_from_hcode so that
dead host extents are not resulting in host code to be found.
* adds a regression test which caused the assert failure before
(bug was found/reported/isolated in a small test case by Dejan Jevtic).
* To check the logic of HostExtent__is_dead, m_transtab.c sanity check is
completed to verify that the nr of entries in use in a sector is equal
to the nr of non dead entries in the host extent array.
* adds/improves traces in m_transtab.c (enabled at compile
time using #define DEBUG_TRANSTAB).
Some already existing 'if (0)' conditions are replaced
by if (DEBUG_TRANSTAB)
Regression tested on
f12/x86
debian6/amd64 (also with export EXTRA_REGTEST_OPTS=--sanity-level=4)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13290
patch from Mark Wielaard.
(with small modifications).
Also clarified some comments related to the resume reply.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13052
about leaked or reachable blocks)
This patch implements two new memcheck gdbserver monitor commands:
block_list <loss_record_nr>
after a leak search, shows the list of blocks of <loss_record_nr>
who_points_at <addr> [<len>]
shows places pointing inside <len> (default 1) bytes at <addr>
(with len 1, only shows "start pointers" pointing exactly to <addr>,
with len > 1, will also show "interior pointers")
Compiled and reg-tested on f12/x86, deb5/amd64, f16/ppc64.
The 'block_list' command is implemented on top of the
lr_array/lc_chunks/lc_extras arrays used during the last leak search.
NB: no impact on the memory for the typical Valgrind usage where a leak
search is only done at the end of the run.
Printing the block_list of a loss record simply consists in scanning the
lc_chunks to find back the chunks corresponding to the loss record for which
block lists is requested.
The 'who_points_at' command is implemented by doing a scan similar to
(but simpler than) the leak search scan.
lc_scan_memory has been enhanced to have a mode to search for a specific
address, rather than to search for all allocated blocks.
VG_(apply_to_GP_regs) has been enhanced to also provide the ThreadId and
register name in the callback function.
The patch touches multiple files (but most changes are easy/trivial or factorise
existing code).
Most significant changes are in memcheck/mc_leakcheck.c :
* changed the LC_Extra struct to remember the clique for indirect leaks
(size of structure not changed).
* made lr_array a static global
* changed lc_scan_memory:
to have a search mode for a specific address (for who_points_at)
(for leak search) to pass a 'current clique' in addition to the clique
leader
so as to have a proper clique hierarchy for indirectly leaked blocks.
* print_results: reset values at the beginning of the print_result of the
next leak search, rather than at the end of print_results of the previous
leak search.
This allows to continue showing the same info for loss records till a new
leak search is done.
* new function print_clique which recursively prints a group of leaked
blocks, starting from the clique leader.
* new function MC_(print_block_list) : calls print_clique for each clique
leader found for the given loss record.
* static void scan_memory_root_set : code extracted from
MC_(detect_memory_leaks) (no relevant change)
* void MC_(who_points_at) : calls scan_memory_root_set, lc_scan_memory
and VG_(apply_to_GP_regs)(search_address_in_GP_reg) to search
pointers to the given address.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12357
--cmd-time-out
* changed prefixes of Valgrind core monitor commands from vg. to v.
* removed prefixes of Tool monitor commands
* memcheck leak_check 'leakpossible' arg renamed to 'possibleleak'
* memcheck make_memory 'ifaddressabledefined' arg renamed to
'Definedifaddressable'
(with uppercase D to avoid confusion with 'defined' arg).
* vgdb options
- Some doc updates : more logical option order documentation,
specify 'standalone' for options aimed at standalone usage.
- added option --cmd-time-out for standalone vgdb
(comment of Josef Weindendorfer, needed to interface with a callgrind GUI)
* updated tests according to the above.
* updated documentation according to the above.
* some additional minor doc fixes/clarifications
(Philippe Waroquiers, philippe.waroquiers@skynet.be). Bug 214909
comment 111.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11844
--vgdb-error=N is specified, print a bit of text telling the user the
magic commands to give GDB in order to attach to the process.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11822
Patch that fixes the problem reported by Christian Borntraeger.
The problem was created by keeping the shared memory mapped file opened
without reason till the process does an exec.
In case of a chain of forked processes (without exec), the range of safe_fd
reserved for Valgrind own usage becomes exhausted.
* coregrind/m_gdbserver/remote-utils.c :
do not VG_(safe_fd) shared_mem_fd (as it is now closed directly)
close shared_mem_fd once file is mmap-ed and written.
* gdbserver_tests/nlfork_chain.stderr.exp,nlfork_chain.vgtest,
fork_chain.c,nlfork_chain.stdout.exp:
new files
* gdbserver_tests/Makefile.am:
modified for new nlfork_chain test
(patch from #214909 c 103,
Philippe Waroquiers, philippe.waroquiers@skynet.be)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11818
