Re: [Valgrind-developers] Re: Separate Calltree Skin for Valgrind 1.9.x

[Josef W. <Jos...@gm...>]

On Tuesday 28 January 2003 21:43, Nicholas Nethercote wrote:
> On Mon, 27 Jan 2003, Josef Weidendorfer wrote:
> > Can you have a short look at this?
> > Is this the correct way for a third-party valgrind skin source package?
> >
> > * Valgrind should install header files for compiling skins.
> > I had to add them to the skin sources :-(
>
> Um, I hadn't given this a great deal of thought.  I think I was imagining
> something simpler, eg:
>   - add a directory under valgrind/ containing the skin's code and
> Makefile.am - add the skin's name to configure.in and Makefile.am (by hand)

But this makes the process of distributing valgrind skins separate from 
valgrind core impossible.
I think the valgrind core is much like a library for skins, and we should
allow developing skins on a machine with a binary installation of valgrind.

I saw the problem with precompiled packages for Debian and my calltree patch 
with Valgrind 1.0.x:
The only possible way to get my patch was to remove the valgrind package and 
install the patched one. It would be much better to simple install a further 
package for a third-party skin. And this involves separate source packages, 
too.

You already made skin development independent from valgrind versions by 
introducing a skin interface version. Thus, skins should be distributable 
independent from valgrind releases.


> and then it all works.  I think;  that's how I've been doing things when
> writing new skins.  That way there's no problems with installing headers
> because they're all in the one place.  I wasn't expecting to have
> configure.in and all that for a skin.  I realise adding the name to
> configure.in and Makefile.am by hand isn't ideal, but it seems to me the
> most straightforward option...

See above.
Problems come up if a skin developer doesn't have access to valgrind CVS
and wants to distribute his skin ;-)


> > * I install a "calltree" script which is almost a simple copy of the
> > valgrind loader script. Only difference: It defaults to a skin with name
> > `basename $0`. As the script is called "calltree", it defaults to skin
> > "vgskin_calltree.so". Is this change sensible for the valgrind script
> > itself?
> > Problem: "calltree -h" gives help for the valgrind command, and not the
> > calltree script. Can we define a variable "VALGRIND_SCRIPT" with the
> > script name? Thus, valgrind could put out the correct help text.
> >
> > Valgrind 1.9.x should supply a "cachegrind" script, too.
> > If a user updates from 1.0.x to 1.9.x he will assume that executing
> > "cachegrind" is still valid (I already got a bug report regarding this!).
>
> I was hoping to get away from the need for multiple startup scripts with
> the --skin= option.  The removal of the 'cachegrind' script was deliberate
> (probably should have been documented).  Having lots of different startup
> scripts that are almost the same is not good.  I like the --skin way
> better, and if you get sick of typing it for your favourite skin it's not
> hard to define an alias for it.

This was just a suggestion. I like it the other way around ;-)
You don't have to have multiple startup scripts. With 'basename $0' as skin it 
would be enough to make (hard or soft) symlinks to the valgrind script named 
by the skin.

> As for the -h option, if a skin uses command line args, the function
> SK_(usage)() allows it to describe them.  Is this not enough for your
> purposes?

Of course.
I only thought about a solution to forward the name of a startup script to the 
valgrind core...

> > For the rewrite of the calltree skin, I want to add address mappings of
> > ELF objects to cachegrind.out (To allow usage of "nm" in KCachegrind for
> > assembler source annotations).
> > Can we add the following function to coregrind/vg_symtab2.c for this?
> >
> > SegInfo* VG_(get_obj) ( Addr a )
>
> Sure, done.

Thanks.

Josef

> N
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers