|
From: Josef W. <Jos...@gm...> - 2003-01-27 17:48:32
|
Hi,
I finally had some time to simply port my calltree patch to a
skin for valgrind 1.9.x. You can get it from the KCachegrind site.
Can you have a short look at this?
Is this the correct way for a third-party valgrind skin source package?
Two remarks:
* Valgrind should install header files for compiling skins.
I had to add them to the skin sources :-(
* I install a "calltree" script which is almost a simple copy of the valg=
rind
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=20
calltree script. Can we define a variable "VALGRIND_SCRIPT" with the scri=
pt=20
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=20
"cachegrind" is still valid (I already got a bug report regarding this!).
For the rewrite of the calltree skin, I want to add address mappings of E=
LF=20
objects to cachegrind.out (To allow usage of "nm" in KCachegrind for=20
assembler source annotations).
Can we add the following function to coregrind/vg_symtab2.c for this?
SegInfo* VG_(get_obj) ( Addr a )
{
SegInfo* si;
ensure_debug_info_inited();
for (si =3D segInfo; si !=3D NULL; si =3D si->next) {
if (si->start <=3D a && a < si->start+si->size)
return si;
}
return 0;
}
The SegInfo structure itself is not known to skins and is only to be used=
with=20
e.g. VG_(seg_start).
Josef
|
|
From: Nicholas N. <nj...@ca...> - 2003-01-28 20:43:49
|
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) 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... > * 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. 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? > 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. N |
|
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 |
|
From: Nicholas N. <nj...@ca...> - 2003-02-02 10:29:14
|
On Wed, 29 Jan 2003, Josef Weidendorfer wrote: > 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. > > You already made skin development independent from valgrind versions by > introducing a skin interface version. Thus, skins should be distributable > independent from valgrind releases. Yes, you're right. I was forgetting about binary distributions. It would be good for skin packing/installing to be as simple as possible. Preferably, that would require only a Makefile.am plus the skin's source (in order to do a installation from source) but I don't know if we can get away with that little. Writing a configure.in is an unfortunate pain, as is the requirement of having aclocal.m4, AUTHORS, NEWS, and other mandatory files. Installing a binary version of a skin could be as simple as copying the vgskin_xxx.so into the appropriate directory, no? As for the include/ files (vg_skin.h, vg_constants_skin.h, vg_kerneliface.h), would it be possible for the skin to reuse the installed Valgrind's copies? Ie. by assuming that the skin will be installed under the valgrind/ directory? I'm not too familiar with all this stuff, if you have any suggestions for making the process simpler they would be welcome. > 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. > [...] > I only thought about a solution to forward the name of a startup script to the > valgrind core... Why do you want to forward the name of the script to the core? N |
|
From: Josef W. <Jos...@gm...> - 2003-02-03 10:44:00
|
On Sunday 02 February 2003 11:29, Nicholas Nethercote wrote: > On Wed, 29 Jan 2003, Josef Weidendorfer wrote: > > 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. > > > > You already made skin development independent from valgrind versions by > > introducing a skin interface version. Thus, skins should be distributable > > independent from valgrind releases. > > Yes, you're right. I was forgetting about binary distributions. > > It would be good for skin packing/installing to be as simple as possible. For the installer of my source package, it's a "configure;make install". For me as a packager, making a new skin version involves incrementing the version number in configure.in and doing a "make distcheck". This is easy enough. To get a skin developer started, we could provide a script "valgrind_make_example_skin <name>", copying a separate version of the example skin (i.e. a autoconf/automake version). > Preferably, that would require only a Makefile.am plus the skin's source > (in order to do a installation from source) but I don't know if we can > get away with that little. Writing a configure.in is an unfortunate pain, > as is the requirement of having aclocal.m4, AUTHORS, NEWS, and other > mandatory files. Yes. From a puristic viewpoint, autoconf/automake is a overkill for small source packages. Using autoconf/automake, source distributions must be selfcontained. I.e. you can't assume autoconf or automake to be installed. I know this pain from KDE: Using the qmake system from QT, the original QT-only kcachegrind was only around 80 KB of packed sources. Making a KDE package out of it, the size was around 400 KB. Thats the smallest source package you can get for a simple KDE version of "hello world" :-( FYI: I made my skin check for Valgrind 1.9.x so it won't be used with a Valgrind 2.x version. All the purpose was to see if there is any problem with separate skin packages... My configure.in is quite short. I check for the valgrind version and assume that my skin will run when valgrind was able to be installed on that machine. I'm not sure if this is a valid assumption, though. With include files on the machine, I *only* would check for a skin interface version compatible with my skin, i.e. all 1.x skin interfaces. Jeremy once suggested a valgrind-devel package with the include files. I think this is not our concern, as the distributors should provide these separate binary package splitting of valgrind. At least Suse is doing this splitting for all libraries. > Installing a binary version of a skin could be as simple as copying the > vgskin_xxx.so into the appropriate directory, no? Yes. But the installer has to know the target dir. At least for RPM. (I'm not sure about position independent packages) Thus, binary distributions will be distribution dependend. Another somewhat standard way is to provide a short "valgrind-config" script. A lot of packages provide this one (i.e. gnome-config, kde-config). It's kind of a easy way to provide parameters of a installed package. Installing a binary skin would be cp vgskin_xxx.so `valgrind-config --prefix`/lib/valgrind > As for the include/ files (vg_skin.h, vg_constants_skin.h, > vg_kerneliface.h), would it be possible for the skin to reuse the > installed Valgrind's copies? Ie. by assuming that the skin will be > installed under the valgrind/ directory? Yes. If they don't match, the configure script will complain. Note: Even with my current separate skin, there is no problem: If the installed valgrind doesn't match the include files of my package, the skin will compile but there will be a run time error. > I'm not too familiar with all this stuff, if you have any suggestions for > making the process simpler they would be welcome. Regarding a minimum size for third-party skins I don't know. For easy skin developing, a example template (see above) would be fine. > > 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. > > [...] > > I only thought about a solution to forward the name of a startup script > > to the valgrind core... > > Why do you want to forward the name of the script to the core? Only for a correct help message. But perhaps this is bogus. Josef |