|
From: Daniel B. <dan...@gm...> - 2003-10-14 12:11:24
|
I've heard a new release of Valgrind will be made soon '20031012', and Julian is willing to integrate the patches to support 2.5/2.6 kernels. Does anyone have any idea what patches are required? Any help would be much appreciated! Please CC myself and js...@ac.... Thanks! -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
|
From: <ar...@de...> - 2003-10-14 13:52:47
|
I did these patches to support compilation of 20030725 for 2.6 kernels on Debian. I don't know if it's what you're looking for but there they are. "Daniel Blueman" <dan...@gm...> writes: > I've heard a new release of Valgrind will be made soon '20031012', and > Julian is willing to integrate the patches to support 2.5/2.6 kernels. > > Does anyone have any idea what patches are required? Any help would be much > appreciated! > > Please CC myself and js...@ac.... Thanks! > > -- > Daniel J Blueman > > NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... > Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService > > Jetzt kostenlos anmelden unter http://www.gmx.net > > +++ GMX - die erste Adresse für Mail, Message, More! +++ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Steve G <lin...@ya...> - 2003-10-14 19:57:04
|
Aside from 2.5/2.6...will any of the new skins be rolled in? I know several developers using crocus, but they are maintaining their own patch set just to use it with a current copy of valgrind. Annelid seems stable, too. -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2003-10-16 11:17:38
|
On Tue, 14 Oct 2003, Steve G wrote: > Aside from 2.5/2.6...will any of the new skins be rolled in? No, it's from the stable branch, no new features. > I know several developers using crocus, but they are maintaining > their own patch set just to use it with a current copy of > valgrind. I'm looking at distributing crocus as an independent skin, like Josef W's Calltree. But I haven't worked out all the relevant automakery, etc. Massif might be rolled into the CVS HEAD sometime, though. Or I could distribute that separately too. Not sure. > Annelid seems stable, too. Hmm, I don't think so; I know about all the duct tape and paper clips that are holding it together :) I'm not yet convinced Annelid is actually useful; if anyone has used it to find bugs, I'd like to hear from you. Thanks. N |
|
From: Daniel B. <dan...@gm...> - 2003-10-16 11:26:26
|
Crocus is good value, and since it is an additional skin to add, it looks reasonably safe to drop in this release. Just gets confusing on your webpage where you talk about 'signal handlers', then use 'interrupt handlers' instead, in the same context ;-) . Dan > On Tue, 14 Oct 2003, Steve G wrote: > > > Aside from 2.5/2.6...will any of the new skins be rolled in? > > No, it's from the stable branch, no new features. > > > I know several developers using crocus, but they are maintaining > > their own patch set just to use it with a current copy of > > valgrind. > > I'm looking at distributing crocus as an independent skin, like Josef W's > Calltree. But I haven't worked out all the relevant automakery, etc. > > Massif might be rolled into the CVS HEAD sometime, though. Or I could > distribute that separately too. Not sure. > > > Annelid seems stable, too. > > Hmm, I don't think so; I know about all the duct tape and paper clips > that are holding it together :) I'm not yet convinced Annelid is actually > useful; if anyone has used it to find bugs, I'd like to hear from you. > > Thanks. > > N > -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
|
From: Steve G <lin...@ya...> - 2003-10-16 13:12:49
|
>I'm looking at distributing crocus as an independent skin, >like Josef W's Calltree. That's a shame unless its your personal preference. The main valgrind homepage does not link to your homepage and a lot of people might not be able to find it (or other skins for that matter). It would be nice if there was a list of resources on the main homepage that pointed to these other skins. Then you have the problem of rolling a skin into whatever version of valgrind is on your system. Sometimes its easy, sometimes there's fixups. I think that developers will get the most benefit if some of these newer skins were rolled in so that they are getting more use. Then there's another scenario...I am co-maintainer of xinetd. Occassionally in the past someone would report a problem, perhaps a core dumper. I have asked people to run valgrind on their copy of xinetd on their system if I couldn't reproduce the problem. These people are not necessarily programmers and if they were faced with resolving diff's, I would not be able to get as high a quality of feedback. Granted, they do not have to do this with memcheck. But based on the problem, crocus might be a good one to have them to run. (Not all problems reported on the xinetd mail list are about xinetd. Sometimes they are having issues with the daemon that xinetd is supposed to be starting for them.) >Massif might be rolled into the CVS HEAD sometime, though. Or >I could distribute that separately too. Not sure. Out of curiosity, why is this a candidate for the main distribution? It has dependancies on other libraries which complicates things. I'm not trying to disparage the Massif skin, I think its a good thing. I'm just curious why a skin that complicates the build is more likely to get into the main distribution than one that doesn't. Just curious... :) I guess my point is that valgrind is now an essential tool in my research & projects. I'd like to see more tests and easier ways of pulling that all together for non-programmers. Thanks, -Steve Grubb __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: Josef W. <Jos...@gm...> - 2003-10-16 16:49:14
|
Hi, On Thursday 16 October 2003 15:12, Steve G wrote: > >I'm looking at distributing crocus as an independent skin, > >like Josef W's Calltree. > > That's a shame unless its your personal preference. The main > valgrind homepage does not link to your homepage and a lot of > people might not be able to find it (or other skins for that > matter). It would be nice if there was a list of resources on the > main homepage that pointed to these other skins. I support this. > Then you have the problem of rolling a skin into whatever version > of valgrind is on your system. Sometimes its easy, sometimes > there's fixups. I think that developers will get the most benefit > if some of these newer skins were rolled in so that they are > getting more use. I really don't think that distribution is the issue here. This is the job of distributors. And if you install valgrind yourself, what's the issue of doing "./configure; make install" a second time for a skin package? If this seems to be too idealistic: It's working with my Calltree skin with V 1.9.6, V-20030725 and V-20031012 this way, and if there's no change in the skin interface major version number, it should do so for future V releases, too. Josef |
|
From: Philippe E. <ph...@wa...> - 2003-10-16 16:38:09
|
Nicholas Nethercote wrote: > On Tue, 14 Oct 2003, Steve G wrote: > > >>Aside from 2.5/2.6...will any of the new skins be rolled in? > > > No, it's from the stable branch, no new features. > > >>I know several developers using crocus, but they are maintaining >>their own patch set just to use it with a current copy of >>valgrind. > > > I'm looking at distributing crocus as an independent skin, like Josef W's > Calltree. But I haven't worked out all the relevant automakery, etc. > > Massif might be rolled into the CVS HEAD sometime, though. Or I could > distribute that separately too. Not sure. > > >>Annelid seems stable, too. > > > Hmm, I don't think so; I know about all the duct tape and paper clips > that are holding it together :) I'm not yet convinced Annelid is actually > useful; if anyone has used it to find bugs, I'd like to hear from you. I don't get problem with Annelid except from the missing mremap. It'll be more usefull if you implement debug info to handle segment in .data and .bss. I think http://developer.kde.org/~sewardj/ "Interesting variants" should list the existing skin. Most of the existing can't be found through google. Annelid search don't find your skin in the first 50 hit (15,900), Annelid and debugger don't find it at all. regards, Philippe Elie |
|
From: Olly B. <ol...@su...> - 2003-10-16 17:22:55
|
On Thu, Oct 16, 2003 at 06:44:50PM +0000, Philippe Elie wrote: > I think http://developer.kde.org/~sewardj/ "Interesting variants" > should list the existing skin. Most of the existing can't be found > through google. Annelid search don't find your skin in the first 50 > hit (15,900), Annelid and debugger don't find it at all. Another useful link for the valgrind webpage would be to the valgrind CVS page on sourceforge - otherwise it's mightily hard to find unless you already know it's hosted there. My suggestion would be to make "CVS" in "you are welcome to build it from CVS" a link to here: http://sourceforge.net/cvs/?group_id=46268 Also the "Home Page" link on: http://sourceforge.net/projects/valgrind Takes you to the empty page at http://valgrind.sourceforge.net/ but it probably ought to link to http://developer.kde.org/~sewardj/ I'm not sure how you change this on sourceforge - I'm fairly sure I've done it before, but I couldn't see where on the admin pages it is. Cheers, Olly |
|
From: Daniel B. <dan...@gm...> - 2003-10-15 09:11:12
|
Hi Andrés, Thank you for your reply. Is there a chance that you be a little more specific about what patches, or where Julian can get them from? Many thanks, Dan > I did these patches to support compilation of 20030725 for 2.6 kernels on > Debian. > > I don't know if it's what you're looking for but there they are. > > "Daniel Blueman" <dan...@gm...> writes: > > > I've heard a new release of Valgrind will be made soon '20031012', and > > Julian is willing to integrate the patches to support 2.5/2.6 kernels. > > > > Does anyone have any idea what patches are required? Any help would be > mu > ch > > appreciated! > > > > Please CC myself and js...@ac.... Thanks! > > > > -- > > Daniel J Blueman > > > > NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... > > Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService > > > > Jetzt kostenlos anmelden unter http://www.gmx.net > > > > +++ GMX - die erste Adresse für Mail, Message, More! +++ > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > SourceForge.net hosts over 70,000 Open Source Projects. > > See the people who have HELPED US provide better services: > > Click here: http://sourceforge.net/supporters.php > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ |
|
From: Tom H. <th...@cy...> - 2003-10-15 09:46:25
|
In message <232...@ww...>
Daniel Blueman <dan...@gm...> wrote:
> Hi Andrés,
>
> Thank you for your reply. Is there a chance that you be a little more
> specific about what patches, or where Julian can get them from?
The patches were attached to his email... They were just minor patches
to configure to make it recognise a 2.6 kernel.
To be honest I'm not sure what it is you're after - are you looking
for patches to make valgrind build and work as now, using the hack to
force LD_ASSUME_KERNEL in the startup script, or are you looking for
patches to make valgrind cope with nptl?
If the latter then I'm not convinced that there's a sane way to do
it I'm afraid because libc and libpthread are so much in bed with each
other now it seems.
I have a patch to make valgrind emulate the kernel TLS support and
handle the GDT references, and it works fine for single threaded
programs run under nptl once you realise that ld.so sets up the thread
area for the first thread before valgrind gets control so you have to
use the get_thread_area system call to setup the initial TLS records
in valgrind.
The problem comes when you create a new thread - normally the pthread
library sets up the thread area for the new thread when it calls clone
to create it, but obviously the valgrind pthread simulation doesn't do
any of that.
The problem I ran in to was trying to work out to make valgrind
allocate the thread area on thread creation - working out it's size
and how to initialise it seems to be horribly complicated plus it
seems to involved cloning a thread descriptor in the same format as
the libpthread one because libc knows about that and goes through it
to find the TLS data as far as I can work out.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
> The problem I ran in to was trying to work out to make valgrind > allocate the thread area on thread creation - working out it's size > and how to initialise it seems to be horribly complicated plus it > seems to involved cloning a thread descriptor in the same format as > the libpthread one because libc knows about that and goes through it > to find the TLS data as far as I can work out. Even under linuxthreads, the very first instruction executed in a new thread can be a signal handler with access to thread-local storage. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104368 where linuxthreads signal handlers must be wrapped to check for such a case. Either the thread area (%gs region) must be setup no later than the clone syscall, or else the thread start function and all signal handlers must be wrapped to check for proper %gs. |