that specified shared objects contain specified symbols. Along with a
couple of regtests that unfortunately will fail on MacOSX.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11125
type STT_GNU_IFUNC which, instead of pointing directly at the
function, point at a routine which will return the address of
the real function. Redirection of indirect functions is handled
by valgrind as follows:
- When a redirection specification matches an indirect
function symbol an active redirection is added in the
normal way, but with the isIFunc flag set.
- When a call is made to an address which matches an
active redirection with the isIFunc flag set the call
is redirected, but not to the target address of the
redirection - instead it is sent to a small wrapper
routine that is preloaded into the client.
- The wrapper routine calls the original client routine
and collects the result, which it reports to valgrind
using a client request, and then returns the result to
the caller.
- When valgrind gets the client request it looks up the
active redirection for the indirect function and then
adds a new active redirection which redirects from the
address returned by the indirection function to the
redirection target. This new redirection does not have
the isIFunc flag set so behaves as a normal redirection.
In addition to the above we also add a few new redirections to
memcheck to capture internal calls made by glibc to things like
strlen, as these internal calls do not go through the indirect
function and instead go direct to the chosen implementation.
Based on a patch from Dodji Seketeli and comments from Jakub
Jelinek, this commit closes bug 206013.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10920
branch hereby becomes inactive. This currently breaks everything
except x86; fixes for amd64/ppc32 to follow.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5520
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
tool preload modules, which are called vgpreload_<tool>.so. Also
fixed a couple of comments relating to this.
(This need not be merged into 3_0_X.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4514
comments, neatened the debugging output, avoided unexpected side-effects
in functions, tweaked code to make it clearer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4028
- Renamed VG_INTERCEPT as VG_REPLACE_FUNCTION to make its purpose
clearer.
- Renamed VG_WRAPPER as VG_NOTIFY_ON_LOAD to make its purpose cleare.
Started calling that stuff "load notification".
- Moved various things into m_redir.c, a much more sensible place for
them. This reduced the number of exported functions overall. Renamed
intercept_demangle() as Z_decode() as part of this.
- Improved the documentation of this stuff, especially in
pub_core_redir.c.
- Got --run-libc-freeres=yes working again. It was doing nothing.
- Renamed vg_inject.so as vg_preload_core.so to match
vg_preload_<tool>.so
- Renamed vg_intercept.c as vg_preloaded.c. (I kept the "vg_" prefix
because this filename can appear in stack traces, so the "vg_" is a
useful hint for users that it belongs to Valgrind.)
- Removed all the Memcheck-specific calls to add_redirect_sym_to_sym()
from VG_(setup_redirect_table)(), instead using VG_REPLACE_FUNCTION in
mac_replace_strmem.c, just like vg_replace_malloc.c. This is the
right way to do it. This required moving some of
coregrind/pub_core_redir.h into the newly added
include/pub_tool_redir.h. add_redirect_sym_to_sym() is no longer
used...
- Now only handing off symbols to m_redir for inspection/decoding after
they have been deemed to be interesting by the symbol table reader.
- Factored out commonality between the add_redirect_*_to_* functions
into add_redirect_X_to_X().
- Added "Zh", meaning '-' ('h' for "hyphen"), to the Z-decoding scheme,
to handle sonames like "ld-linux-x86-64.so.2".
- Added a FAQ explaining the newly found issue of glibc aliasing
sometimes causing the wrong function name to appear in stack traces.
- Added a new regtest strchr.c. It's possible this will fail on some
platforms. If so, an alternative output file can be provided, but
I'd like to see it in practice first.
It's possible that there will be minor breakage on other
platforms/setups, but it should be minimal and easily fixable.
Plus some ordinary cleanups in symtab.c:
- Removed the old optimisation from VG_(addStr)() whereby it kept track
of the previous 5 added strings and avoiding duplicating any of them.
Turns out it was barely having any effect any more, and just
complicated things.
- Made read_symtab() more readable, by introducing a new variable
"sym_name" and introducing the auxiliary function
is_symbol_interesting().
- renamed the module variable 'segInfo' as 'segInfo_list' to make it
more obvious it's a module variable and not just some ordinary local
variable (which was an easy mistake to make).
-----------------------------------------------------------------------------
XXX: [later] remove add_redirect_sym_to_sym, and everything related to
X_to_sym? (ie. only need X_to_addr)
XXX: better function names? all those 'resolved' names...
[later...]
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3916
