|
From: Josef W. <Jos...@gm...> - 2003-01-29 00:04:54
|
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 |