|
From: Josef W. <Jos...@gm...> - 2005-10-15 15:55:37
|
Hi, it seems that VG 3.1. comes along nicely. In adding support for it in callgrind, there are some changes required as tools are linked statically now: * VG should install the needed library(ies) so that an external tool can be statically linked. * 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. 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? 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 ;-) Josef |
|
From: Tom H. <to...@co...> - 2005-10-15 16:32:32
|
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/
|
|
From: Josef W. <Jos...@gm...> - 2005-10-15 18:21:04
|
On Saturday 15 October 2005 18:32, Tom Hughes wrote:
> 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.
Yes.
But as I said, I saw it as a big plus for the static linking of tools to be
able to install them without needing any valgrind installation at all.
No need to worry about version mismatches.
Can you ensure that the launcher from say VG 3.2 will
work flawlessly with callgrind linked with VG 3.1 ?
If not, external tools still would need to have a
version check at runtime as we have now.
I can get rid of this problem if I provide my own launcher ("callgrind").
BTW: Is a launcher like this enough:
#!/bin/sh
export VALGRIND_LAUNCHER=callgrind
exec /usr/local/lib/valgrind/callgrind $*
Or is there another issue that a binary package of an external tool
would have to depend on a valgrind installation?
What about vg_preload_core.so?
> 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.
Ah, ok. I thought there might be some "magic" here.
I just tried, and it works now:
~> VALGRIND_LAUNCHER= /usr/local/lib/valgrind/memcheck ls
==414== Memcheck, a memory error detector.
...
Josef
|
|
From: Tom H. <to...@co...> - 2005-10-15 21:38:31
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> Can you ensure that the launcher from say VG 3.2 will
> work flawlessly with callgrind linked with VG 3.1 ?
Well not absolutely, but it seems likely.
> If not, external tools still would need to have a
> version check at runtime as we have now.
I believe that is on the to do list.
> I can get rid of this problem if I provide my own launcher ("callgrind").
> BTW: Is a launcher like this enough:
>
> #!/bin/sh
> export VALGRIND_LAUNCHER=callgrind
> exec /usr/local/lib/valgrind/callgrind $*
In principle I suspect so, at least until you want biarch support.
> Or is there another issue that a binary package of an external tool
> would have to depend on a valgrind installation?
> What about vg_preload_core.so?
That would be an issue, yes. It's only used to trap __libc_freeres
at the momemt though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-15 19:24:00
|
> 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 agree. Except also it figures out the name of the launcher and sets VALGRIND_LAUNCHER to this value, so that when child process is exec'd and we want to trace it, the name of the launcher is known. > 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. Yeh .. that just means really "VALGRIND_LAUNCHER is not set". Perhaps it would be better to reword the message. So as Josef says the following is probably OK: #!/bin/sh export VALGRIND_LAUNCHER=callgrind exec /usr/local/lib/valgrind/callgrind $* J |