|
From: Nicholas N. <nj...@ca...> - 2004-07-20 11:52:13
|
[CC'ing vg-dev]
On Tue, 20 Jul 2004, Julian Seward wrote:
>
> Hi. I added a new redirection entry (fruitlessly, but that's
> not the point)
>
> VG_(add_redirect_sym)("file:/lib/ld-2.3.3.so", "strchr",
> "*vgpreload_memcheck.so*", "strchr");
I'm not sure what is the difference between the redirection table and the
LIBALIAS stuff. Someone wrote a patch for one of the bugs in bugzilla
where they replaced all of the redirection table with LIBALIAS usage, I
think.
> at the end of VG_(setup_code_redirect_table), and got this:
>
> ==20560== REDIRECT soname:libc.so.6(__GI___res_state) to
> soname:libpthread.so.0(__res_state)
> ==20560== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0
> (__res_state)
> ==20560== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy)
> ==20560== REDIRECT soname:libc.so.6(strnlen) to
> *vgpreload_memcheck.so*(strnlen)
> ==20560== REDIRECT soname:ld-linux.so.2(stpcpy) to
> *vgpreload_memcheck.so*(stpcpy)
> ==20560== REDIRECT soname:ld-linux.so.2(strchr) to
> *vgpreload_memcheck.so*(strchr)
> ==20560== REDIRECT file:/lib/ld-2.3.3.so(strchr) to
> *vgpreload_memcheck.so*(strchr)
> ==20560==
> ==20560== Reading syms
> from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vg_inject.so
> (0x1B8FB000)
> ==20560== Conditional jump or move depends on uninitialised value(s)
> ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> ==20560== Reading syms
> from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vgpreload_memcheck.so
> (0x1B8FE000)
>
> valgrind: vg_skiplist.c:377 (vgPlain_SkipList_Insert): Assertion `n == ((void
> *)0) || (l->cmp)(key_of_node(l, n), k) != 0' failed.
> ==20560== at 0xB002BF80: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
> ==20560== by 0xB002BF7F: assert_fail (vg_mylibc.c:1165)
> ==20560== by 0xB002BFBD: vgPlain_core_assert_fail (vg_mylibc.c:1176)
> ==20560== by 0xB0039498: vgPlain_SkipList_Insert (vg_skiplist.c:381)
>
> Wow! What did I do wrong?
>
> Can I ask .. what is a skiplist? Is it like a FiniteMap in Haskell
> in the sense that it maps arbitrary keys (with ordering) to arbitrary
> values?
Yes. Read the comment at the top of coregrind/vg_skiplist.c; it explains
how they work in general, and also the obscure structure layout that is
used in the implementation to allow arbitrary length keys and values.
> Am trying to figure out why SuSE often gives me this at startup
>
> ==20560== Conditional jump or move depends on uninitialised value(s)
> ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> (no further frames, alas)
>
> It's somehow env dependent, and I've chased that a bit, with no success.
> In any case, I'd prefer a solution that didn't depend subtly on
> environment variables. I wanted to be sure this strchr call was being
> redirected, which I think it is. That probably means my only option
> is to suppress this, but having only a single frame to match on is
> not good. Umm. Ideas?
Maybe LIBALIAS instead of the redirection table for strchr()? I don't
know, I don't understand the redirection stuff at all.
N
|
|
From: Jeremy F. <je...@go...> - 2004-07-20 23:33:07
|
On Tue, 2004-07-20 at 12:51 +0100, Nicholas Nethercote wrote:
> [CC'ing vg-dev]
>
> On Tue, 20 Jul 2004, Julian Seward wrote:
>
> >
> > Hi. I added a new redirection entry (fruitlessly, but that's
> > not the point)
> >
> > VG_(add_redirect_sym)("file:/lib/ld-2.3.3.so", "strchr",
> > "*vgpreload_memcheck.so*", "strchr");
>
> I'm not sure what is the difference between the redirection table and the
> LIBALIAS stuff. Someone wrote a patch for one of the bugs in bugzilla
> where they replaced all of the redirection table with LIBALIAS usage, I
> think.
>
> > at the end of VG_(setup_code_redirect_table), and got this:
> >
> > ==20560== REDIRECT soname:libc.so.6(__GI___res_state) to
> > soname:libpthread.so.0(__res_state)
> > ==20560== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0
> > (__res_state)
> > ==20560== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy)
> > ==20560== REDIRECT soname:libc.so.6(strnlen) to
> > *vgpreload_memcheck.so*(strnlen)
> > ==20560== REDIRECT soname:ld-linux.so.2(stpcpy) to
> > *vgpreload_memcheck.so*(stpcpy)
> > ==20560== REDIRECT soname:ld-linux.so.2(strchr) to
> > *vgpreload_memcheck.so*(strchr)
> > ==20560== REDIRECT file:/lib/ld-2.3.3.so(strchr) to
> > *vgpreload_memcheck.so*(strchr)
> > ==20560==
> > ==20560== Reading syms
> > from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vg_inject.so
> > (0x1B8FB000)
> > ==20560== Conditional jump or move depends on uninitialised value(s)
> > ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> > ==20560== Reading syms
> > from /home/sewardj/VgHEAD/valgrind/Inst/lib/valgrind/vgpreload_memcheck.so
> > (0x1B8FE000)
> >
> > valgrind: vg_skiplist.c:377 (vgPlain_SkipList_Insert): Assertion `n == ((void
> > *)0) || (l->cmp)(key_of_node(l, n), k) != 0' failed.
> > ==20560== at 0xB002BF80: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
> > ==20560== by 0xB002BF7F: assert_fail (vg_mylibc.c:1165)
> > ==20560== by 0xB002BFBD: vgPlain_core_assert_fail (vg_mylibc.c:1176)
> > ==20560== by 0xB0039498: vgPlain_SkipList_Insert (vg_skiplist.c:381)
> >
> > Wow! What did I do wrong?
I think it's trying to tell you, in its own clumsy way, that you've got
a duplicate entry in the list. It doesn't support duplicates.
> >
> > Can I ask .. what is a skiplist? Is it like a FiniteMap in Haskell
> > in the sense that it maps arbitrary keys (with ordering) to arbitrary
> > values?
>
> Yes. Read the comment at the top of coregrind/vg_skiplist.c; it explains
> how they work in general, and also the obscure structure layout that is
> used in the implementation to allow arbitrary length keys and values.
>
> > Am trying to figure out why SuSE often gives me this at startup
> >
> > ==20560== Conditional jump or move depends on uninitialised value(s)
> > ==20560== at 0x1B8F4126: strchr (in /lib/ld-2.3.3.so)
> > (no further frames, alas)
> >
> > It's somehow env dependent, and I've chased that a bit, with no success.
> > In any case, I'd prefer a solution that didn't depend subtly on
> > environment variables. I wanted to be sure this strchr call was being
> > redirected, which I think it is. That probably means my only option
> > is to suppress this, but having only a single frame to match on is
> > not good. Umm. Ideas?
>
> Maybe LIBALIAS instead of the redirection table for strchr()? I don't
> know, I don't understand the redirection stuff at all.
There's a few things going on here. You can explicitly register a
redirect with VG_(add_redirect_sym)(). This is the base mechanism, but
I don't like it much because it forces you to scatter special knowledge
into too many places.
The preferred mechanism is the implicit one, where a shared object (ie,
Tool, or something else), magically registers its own redirections.
Unfortunately this has the appearance of being a bit magical, because
this stuff is encoded into special symbols with special names (courtesy
of Robert). It's a bit ugly, but its nicer than the alternatives which
were 1) more complex and 2) ELF-specific.
LIBALIAS is the macro which implements this for vg_replace_malloc.c, but
the real meat is in VG_INTERCEPT/VG_INTERCEPT_ALIAS() macros and the
genintercepts.pl script. These generate aliased symbols with the magic
mangling which is used by the symtable parser to automatically install
the intercepts.
The upshot is that when a client loads a library which happens to be
provided by Valgrind, and that library wants to intercept some symbols
from other client-side libraries, the interceptions are put in place
when the library's symtab is loaded.
The interceptions act like "come-froms" - they specify a to and from
address, either numerically or symbolically. When both from and to
addresses have been resolved into real addresses, the interception
becomes active, which means that when we start executing the BB at
"from", the translator reads code from "to" instead.
Unresolved intercepts can hang around forever, if they're specified to
match libraries and/or symbols which are never loaded.
Also, a given interception pattern can only become resolved once, even
if it matches multiple symbols (ie, matching "malloc" in all libraries
will resolve to the first malloc it finds). This is probably a bug, but
it does encourage more precise matching conditions which is not a bad
thing.
J
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-25 12:21:28
|
On Tue, 20 Jul 2004, Jeremy Fitzhardinge wrote: >> Maybe LIBALIAS instead of the redirection table for strchr()? I don't >> know, I don't understand the redirection stuff at all. > > There's a few things going on here. You can explicitly register a > redirect with VG_(add_redirect_sym)(). This is the base mechanism, but > I don't like it much because it forces you to scatter special knowledge > into too many places. > > The preferred mechanism is the implicit one, where a shared object (ie, > Tool, or something else), magically registers its own redirections. > Unfortunately this has the appearance of being a bit magical, because > this stuff is encoded into special symbols with special names (courtesy > of Robert). It's a bit ugly, but its nicer than the alternatives which > were 1) more complex and 2) ELF-specific. So, can VG_(add_redirect_sym)() be abolished, and its uses replaced by interceptions? Having two ways of doing things is not good... N |
|
From: Jeremy F. <je...@go...> - 2004-07-25 19:35:22
|
On Sun, 2004-07-25 at 13:21 +0100, Nicholas Nethercote wrote: > So, can VG_(add_redirect_sym)() be abolished, and its uses replaced by > interceptions? Having two ways of doing things is not good... No, because that's the underlying mechanism to implement everything. And the symtab hackery probably can't deal with every possible case. J |