Thanks for the tip.  I saw that code while grepping for VG_(set_IP),
and I thought I was doing what that function was doing.  However,
looking closer, I see that the IP is being set to the result of
VG_(client_freeres) which contains the address of the client function
that is called.  I am pretty sure that I am not getting the correct
address of the client function I want to call.  I've searched around
for some function that can provide me the client address given a
function name, and there doesn't appear to be one.  Any other way I
can get a client function address?

As an aside, I am interested in why the client program executes
normally, despite me calling VG_(set_IP) with an invalid address from
SE_(start_client_code) above.  I read that function executes in the
client context, but nothing seemingly changes when I call VG_(set_IP)
in a function tracking thread creation, which runs in the tool's
context.  I would expect the tool or the client to crash when I set an
invalid IP, but the client executes as if the IP is correct.

On Thu, Mar 5, 2020 at 3:58 PM Philippe Waroquiers
<philippe.waroqui...@skynet.be> wrote:
>
> You might find some inspiration by reading the function final_tidyup
> in coregrind/m_main.c.
>
> final_tidyup is calling some client code part of malloc library.
>
> Philippe
>
>
> On Thu, 2020-03-05 at 11:27 -0500, Derrick McKee wrote:
> > My intent is to write a tool that waits for another process to write
> > client addresses to a pipe, and then execute the specified function
> > with a fixed number of arguments.  I'm unconcerned about whether the
> > specified function actually has the assumed arity or not, though.  I
> > tried the following, but it seems that the function is not called.
> > However, this is what I am wanting to do.
> > ---------------------------------------------
> > static void SE_(start_client_code)(ThreadId tid, ULong blocks_dispatched) {
> >   if (!client_running && tid == client_thread_id) {
> >     VG_(umsg)
> >     ("Thread %u is starting executing at instruction 0x%lx with "
> >      "blocks_dispatched=%llu\n",
> >      tid, VG_(get_IP)(tid), blocks_dispatched);
> >     client_running = True;
> >     VG_(umsg)("Thread %u is about to call target function\n", tid);
> >     OrigFn fn;
> >     fn.nraddr = (Addr)0x401145; // Function address in client
> >     CALL_FN_v_v(fn);  // Assume no arguments are passed in
> >     VG_(umsg)("Thread %u returned\n", tid);
> >     client_running = False;
> >   }
> > }
> >
> > static void SE_(pre_clo_init)(void) {
> >     ....
> >     VG_(track_start_client_code)(SE_(start_client_code));
> > }
> >
> > VG_DETERMINE_INTERFACE_VERSION(SE_(pre_clo_init))
> > --------------------------------------
> > Reading the documentation, it seems that CALL_FN_v_v should be called
> > from the client code, but I want to use my tool with any binary.  I
> > also tried using the VG_(set_IP) function (admittedly against the
> > valgrind tool contract), but that seemingly didn't work either.  Any
> > other thoughts, or is this just something I cannot do with valgrind?
> >
> > On Tue, Mar 3, 2020 at 11:01 AM Derrick McKee <derrick.mc...@gmail.com> 
> > wrote:
> > > I am also interested in instrumenting the guest binary, as well as
> > > change which guest function I execute at run time.  So LD_PRELOAD
> > > won't help me here.
> > >
> > > On Tue, Mar 3, 2020 at 10:41 AM John Reiser <jrei...@bitwagon.com> wrote:
> > > > > I am trying to make a tool that intercepts the call to main, and then
> > > > > call an arbitrary function within the guest with arbitrary function
> > > > > arguments.
> > > >
> > > > This can be done without valgrind by using LD_PRELOAD environment 
> > > > variable
> > > > and RTLD_NEXT (see "man dlsym"):
> > > >
> > > >      LD_PRELOAD=main_interceptor.so  ./my_app args...
> > > >
> > > > where main_interceptor.so is a shared library that has a function main()
> > > > and that can call the original main() by using dlsym(RTLD_NEXT, "main").
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Valgrind-users mailing list
> > > > Valgrind-users@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > >
> > >
> > > --
> > > Derrick McKee
> > > Phone: (703) 957-9362
> > > Email: derrick.mc...@gmail.com
> >
> >
>


-- 
Derrick McKee
Phone: (703) 957-9362
Email: derrick.mc...@gmail.com


_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to