|
From: Julian S. <js...@ac...> - 2011-08-11 19:30:43
|
On Monday, July 25, 2011, Jakub Jelinek wrote:
> On Mon, Jul 25, 2011 at 03:05:56PM +0200, Julian Seward wrote:
> > One other thing: when you say "change somewhat the behavior of the
> > program" what do you mean? The redirects are all intended to be
> > functionally identical to the functions they replace.
>
> By that I mean that the .got.plt section with your approach will actually
> contain a pointer to valgrind's replacement. No normal code will probably
> look at that, but perhaps something like ltrace might.
Sorry to go on about this even more .. I've been thinking about the
redirection machinery some more, with a view to fixing 275284
(memmove vs memcpy redirection swampage) and I ended up reading the
long discussion on 206013, the ifunc-redir report, as background.
I'm concerned that the ifunc-redir fix makes the redirection machinery
complex, and fixing 275284 is going to make it even more complex.
So my question: is it actually necessary to redirect ifunc functions?
Couldn't we just add normal redirections for all possible target addresses
that an ifunc could point at? Would that work? There surely can't
be more than a handful of (eg) strlen implementations in libc, can there?
What I'm contemplating is a way to separate the actions of writing a
replacement function from that of specifying what functions it is a
replacement for. At the moment these concepts are glued together, and
the fact that some function X is a replacement for Y is encoded in
X's name. Hence if I want to have replacements for both "strlen" and
"__specialised_implementation_of_strlen", I have to use the STRLEN
macro in mc_replace_strmem.c, and I end up with two copies of the
replacement function in vgpreload_memcheck-amd64-linux.so. Which is
stupid.
If such a separation was possible, then I could
(1) write a single replacement for (eg) strlen then
I could add specifications saying that all the known variants
of strlen in libc should be redirected to it, hence making
the ifunc stuff more or less redundant, and
and
(2) write a single memmove replacement, and specify that all
known libc variants of both memmove and memcopy should be redirected
to it. This would fix 275284. (Of course it would still be necessary
to generalise the symbol table stuff to allow multiple symbols at the
same address, as per https://bugs.kde.org/show_bug.cgi?id=275284#c12
This would also fix the problem described in c13 of that bug.
J
|