[uml-devel] Re: Valgrind meets UML

[uml-devel] Re: Valgrind meets UML

[Giovanni Marzot]

Hi,

I see this email below...

Can anyone confirm if the patches to valgrind mentioned below have found 
there way into the release?

I will be attempting this with 2.4.20-6um.

Any words of wisdom appreciated. Has anyone used this combination 
succesfully?

I wonder what "teaching valgrind about the false positives" entails.

thanks for any info, GSM

 >bulb@ucw.cz said:
 >> Is it possible to run 2.4.20-3um (or -4um - I have not got around to
 >> updating yet) under valgrind?
 >>
 >> Does it need some specific config options to work?
 >
 >Any recent UML is as valgrindable as the UML mentioned in the post you 
 >saw.
 >
 >You need CONFIG_MODE_SKAS, !CONFIG_MODE_TT, and 
 >CONFIG_KERNEL_STACK_ORDER=3.
 >
 >You also probably need some valgrind patches unless the stuff I and 
 >Jeremy
 >have done have been merged into valgrind CVS.
 >
 >Once valgrind is working, you need to go through the false positives and
 >teach valgrind about how the kernel deals with memory allocation.  This is
 >the point at which I stopped.




-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Valgrind meets UML

[Jeremy Fitzhardinge]

On Thu, 2003-10-23 at 07:40, Giovanni Marzot wrote:
> Can anyone confirm if the patches to valgrind mentioned below have found 
> there way into the release?

They haven't.  They were mostly slimy hacks to see what needed fixing,
rather than proper fixes.  The good news is that I've been busily
incorporating proper fixes and redesigns into Valgrind, so the
development version should be capable of running uml unpatched soon.

> I wonder what "teaching valgrind about the false positives" entails.

Not everything Valgrind reports is an error.  You can either generate a
suppression rule to tell V not to report it, or you can use annotations
in your program to tell V what's really going on.

	J



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Valgrind meets UML

[Giovanni Marzot]

Thank you for the reply.

Jeremy Fitzhardinge wrote:
> On Thu, 2003-10-23 at 07:40, Giovanni Marzot wrote:
> 
>>Can anyone confirm if the patches to valgrind mentioned below have found 
>>there way into the release?
> 
> 
> They haven't.  They were mostly slimy hacks to see what needed fixing,
> rather than proper fixes.  The good news is that I've been busily
> incorporating proper fixes and redesigns into Valgrind, so the
> development version should be capable of running uml unpatched soon.

hmmm...Should I wait until this is done or is there something I can try 
in the meantime.

Are the old patches even available anywhere?

If you have something you would like me to try out (even if its grungy) 
I would be happy to give it a whirl.

> 
> 
>>I wonder what "teaching valgrind about the false positives" entails.
> 
> 
> Not everything Valgrind reports is an error.  You can either generate a
> suppression rule to tell V not to report it, or you can use annotations
> in your program to tell V what's really going on.

cool.

-GSM

> 
> 	J
> 





-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Valgrind meets UML

[Jeremy Fitzhardinge]

On Thu, 2003-10-23 at 09:11, Giovanni Marzot wrote:
> hmmm...Should I wait until this is done or is there something I can try 
> in the meantime.
> 
> Are the old patches even available anywhere?

The old patches have either been merged or won't apply any more. 
Normally I would say "try the CVS version", but we're in the process of
migrating away from SF's CVS - I hope that will be done in the next few
days.

	J



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Valgrind meets UML

[Jeff Dike]

gmarzot@nortelnetworks.com said:
> Any words of wisdom appreciated. Has anyone used this combination
> succesfully?

I ran out of free time about a year ago when playing with this, but I did
have UML and Valgrind playing together.

> I wonder what "teaching valgrind about the false positives" entails. 

However, I didn't get anything useful out of it.  This is because Valgrind
knows nothing about the kernel memory allocators.  I started describing them,
but didn't get too far.

IIRC, you add special macros into the allocators when the status of a region
of memory changes.  I.e.
	a buffer being returned from an allocator is declared readable and 
writeable
	a buffer being freed is declared unreadable and unwriteable (or maybe
just inaccessible, I forgot)

These macros expand into different sequences of noops which are recognized
by Valgrind, which is a cute trick.

You've found the UML config changes needed for Valgrind.  If Valgrind itself
has the changes that Jeremy and I made, then you should be all set to at
least run UML under it.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Valgrind meets UML

[Henrik Nordstrom]

On Thu, 23 Oct 2003, Jeff Dike wrote:

> You've found the UML config changes needed for Valgrind.  If Valgrind itself
> has the changes that Jeremy and I made, then you should be all set to at
> least run UML under it.

Which alone should trap some stupid mistakes with uninitialized variables,
even if the memory allocation/deallocation integration is not set yet so 
it it not totally fruitless.

It should also allow for the cachegrind mode, which some people might 
find useful.

Regards
Henrik



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Valgrind meets UML

[Jeff Dike]

hno@marasystems.com said:
> Which alone should trap some stupid mistakes with uninitialized
> variables, even if the memory allocation/deallocation integration is
> not set yet so  it it not totally fruitless.

In the small amount of testing I did (boot up tomsrtbt and halt it), it didn't
find anything real.  It found some structures that I was passing into system
calls that were incompletely initialized (because it didn't make sense to
initialize some fields or because there was a union in it and the code was
using one of the smaller arms), and a few similar things.

It's going to require more extensive of UML under valgrind to start finding
bugs.

> It should also allow for the cachegrind mode, which some people might
> find useful. 

Cachegrind would be particularly interesting, and cache behavior along a
particular code path would be interesting to people, so this wouldn't
necessarily need a real workload to be useful.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel