[uml-devel] UML and valgrind

[uml-devel] UML and valgrind

[Bahi, David]

back some time ago it seems like someone had more than a clue as to what
was requried to get valgrind working under UML... well as of 2.1.1 it
still ain't working.

http://marc.theaimsgroup.com/?l=user-mode-linux-devel&m=107066894230633&
w=2

I was wondering if a patch was available for our 'community' to make use
of this tool... for both running the UML as an application and for
running
applications within the UML.

It seems that for running valgrind within the UML there is a signal
handling
problem where 'restorer' is NULL and causes a panic in
setup_signal_stack_si

signal_kernel.c
  handle_signal()

	if (ka->sa.sa_flags & SA_RESTORER) restorer =
ka->sa.sa_restorer;
	else restorer = NULL;

	if(ka->sa.sa_flags & SA_SIGINFO)
		err = setup_signal_stack_si(sp, signr, (unsigned long)
handler,
					    restorer, regs, info,
&save);

thanks for any insight.

db

"The kernel is the only UNIX code that cannot be substituted by a user
to his own liking. For this reason, the kernel should make as few real
decisions as possible." -- K. Thompson


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
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: UML and valgrind

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

cc'ing valgrind users to solicit support!

as of valgrind 2.1.2 is happy as can be within a User Mode
Linux hosted session. This was tested with 2.4.24-1um and
2.4.26-2um + incrementals on a RedHat 9 (non-nptl, skas)
host - and using RH9 UML filesystems.

still trouble with launching a UML itself under valgrind
(even with MODE_SKAS, ! MODE_TT, and KERNEL_STACK_ORDER=3)

for starters we have:

[u2](dbahi)443$ ~/valgrind-2.1.2/bin/valgrind --tool=memcheck 
/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux umid=kickme 
ubd0=/local/cow/kickmoo,/local/dbahi/root_fs.rh-9-full 
ubd1=/local/cow/kickmoo2,/local/dbahi/swap_fs.256 
hostfs=/local/hostfs/kickdir/

Executable is mapped outside of range (nil)-0x52c00000
valgrind: 
do_exec(/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux) 
failed: Cannot allocate memory

How does one get around this sudden valgrind exit?

Bahi, David wrote:

> back some time ago it seems like someone had more than a clue as to what
> was requried to get valgrind working under UML... well as of 2.1.1 it
> still ain't working.
> 
> http://marc.theaimsgroup.com/?l=user-mode-linux-devel&m=107066894230633&
> w=2
> 
> I was wondering if a patch was available for our 'community' to make use
> of this tool... for both running the UML as an application and for
> running
> applications within the UML.
> 
> It seems that for running valgrind within the UML there is a signal
> handling
> problem where 'restorer' is NULL and causes a panic in
> setup_signal_stack_si
> 
> signal_kernel.c
>   handle_signal()
> 
> 	if (ka->sa.sa_flags & SA_RESTORER) restorer =
> ka->sa.sa_restorer;
> 	else restorer = NULL;
> 
> 	if(ka->sa.sa_flags & SA_SIGINFO)
> 		err = setup_signal_stack_si(sp, signr, (unsigned long)
> handler,
> 					    restorer, regs, info,
> &save);
> 
> thanks for any insight.
> 
> db
> 
> "The kernel is the only UNIX code that cannot be substituted by a user
> to his own liking. For this reason, the kernel should make as few real
> decisions as possible." -- K. Thompson

-- 
There are two kinds of people in this world: Those that enter a room and 
turn the television set on, and those that enter a room and turn the 
television set off. -- Raymond Shaw, The Manchurian Candidate (1962).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

dbahi@enterasys.com said:
> Executable is mapped outside of range (nil)-0x52c00000 valgrind:
> do_exec(/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux)
> failed: Cannot allocate memory
>
> How does one get around this sudden valgrind exit? 

If I remember right, there is a hard-coded address in valgrind.  If the process
loads above that you get that error.  Changing it and rebuilding doesn't seem
to hurt anything.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Nicholas Nethercote]

On Tue, 3 Aug 2004, Jeff Dike wrote:

> dbahi@enterasys.com said:
>> Executable is mapped outside of range (nil)-0x52c00000 valgrind:
>> do_exec(/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux)
>> failed: Cannot allocate memory
>>
>> How does one get around this sudden valgrind exit?
>
> If I remember right, there is a hard-coded address in valgrind.  If the process
> loads above that you get that error.  Changing it and rebuilding doesn't seem
> to hurt anything.

It's not quite hard-coded, but close -- that address depends on another 
address that is hard-coded, unfortunately.  Programs that have to load 
pieces at high addresses don't interact well with Valgrind, which 
partitions the address space, the low part for the client program, the 
high part for Valgrind.

What address was UML trying to load something at?  Is that adjustable?

N


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Nicholas Nethercote]

On Tue, 3 Aug 2004, Jeff Dike wrote:

>> What address was UML trying to load something at?
>
> 0xa0000000

Currently Valgrind uses 0xb0000000--0xbfffffff for itself, always.  Below 
that depends which tool you are using, if it uses "shadow memory" (ie. 
shadowing every memory value with a metavalue), and how big the shadow 
metavalues are.

For example, Memcheck uses 9 bits of shadow memory for every byte of real 
memory, so it reserves down to 0x52c00000 or so for its own use.  If you 
try Addrcheck, which only uses 1 shadow bit per real byte, it will reserve 
down to only about 0x9c000000.  If you use --tool=none, no shadow memory 
is needed so you should be able to use up to about 0xaf000000.

HTH

N


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

njn25@cam.ac.uk said:
> What address was UML trying to load something at?  

0xa0000000

> Is that adjustable?

Yup, just something I haven't got around to doing yet.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 5944 bytes --]

fantastic! patch applied. results below.

note that valgrind almost _requires_ dynamic
linking - so I'll keep mem= below 750M, right?

ugh, so close - it bails - stopped by clone() !?!!?? :

[u2](dbahi)276$  ~/valgrind-2.1.2/bin/valgrind -v --tool=memcheck 
./linux umid=kickme 
ubd0=/local/cow/kickmoo,/local/dbahi/root_fs.rh-9-full 
ubd1=/local/cow/kickmoo2,/local/dbahi/swap_fs.256 hostfs=/local/hostfs
==2951== Memcheck, a memory error detector for x86-linux.
==2951== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==2951== Using valgrind-2.1.2, a program supervision framework for 
x86-linux.
==2951== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==2951== Valgrind library directory: 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind
==2951== Command line
==2951==    ./linux
==2951==    umid=kickme
==2951==    ubd0=/local/cow/kickmoo,/local/dbahi/root_fs.rh-9-full
==2951==    ubd1=/local/cow/kickmoo2,/local/dbahi/swap_fs.256
==2951==    hostfs=/local/hostfs
==2951== Startup, with flags:
==2951==    -v
==2951==    --tool=memcheck
==2951== Contents of /proc/version:
==2951==   Linux version 2.4.20-28.9.ets.1.autofs41.skas3 
(dbahi@etrs-pc02) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) 
#1 Thu Feb 12 21:32:45 EST 2004
==2951== Reading syms from 
/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux (0x8048000)
==2951== Reading syms from /lib/ld-2.3.2.so (0x1B8E4000)
==2951==    object doesn't have any debug info
==2951== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/stage2 (0xB0000000)
==2951== Reading syms from /lib/ld-2.3.2.so (0xB1000000)
==2951==    object doesn't have any debug info
==2951== Reading syms from /lib/libdl-2.3.2.so (0xB1031000)
==2951==    object doesn't have any debug info
==2951== Reading syms from /lib/i686/libc-2.3.2.so (0xB1036000)
==2951==    object doesn't have any debug info
==2951== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgskin_memcheck.so 
(0xB126F000)
==2951== Reading suppressions file: 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/default.supp
==2951== REDIRECT soname:libc.so.6(__GI___errno_location) to 
soname:libpthread.so.0(__errno_location)
==2951== REDIRECT soname:libc.so.6(__errno_location) to 
soname:libpthread.so.0(__errno_location)
==2951== REDIRECT soname:libc.so.6(__GI___h_errno_location) to 
soname:libpthread.so.0(__h_errno_location)
==2951== REDIRECT soname:libc.so.6(__h_errno_location) to 
soname:libpthread.so.0(__h_errno_location)
==2951== REDIRECT soname:libc.so.6(__GI___res_state) to 
soname:libpthread.so.0(__res_state)
==2951== REDIRECT soname:libc.so.6(__res_state) to 
soname:libpthread.so.0(__res_state)
==2951== REDIRECT soname:libc.so.6(stpcpy) to 
*vgpreload_memcheck.so*(stpcpy)
==2951== REDIRECT soname:libc.so.6(strnlen) to 
*vgpreload_memcheck.so*(strnlen)
==2951== REDIRECT soname:ld-linux.so.2(stpcpy) to 
*vgpreload_memcheck.so*(stpcpy)
==2951== REDIRECT soname:ld-linux.so.2(strchr) to 
*vgpreload_memcheck.so*(strchr)
==2951==
==2951== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vg_inject.so (0x1B8FB000)
==2951== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgpreload_memcheck.so 
(0x1B900000)
==2951== TRANSLATE: 0x1B8F5BB0 redirected to 0x1B903498
==2951== Reading syms from /lib/libutil-2.3.2.so (0x1B907000)
==2951==    object doesn't have any debug info
==2951== Reading syms from /lib/tls/libc-2.3.2.so (0x42000000)
==2951==    object doesn't have any debug info
==2951== TRANSLATE: 0x1B8E4C00 redirected to 0x52BFF040
==2951== TRANSLATE: 0x42073700 redirected to 0x1B903C90
==2951==
==2951== Valgrind detected that your program requires
==2951== the following unimplemented functionality:
==2951==    clone(): not supported by Valgrind.
    We do now support programs linked against
    libpthread.so, though.  Re-run with -v and ensure that
    you are picking up Valgrind's implementation of libpthread.so.
==2951== This may be because the functionality is hard to implement,
==2951== or because no reasonable program would behave this way,
==2951== or because nobody has yet needed it.  In any case, let us know at
==2951== valgrind.kde.org and/or try to work around the problem, if you can.
==2951==
==2951== Valgrind has to exit now.  Sorry.  Bye!
==2951==

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==2951==    at 0x420DF139: clone (in /lib/tls/libc-2.3.2.so)
==2951==    by 0x80DA3A4: can_do_skas (process.c:239)
==2951==    by 0x80DE595: linux_main (um_arch.c:332)
==2951==    by 0x80532AF: main (main.c:148)



Jeff Dike wrote:

> njn25@cam.ac.uk said:
> 
>>What address was UML trying to load something at?  Is that adjustable?
> 
> 
> It is now.  Get the load-low patch from 
> 	http://user-mode-linux.sourceforge.net/patches.html
> 
> It will make UML load where every normal process loads when CONFIG_MODE_SKAS
> is on and CONFIG_MODE_TT is off.  This should get you past valgrind's address
> space assumptions.
> 
> As a side-benefit, this will allow UML to have much greater physical memory
> without needing to go to highmem.  If you take advantage of this, either enable 
> CONFIG_STATIC_LINK or keep the physical memory size below about 750M.  The
> reason is you don't want to push UML physical memory into the 0x40000000 area
> occupied by shared libraries.  With CONFIG_STATIC_LINK, this problem goes away
> and you can have physical memory up to about 2.75G.
> 
> Let me know if there are any problems.  It's not well tested - I ran it enough
> to see it panic because it had no root filesystem.  My current work box doesn't
> have skas on it yet, so I can't boot this one up totally.
> 
> 				Jeff
> 

-- 
There are two kinds of people in this world: Those that enter a room and 
turn the television set on, and those that enter a room and turn the 
television set off. -- Raymond Shaw, The Manchurian Candidate (1962).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

njn25@cam.ac.uk said:
> What address was UML trying to load something at?  Is that adjustable?

It is now.  Get the load-low patch from 
	http://user-mode-linux.sourceforge.net/patches.html

It will make UML load where every normal process loads when CONFIG_MODE_SKAS
is on and CONFIG_MODE_TT is off.  This should get you past valgrind's address
space assumptions.

As a side-benefit, this will allow UML to have much greater physical memory
without needing to go to highmem.  If you take advantage of this, either enable 
CONFIG_STATIC_LINK or keep the physical memory size below about 750M.  The
reason is you don't want to push UML physical memory into the 0x40000000 area
occupied by shared libraries.  With CONFIG_STATIC_LINK, this problem goes away
and you can have physical memory up to about 2.75G.

Let me know if there are any problems.  It's not well tested - I ran it enough
to see it panic because it had no root filesystem.  My current work box doesn't
have skas on it yet, so I can't boot this one up totally.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

dbahi@enterasys.com said:
> ugh, so close - it bails - stopped by clone() !?!!?? : 

OK, there were a bunch of problems that were fixed when me, Jeremy, and Julian
were working on this.  The clone one seems to have not made it.  I've lost the
patches I had, but I dug this out of a piece of email.  It applies to 
coregrind/vg_syscalls.c:

> @@ -39,6 +40,10 @@
>  # code which copies from baseBlock before the call, into
>  # m_state_static, and back afterwards.
>  
> +.section .data
> +save_ip:
> +        .long   0
> +
>  VG_(do_syscall):
>         # Save all the int registers of the real machines state on the
>         # simulators stack.
> @@ -80,10 +85,27 @@
>         movl    VG_(m_state_static)+48, %esi
>         movl    VG_(m_state_static)+52, %edi
>  
> +       cmpl    $__NR_clone, %eax
> +       jne     not_clone
> +
> +       pushl   %eax
> +       movl    VG_(m_state_static)+60, %eax
> +       movl    %eax, save_ip
> +       popl    %eax
> +
> +       int     $0x80
> +
> +       cmpl    $0, %eax
> +       jne     parent_finish
> +
> +       jmp     *save_ip
> +
> +not_clone:
>         # esp now refers to the simulatees stack
>         # Do the actual system call
>         int     $0x80

It handles the clone by calling clone itself, creating a new valgrind thread
which will go on grinding the new UML thread.

Also, I saw this:

> 	valgrind: the `impossible' happened:
> 	   Unhandled REPE case

If you see this, check that you have
	http://www.goop.org/~jeremy/valgrind/76-repe-scas.patch
and apply if not.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

If you get past the clone and repe problems in valgrind, there was another
where V was confused by UML's stack switching.  I didn't see a patch for that
in my email, but someone special-cased longjmp in the stack overflow detection
to get around that.

IIRC, that got UML booting.  Now, it produced almost no useful information 
because V doesn't understand the kernel memory allocators.  So, below are
my attempts to make it do so.  These apply to UML, and describe the kernel
to V.

I don't guarantee that they are correct, but they should at least give you
an idea what needs to happen.

				Jeff

V doesn't see that PTRACE_FAULTINFO initializes the fault struct given to it:

diff -Naur um/arch/um/kernel/skas/process.c v/arch/um/kernel/skas/process.c
--- um/arch/um/kernel/skas/process.c	Tue Jan 14 21:09:16 2003
+++ v/arch/um/kernel/skas/process.c	Mon Dec 23 11:42:39 2002
@@ -25,6 +25,8 @@
 #include "proc_mm.h"
 #include "skas_ptrace.h"
 
+#include "memcheck.h"
+
 unsigned long exec_regs[FRAME_SIZE];
 unsigned long exec_fp_regs[HOST_FP_SIZE];
 unsigned long exec_fpx_regs[HOST_XFP_SIZE];
@@ -40,6 +42,7 @@
 		panic("handle_segv - PTRACE_FAULTINFO failed, errno = %d\n",
 		      errno);
 
+	VALGRIND_MAKE_READABLE(&fault, sizeof(fault));
 	segv(fault.addr, 0, FAULT_WRITE(fault.is_write), 1, NULL);
 }
 
This makes buffers writeable according to V when they are handed out by
the slab allocator, and no-access when they are freed:

diff -Naur um/mm/slab.c v/mm/slab.c
--- um/mm/slab.c	Fri Dec 20 18:42:53 2002
+++ v/mm/slab.c	Mon Dec 23 11:15:31 2002
@@ -76,6 +76,8 @@
 #include	<linux/seq_file.h>
 #include	<asm/uaccess.h>
 
+#include "memcheck.h"
+
 /*
  * DEBUG	- 1 for kmem_cache_create() to honour; SLAB_DEBUG_INITIAL,
  *		  SLAB_RED_ZONE & SLAB_POISON.
@@ -500,6 +502,11 @@
 	 * it is a named-page or buffer-page.  The members it tests are
 	 * of no interest here.....
 	 */
+
+	if(addr != NULL)
+	        VALGRIND_MAKE_WRITABLE(addr, 
+				       (1 << cachep->gfporder) * PAGE_SIZE);
+
 	return addr;
 }
 
@@ -1076,8 +1083,11 @@
 		 * the same cache which they are a constructor for.
 		 * Otherwise, deadlock. They must also be threaded.
 		 */
-		if (cachep->ctor)
+		if (cachep->ctor){
+		        VALGRIND_MAKE_WRITABLE(objp, cachep->objsize);
 			cachep->ctor(objp, cachep, ctor_flags);
+		        VALGRIND_MAKE_NOACCESS(objp, cachep->objsize);
+		}
 #if DEBUG
 		if (cachep->flags & SLAB_RED_ZONE)
 			objp -= BYTES_PER_WORD;
@@ -1528,7 +1538,11 @@
  */
 void * kmem_cache_alloc (kmem_cache_t *cachep, int flags)
 {
-	return __kmem_cache_alloc(cachep, flags);
+        void *ptr = __kmem_cache_alloc(cachep, flags);
+
+	if(ptr != NULL)
+	        VALGRIND_MAKE_READABLE(ptr, cachep->objsize);
+	return ptr;
 }
 
 /**
@@ -1557,10 +1571,16 @@
 	cache_sizes_t *csizep = cache_sizes;
 
 	for (; csizep->cs_size; csizep++) {
+   	        void *ptr;
 		if (size > csizep->cs_size)
 			continue;
-		return __kmem_cache_alloc(flags & GFP_DMA ?
-			 csizep->cs_dmacachep : csizep->cs_cachep, flags);
+		ptr = __kmem_cache_alloc(flags & GFP_DMA ?
+					 csizep->cs_dmacachep : 
+					 csizep->cs_cachep, flags);
+		if(ptr != NULL)
+		        VALGRIND_MAKE_WRITABLE(ptr, size);
+
+		return ptr;
 	}
 	return NULL;
 }

Ditto for vmalloc/vfree:

diff -Naur um/mm/vmalloc.c v/mm/vmalloc.c
--- um/mm/vmalloc.c	Mon Feb 25 12:50:45 2002
+++ v/mm/vmalloc.c	Mon Dec 23 11:30:26 2002
@@ -16,6 +16,8 @@
 #include <asm/uaccess.h>
 #include <asm/pgalloc.h>
 
+#include "memcheck.h"
+
 rwlock_t vmlist_lock = RW_LOCK_UNLOCKED;
 struct vm_struct * vmlist;
 
@@ -212,11 +214,14 @@
 		printk(KERN_ERR "Trying to vfree() bad address (%p)\n", addr);
 		return;
 	}
+
 	write_lock(&vmlist_lock);
 	for (p = &vmlist ; (tmp = *p) ; p = &tmp->next) {
 		if (tmp->addr == addr) {
 			*p = tmp->next;
 			vmfree_area_pages(VMALLOC_VMADDR(tmp->addr), tmp->size);
+			VALGRIND_MAKE_NOACCESS(VMALLOC_VMADDR(tmp->addr), 
+					      tmp->size);
 			write_unlock(&vmlist_lock);
 			kfree(tmp);
 			return;
@@ -244,6 +249,8 @@
 		vfree(addr);
 		return NULL;
 	}
+
+	VALGRIND_MAKE_WRITABLE(addr, size);
 	return addr;
 }
 



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]

trying to find a way to wedge the old patch into
the new code... i don't think it applies anymore.

alright, i don't read assembly (head hung low) but
valgrind 2.1.2/coregrind/vg_syscall.S has something
that makes me ask why i'm getting the 'clone() not
supported message'

does this need some kind of tie-in code in vg_syscalls.c?

.globl VG_(clone)
VG_(clone):
#define FSZ	(4+4+4)			/* frame size = retaddr+ebx+edi */
	push	%ebx
	push	%edi
	/* set up child stack with function and arg */
	movl	 4+FSZ(%esp), %ecx	/* child stack */
	movl	12+FSZ(%esp), %ebx	/* fn arg */
	movl	 0+FSZ(%esp), %eax	/* fn */
	lea	-8(%ecx), %ecx		/* make space on stack */
	movl	%ebx, 4(%ecx)		/*   fn arg */
	movl	%eax, 0(%ecx)		/*   fn */

	/* get other args to clone */
	movl	 8+FSZ(%esp), %ebx	/* flags */
	movl	20+FSZ(%esp), %edx	/* parent tid * */
	movl	16+FSZ(%esp), %edi	/* child tid * */
	movl	$__NR_clone, %eax
	int	$0x80
	testl	%eax, %eax
	jnz	1f

	/* CHILD - call thread function */
	popl	%eax
	call	*%eax

	/* exit with result */
	movl	%eax, %ebx
	movl	$__NR_exit, %eax
	int	$0x80

	/* Hm, exit returned */
	ud2
		
1:	/* PARENT or ERROR */
	pop	%edi
	pop	%ebx
	ret


Jeff Dike wrote:

> dbahi@enterasys.com said:
> 
>>ugh, so close - it bails - stopped by clone() !?!!?? : 
> 
> 
> OK, there were a bunch of problems that were fixed when me, Jeremy, and Julian
> were working on this.  The clone one seems to have not made it.  I've lost the
> patches I had, but I dug this out of a piece of email.  It applies to 
> coregrind/vg_syscalls.c:
> 
> 
>>@@ -39,6 +40,10 @@
>> # code which copies from baseBlock before the call, into
>> # m_state_static, and back afterwards.
>> 
>>+.section .data
>>+save_ip:
>>+        .long   0
>>+
>> VG_(do_syscall):
>>        # Save all the int registers of the real machines state on the
>>        # simulators stack.
>>@@ -80,10 +85,27 @@
>>        movl    VG_(m_state_static)+48, %esi
>>        movl    VG_(m_state_static)+52, %edi
>> 
>>+       cmpl    $__NR_clone, %eax
>>+       jne     not_clone
>>+
>>+       pushl   %eax
>>+       movl    VG_(m_state_static)+60, %eax
>>+       movl    %eax, save_ip
>>+       popl    %eax
>>+
>>+       int     $0x80
>>+
>>+       cmpl    $0, %eax
>>+       jne     parent_finish
>>+
>>+       jmp     *save_ip
>>+
>>+not_clone:
>>        # esp now refers to the simulatees stack
>>        # Do the actual system call
>>        int     $0x80
> 
> 
> It handles the clone by calling clone itself, creating a new valgrind thread
> which will go on grinding the new UML thread.
> 
> Also, I saw this:
> 
> 
>>	valgrind: the `impossible' happened:
>>	   Unhandled REPE case
> 
> 
> If you see this, check that you have
> 	http://www.goop.org/~jeremy/valgrind/76-repe-scas.patch
> and apply if not.
> 
> 				Jeff
> 

-- 
There are two kinds of people in this world: Those that enter a room and 
turn the television set on, and those that enter a room and turn the 
television set off. -- Raymond Shaw, The Manchurian Candidate (1962).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Nicholas Nethercote]

On Tue, 3 Aug 2004, Jeff Dike wrote:

>> +       pushl   %eax
>> +       movl    VG_(m_state_static)+60, %eax
>> +       movl    %eax, save_ip
>> +       popl    %eax

m_state_static doesn't exist anymore.  You could try getting the simulated 
%eip out of the 'baseBlock' -- it starts at VG_(baseBlock), and %eip is 
VGOFF_(m_eip) *words* into it, ie. 4*VGOFF_(m_eax) bytes into it.  I'm not 
certain that the simulated %eip is up-to-date exactly as necessary, but it 
could be.  The rest of the patch would work the same way.

> Also, I saw this:
>
>> 	valgrind: the `impossible' happened:
>> 	   Unhandled REPE case
>
> If you see this, check that you have
> 	http://www.goop.org/~jeremy/valgrind/76-repe-scas.patch
> and apply if not.

That should be fixed in all recent versions of Valgrind.

HTH

N


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Nuno Silva]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

D. Bahi wrote:
| fantastic! patch applied. results below.
|
| note that valgrind almost _requires_ dynamic
| linking - so I'll keep mem= below 750M, right?
|
| ugh, so close - it bails - stopped by clone() !?!!?? :

[..]

|
| ==2951== Reading syms from /lib/tls/libc-2.3.2.so (0x42000000)
| ==2951==    object doesn't have any debug info
| ==2951== TRANSLATE: 0x1B8E4C00 redirected to 0x52BFF040
| ==2951== TRANSLATE: 0x42073700 redirected to 0x1B903C90
| ==2951==
| ==2951== Valgrind detected that your program requires
| ==2951== the following unimplemented functionality:
| ==2951==    clone(): not supported by Valgrind.

[..]

You have a NPTL/TLS system. Maybe that's the problem. You could try to:

# mv /lib/tls /lib/tls.off

...and rerun that. Maybe it works better. :-)
Remember to move tls.off again to revert to tls-enabled glibc ;)

HTH,
Nuno Silva
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBEDc9OPig54MP17wRAvMQAKCfBLEKk4jMnDrZtFvfLMYQ9tJvHACfVKlF
fNIUgR/H6gDkE0/VsvUmQNc=
=HEXR
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 6070 bytes --]

thanks for the idea, but, nope. i'm sorry to report same results.

to clarify, the toolchain supports NTPL but the kernel is not built
with this feature as the UML 2.4 series didn't have an skas patch
that supported this...

oh well. here's the log so you can see the invocation/results:

[u2](dbahi)307$ ~/valgrind-2.1.2/bin/valgrind -v --tool=memcheck 
/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux umid=kickme 
ubd0=/local/cow/kickmoo,/local/dbahi/root_fs.rh-9-full 
ubd1=/local/cow/kickmoo2,/local/dbahi/swap_fs.256  hostfs=/local/hostfs&
[2] 18281
[u2](dbahi)308$ ==18281== Memcheck, a memory error detector for x86-linux.
==18281== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==18281== Using valgrind-2.1.2, a program supervision framework for 
x86-linux.
==18281== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==18281== Valgrind library directory: 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind
==18281== Command line
==18281==    /local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux
==18281==    umid=kickme
==18281== 
ubd0=/local/target0/s1/cow/kickmoo,/local/dbahi/root_fs.rh-9-full
==18281==    ubd1=/local/target0/s1/cow/kickmoo2,/local/dbahi/swap_fs.256
==18281==    hostfs=/local/target0/s1/hostfs/chassis[box].cm[cm1]/
==18281== Startup, with flags:
==18281==    -v
==18281==    --tool=memcheck
==18281== Contents of /proc/version:
==18281==   Linux version 2.4.20-28.9.ets.1.autofs41.skas3 
(dbahi@etrs-pc02) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) 
#1 Thu Feb 12 21:32:45 EST 2004
==18281== Reading syms from 
/local/dbahi/kernels/linux-2.4.26_uml-patch-2.4.26-2um/linux (0x8048000)
==18281== Reading syms from /lib/ld-2.3.2.so (0x1B8E4000)
==18281==    object doesn't have any debug info
==18281== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/stage2 (0xB0000000)
==18281== Reading syms from /lib/ld-2.3.2.so (0xB1000000)
==18281==    object doesn't have any debug info
==18281== Reading syms from /lib/libdl-2.3.2.so (0xB1031000)
==18281==    object doesn't have any debug info
==18281== Reading syms from /lib/i686/libc-2.3.2.so (0xB1036000)
==18281==    object doesn't have any debug info
==18281== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgskin_memcheck.so 
(0xB126F000)
==18281== Reading suppressions file: 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/default.supp
==18281== REDIRECT soname:libc.so.6(__GI___errno_location) to 
soname:libpthread.so.0(__errno_location)
==18281== REDIRECT soname:libc.so.6(__errno_location) to 
soname:libpthread.so.0(__errno_location)
==18281== REDIRECT soname:libc.so.6(__GI___h_errno_location) to 
soname:libpthread.so.0(__h_errno_location)
==18281== REDIRECT soname:libc.so.6(__h_errno_location) to 
soname:libpthread.so.0(__h_errno_location)
==18281== REDIRECT soname:libc.so.6(__GI___res_state) to 
soname:libpthread.so.0(__res_state)
==18281== REDIRECT soname:libc.so.6(__res_state) to 
soname:libpthread.so.0(__res_state)
==18281== REDIRECT soname:libc.so.6(stpcpy) to 
*vgpreload_memcheck.so*(stpcpy)
==18281== REDIRECT soname:libc.so.6(strnlen) to 
*vgpreload_memcheck.so*(strnlen)
==18281== REDIRECT soname:ld-linux.so.2(stpcpy) to 
*vgpreload_memcheck.so*(stpcpy)
==18281== REDIRECT soname:ld-linux.so.2(strchr) to 
*vgpreload_memcheck.so*(strchr)
==18281==
==18281== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vg_inject.so (0x1B8FB000)
==18281== Reading syms from 
/home/rtrsvcs/dbahi/valgrind-2.1.2/lib/valgrind/vgpreload_memcheck.so 
(0x1B900000)
==18281== TRANSLATE: 0x1B8F5BB0 redirected to 0x1B903498
==18281== Reading syms from /lib/libutil-2.3.2.so (0x1B907000)
==18281==    object doesn't have any debug info
==18281== Reading syms from /lib/libc-2.3.2.so (0x1B90B000)
==18281==    object doesn't have any debug info
==18281== TRANSLATE: 0x1B97E1C0 redirected to 0x1B903C90
==18281==
==18281== Valgrind detected that your program requires
==18281== the following unimplemented functionality:
==18281==    clone(): not supported by Valgrind.
    We do now support programs linked against
    libpthread.so, though.  Re-run with -v and ensure that
    you are picking up Valgrind's implementation of libpthread.so.
==18281== This may be because the functionality is hard to implement,
==18281== or because no reasonable program would behave this way,
==18281== or because nobody has yet needed it.  In any case, let us know at
==18281== valgrind.kde.org and/or try to work around the problem, if you 
can.
==18281==
==18281== Valgrind has to exit now.  Sorry.  Bye!
==18281==

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==18281==    at 0x1B9EE4C9: clone (in /lib/libc-2.3.2.so)
==18281==    by 0x80DA3A4: can_do_skas (process.c:239)
==18281==    by 0x80DE595: linux_main (um_arch.c:332)
==18281==    by 0x80532AF: main (main.c:148)


Nuno Silva wrote:
> Hi!
> 
> D. Bahi wrote:
> | fantastic! patch applied. results below.
> |
> | note that valgrind almost _requires_ dynamic
> | linking - so I'll keep mem= below 750M, right?
> |
> | ugh, so close - it bails - stopped by clone() !?!!?? :
> 
> [..]
> 
> |
> | ==2951== Reading syms from /lib/tls/libc-2.3.2.so (0x42000000)
> | ==2951==    object doesn't have any debug info
> | ==2951== TRANSLATE: 0x1B8E4C00 redirected to 0x52BFF040
> | ==2951== TRANSLATE: 0x42073700 redirected to 0x1B903C90
> | ==2951==
> | ==2951== Valgrind detected that your program requires
> | ==2951== the following unimplemented functionality:
> | ==2951==    clone(): not supported by Valgrind.
> 
> [..]
> 
> You have a NPTL/TLS system. Maybe that's the problem. You could try to:
> 
> # mv /lib/tls /lib/tls.off
> 
> ...and rerun that. Maybe it works better. :-)
> Remember to move tls.off again to revert to tls-enabled glibc ;)
> 
> HTH,
> Nuno Silva

-- 
There are two kinds of people in this world: Those that enter a room and
turn the television set on, and those that enter a room and turn the
television set off. -- Raymond Shaw, The Manchurian Candidate (1962).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Tom Hughes]

In message <410FF1C3.9060509@enterasys.com>
        D. Bahi <dbahi@enterasys.com> wrote:

> alright, i don't read assembly (head hung low) but
> valgrind 2.1.2/coregrind/vg_syscall.S has something
> that makes me ask why i'm getting the 'clone() not
> supported message'

You're not getting as far as any code in vg_syscall.S though. Don't
get confused by VG_(clone) as that has nothing to do with implementing
clone in the client program - it's used by valgrind to start the
background threads that it uses for handling blocking system calls.

> does this need some kind of tie-in code in vg_syscalls.c?

Not exactly. The message you are getting comes from vg_syscalls.c
but the point is that clone is not like other system calls where
you can trivially implement it - it would require a substantial
amount of work throughout valgrind.

Tom

-- 
Tom Hughes (thh@cyberscience.com)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Tom Hughes]

In message <200408031931.i73JVkvv003367@ccure.user-mode-linux.org>
        Jeff Dike <jdike@addtoit.com> wrote:

> dbahi@enterasys.com said:
>> ugh, so close - it bails - stopped by clone() !?!!?? : 
>
> OK, there were a bunch of problems that were fixed when me, Jeremy,
> and Julian were working on this.  The clone one seems to have not
> made it.  I've lost the patches I had, but I dug this out of a piece
> of email.  It applies to coregrind/vg_syscalls.c:

Clone is not (at least in general) supportable in valgrind without
a reasonably large amount of work.

>> @@ -39,6 +40,10 @@
>>  # code which copies from baseBlock before the call, into
>>  # m_state_static, and back afterwards.
>>  
>> +.section .data
>> +save_ip:
>> +        .long   0
>> +
>>  VG_(do_syscall):
>>         # Save all the int registers of the real machines state on the
>>         # simulators stack.
>> @@ -80,10 +85,27 @@
>>         movl    VG_(m_state_static)+48, %esi
>>         movl    VG_(m_state_static)+52, %edi
>>  
>> +       cmpl    $__NR_clone, %eax
>> +       jne     not_clone
>> +
>> +       pushl   %eax
>> +       movl    VG_(m_state_static)+60, %eax
>> +       movl    %eax, save_ip
>> +       popl    %eax
>> +
>> +       int     $0x80
>> +
>> +       cmpl    $0, %eax
>> +       jne     parent_finish
>> +
>> +       jmp     *save_ip
>> +
>> +not_clone:
>>         # esp now refers to the simulatees stack
>>         # Do the actual system call
>>         int     $0x80

I don't see how a patch that small can have made clone work for you in
any version - at the very least you would need a change to vg_syscall.c
to stop it trapping the clone and complaining about it or you would
never actually reach VG_(do_syscall).

> It handles the clone by calling clone itself, creating a new
> valgrind thread which will go on grinding the new UML thread.

But how did you cope with the fact that valgrind doesn't protect it's
internal data structures in any way? You would have all sorts of
problems with two threads trying to access the same data.

Or are you not specifying CLONE_VM among the flags? it is it more like
a fork than a thread creation? That valgrind may be able to handle
quite easily.

In fact, what is the exact set of flags you're using to clone?

Tom

-- 
Tom Hughes (thh@cyberscience.com)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Tom Hughes]

In message <20040804153541.GA7237@ccure.user-mode-linux.org>
        Jeff Dike <jdike@addtoit.com> wrote:

>> But how did you cope with the fact that valgrind doesn't protect it's
>> internal data structures in any way? You would have all sorts of
>> problems with two threads trying to access the same data.
>
> I think I was mistaken about this firing off another valgrind thread, for
> two reasons.  
>
> I remember being concerned about whether the process data was still
> present in its normal, not running under valgrind, form.  This would
> only be a problem if you were planning on running a non-valgrind
> thread in the same address space.

Even doing that (if it's still possible) is quite dangerous as
that thread could accidentally damage valgrind's environment.

> Second, the patch above looks like it extracts the client IP from
> valigrind's state and branches to it.  This would make the new
> thread a non-valgrind one.

That would imply that the newly created thread was left to run on
the real CPU rather than the simulated CPU. If that's the case then
I'm not that it is possible anymore - I know we had to take out the
stuff that allowed valgrind to switch back to the real CPU after
running a specified number of basic blocks because it could no longer
be made to work.

Tom

-- 
Tom Hughes (thh@cyberscience.com)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

On Wed, Aug 04, 2004 at 08:52:19AM +0100, Tom Hughes wrote:
> I don't see how a patch that small can have made clone work for you in
> any version - at the very least you would need a change to vg_syscall.c
> to stop it trapping the clone and complaining about it or you would
> never actually reach VG_(do_syscall).

There may have been more - this was the only bit that I spotted in my old
email.  In any case, that patch was the guts of the clone support.

> But how did you cope with the fact that valgrind doesn't protect it's
> internal data structures in any way? You would have all sorts of
> problems with two threads trying to access the same data.

Despite its use of clone, UML is essentially single-threaded.  The child
thread goes and does something, and the parent waits for it.  There is a 
window between the clone and wait where both could be executing at the
same time, and trashing valgrind data, but I never saw that happen.

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

On Wed, Aug 04, 2004 at 08:52:19AM +0100, Tom Hughes wrote:
> >> @@ -39,6 +40,10 @@
> >>  # code which copies from baseBlock before the call, into
> >>  # m_state_static, and back afterwards.
> >>  
> >> +.section .data
> >> +save_ip:
> >> +        .long   0
> >> +
> >>  VG_(do_syscall):
> >>         # Save all the int registers of the real machines state on the
> >>         # simulators stack.
> >> @@ -80,10 +85,27 @@
> >>         movl    VG_(m_state_static)+48, %esi
> >>         movl    VG_(m_state_static)+52, %edi
> >>  
> >> +       cmpl    $__NR_clone, %eax
> >> +       jne     not_clone
> >> +
> >> +       pushl   %eax
> >> +       movl    VG_(m_state_static)+60, %eax
> >> +       movl    %eax, save_ip
> >> +       popl    %eax
> >> +
> >> +       int     $0x80
> >> +
> >> +       cmpl    $0, %eax
> >> +       jne     parent_finish
> >> +
> >> +       jmp     *save_ip
> >> +
> >> +not_clone:
> >>         # esp now refers to the simulatees stack
> >>         # Do the actual system call
> >>         int     $0x80
> 

> But how did you cope with the fact that valgrind doesn't protect it's
> internal data structures in any way? You would have all sorts of
> problems with two threads trying to access the same data.

I think I was mistaken about this firing off another valgrind thread, for
two reasons.  

I remember being concerned about whether the process data was still present
in its normal, not running under valgrind, form.  This would only be a problem
if you were planning on running a non-valgrind thread in the same address
space.

Second, the patch above looks like it extracts the client IP from valigrind's
state and branches to it.  This would make the new thread a non-valgrind one.

So, this being the case, there are no concerns about multi-threading V, just
UML, which isn't your problem.

				Jeff


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Tom Hughes]

In message <200408041800.i74I0Nvv007667@ccure.user-mode-linux.org>
          Jeff Dike <jdike@addtoit.com> wrote:

> thh@cyberscience.com said:
> > Even doing that (if it's still possible) is quite dangerous as that
> > thread could accidentally damage valgrind's environment.
> 
> So?  It's also quite dangerous as that thread could damage another thread's
> environment.  That's the nature of multithreaded apps.

The problem is that the virtual environment seen by a program running
under valgrind may not be the same as the real environment - things like
signal handlers, signal masks, resource limits and son. That might be
confusing for the thread that isn't running under valgrind and might
even lead to that thread damaging the process state. I'm not saying
it will happen, just that it's something to beware of.

> > That would imply that the newly created thread was left to run on the
> > real CPU rather than the simulated CPU. If that's the case then I'm
> > not that it is possible anymore - I know we had to take out the stuff
> > that allowed valgrind to switch back to the real CPU after running a
> > specified number of basic blocks because it could no longer be made to
> > work.
> 
> We're not talking about a thread switching back and forth between the real
> CPU and the simulated one.  We're talking about a thread being created on
> the real CPU and staying there.

It's still switch from the simulated CPU to the real CPU though - the
thread of control arrives at the clone and then branches with one
branch continuing on the real CPU and one on the simulated CPU. That
sounds to me just the same (for the new thread) as the existing thread
of control continuing on the real CPU.

You probably really need Jeremy's thoughts on the matter - he's more
up on this stuff and I think he was involved in dropping the support
for switching back to the real CPU.

Tom

-- 
Tom Hughes (thh@cyberscience.com)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

thh@cyberscience.com said:
> Even doing that (if it's still possible) is quite dangerous as that
> thread could accidentally damage valgrind's environment. 

So?  It's also quite dangerous as that thread could damage another thread's
environment.  That's the nature of multithreaded apps.

> That would imply that the newly created thread was left to run on the
> real CPU rather than the simulated CPU. If that's the case then I'm
> not that it is possible anymore - I know we had to take out the stuff
> that allowed valgrind to switch back to the real CPU after running a
> specified number of basic blocks because it could no longer be made to
> work. 

We're not talking about a thread switching back and forth between the real
CPU and the simulated one.  We're talking about a thread being created on
the real CPU and staying there.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

thh@cyberscience.com said:
> The problem is that the virtual environment seen by a program running
> under valgrind may not be the same as the real environment - things
> like signal handlers, signal masks, resource limits and son. That
> might be confusing for the thread that isn't running under valgrind
> and might even lead to that thread damaging the process state. I'm not
> saying it will happen, just that it's something to beware of. 

Yeah, that's why I was concerned about the process data existing in its
native state.  As for the rest, in the absense of CLONE_SIGHAND, it is all
private to the thread, so it and valgrind won't trip over each other, assuming
that the child is sufficiently careful not to inherit stuff that it doesn't 
expect.

> It's still switch from the simulated CPU to the real CPU though - the
> thread of control arrives at the clone and then branches with one
> branch continuing on the real CPU and one on the simulated CPU. That
> sounds to me just the same (for the new thread) as the existing thread
> of control continuing on the real CPU.

It feels to me more like the valgrind thread runs a system call with no
perceptible effect, and there's this new thread all of a sudden which runs
happily in this address space because it can't tell that valgrind is there.

> You probably really need Jeremy's thoughts on the matter - he's more
> up on this stuff and I think he was involved in dropping the support
> for switching back to the real CPU. 

Yeah, he was responsible for that fragment I posted as well.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Nicholas Nethercote]

On Wed, 4 Aug 2004, Jeff Dike wrote:

> It feels to me more like the valgrind thread runs a system call with no
> perceptible effect, and there's this new thread all of a sudden which runs
> happily in this address space because it can't tell that valgrind is there.

To summarise:  you seem to be confident there won't be any problems, and 
Tom's not so sure.  I'm not sure either, but the threads/signals/syscalls 
stuff is the part of Valgrind I understand the least.  I would say, just 
don't be shocked if you do this and weird things start happening :)

N


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

ok, great.

now where do i put this snippet - because it doesn't
belong in the file mentioned in the earliest post...
(or if it does - i don't see how). is there someone
willing to 'modernize' this patch for the clueless
user (me ;)

thanks very much.

Nicholas Nethercote wrote:

> On Wed, 4 Aug 2004, Jeff Dike wrote:
> 
>> It feels to me more like the valgrind thread runs a system call with no
>> perceptible effect, and there's this new thread all of a sudden which 
>> runs
>> happily in this address space because it can't tell that valgrind is 
>> there.
> 
> 
> To summarise:  you seem to be confident there won't be any problems, and 
> Tom's not so sure.  I'm not sure either, but the 
> threads/signals/syscalls stuff is the part of Valgrind I understand the 
> least.  I would say, just don't be shocked if you do this and weird 
> things start happening :)
> 
> N


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [Valgrind-users] Re: [uml-devel] Re: UML and valgrind

[Jeff Dike]

njn25@cam.ac.uk said:
> To summarise:  you seem to be confident there won't be any problems,
> and  Tom's not so sure.  I'm not sure either, but the threads/signals/
> syscalls  stuff is the part of Valgrind I understand the least.  I
> would say, just  don't be shocked if you do this and weird things
> start happening :) 

Fair enough.  I'd just point out that this worked fine a couple of years ago,
so there's some basis for my confidence.  OTOH, that patch was never merged,
so possibly that basis has disappeared.

But I'd say that this is worth looking into, since valgrinding the kernel 
would be an immensely useful thing to be able to do.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel