|
From: Alfonso A. <alf...@gm...> - 2012-12-13 17:06:02
|
OK, I found a solution. If executing under valgrind, simply hijack _vgr10070ZU_libcZdsoZa_calloc directly instead of calloc. It works like a charm. Thanks a lot for your help, really :) On Thu, Dec 13, 2012 at 12:44 AM, Alfonso Acosta <alf...@gm...> wrote: > On Thu, Dec 13, 2012 at 12:03 AM, John Reiser <jr...@bi...> wrote: >>> calloc -> _vgr10070ZU_libcZdsoZa_calloc >>> >>> But after "moving" the start of calloc to orig_calloc, we want: >>> >>> orig_calloc -> _vgr10070ZU_libcZdsoZa_calloc >> >> You control orig_calloc, so what is stopping you? > > By reassigning redirections I really meant replacing them by another > one. True, leaving the resolution of _vgr10070ZU_libcZdsoZa_calloc > aside, l could indeed add that redirection myself. However, I think it > doesn't cut it: > > As I understand it, even with that extra redirection, the initial > "calloc -> _vgr10070ZU_libcZdsoZa_calloc" redirection would still be > active, breaking my hijacking mechanism, which would render my code > unusable. Remember that I expect calloc_hijacker to be called instead > of calloc. With the initial redirection still in place, > _vgr10070ZU_libcZdsoZa_calloc would be called instead. > >> The routine calloc_hijacker could check whether the instruction layout >> remains the same as the first time, deduce that valgrind is active, >> and re-arrange the code further. (Remember to sync the Icache; >> on x86 any backwards branch suffices, but on other architectures >> a system call is necessary.) > > > I might be missing something, but I don't see how calloc_hijacker > would be called at all if "calloc -> _vgr10070ZU_libcZdsoZa_calloc" is > still in place. > > After skimming the sources of Valgrind I see that some functions are > replaced and not wrapped (with no possibility to access the original > function) and calloc seems to be one of them. Even if calloc was > wrapped, it is up to the wrapped to call the original function. |