Re: [Valgrind-developers] External tools with VG 3.1

[Tom H. <to...@co...>]

In message <200...@gm...>
          Josef Weidendorfer <Jos...@gm...> wrote:

> * As was discussed when introducing the static linking, a nice
> property now is that external tools can work - and thus, be
> distributed - on its own. The missing thing here is the launcher.
> What is the launcher doing exactly? When I run a static tool
> directly, I get a SEGFAULT.

All the launcher does is decided which tool to run and exec it - there
should be no need for a tool writer to recreate the launcher as it will
try and run unknown tools quite happily.

Basically it takes the argument to --tool and then just does an exec
of /usr/lib/valgrind/<tool> so if you install a statically linked callgrind
binary in the valgrind library directory it should all work.

I don't know why you get a segmentation fault when you run a tool
directly - that used to work, and was a useful way of debugging the
tools but Julian disabled it when he added the stuff to pass through
the launcher name for client execs. It now does this for me:

dunsmere [~] % /tmp/valgrind-debug/lib/valgrind/memcheck date
valgrind: You cannot run '/tmp/valgrind-debug/lib/valgrind/memcheck' directly.
valgrind: You should use $prefix/bin/valgrind.

> Do you think the launcher will change a lot with VG releases? If yes,
> it would be good to make a library here, too. If not, I simply could
> copy m_launcher.c into callgrind (to produce a "callgrind" binary),
> or do you see a problem with this?

Well there is some work pending on the launcher to enable biarch
support where it will work out which version of the tool to run
based on the architecture of the binary it is running.

At that point the tools will move down a level so the launcher
will exec something like /usr/lib/valgrind/x86-linux/memcheck.

> The thing here is to get binary packages for external tools which are
> independent from any installed VG version / do not depend on a VG
> installation at all. This would mean that you can always install the
> newest valgrind nearside an older callgrind, without me being
> forced to deliver a callgrind release matching the newest VG ;-)

The default valgrind launcher should generally work fine with
newer/older tools I would expect.

Tom

-- 
Tom Hughes (to...@co...)
http://www.compton.nu/