|
From: Greg P. <gp...@us...> - 2007-08-31 23:28:11
|
Where's the code that sets the definedness bits for syscall results? (e.g. eax on linux-x86, r3+cr0 on linux-ppc64, etc) darwin-x86 expects results in eax, edx, and eflags.c. I've missed something somewhere, because if eflags is marked undefined before the syscall then memcheck complains about the error-checking code after the syscall. I can't find the analogous code for other CPUs. (Darwin update: I'm working towards a Leopard-i386 open-source release as soon after Leopard ships as possible.) -- Greg Parker gp...@us... |
|
From: Nicholas N. <nj...@cs...> - 2007-09-01 09:11:35
|
On Sat, 31 Aug 2007, Greg Parker wrote:
> Where's the code that sets the definedness bits for syscall results?
> (e.g. eax on linux-x86, r3+cr0 on linux-ppc64, etc)
>
> darwin-x86 expects results in eax, edx, and eflags.c. I've missed
> something somewhere, because if eflags is marked undefined before
> the syscall then memcheck complains about the error-checking code
> after the syscall. I can't find the analogous code for other CPUs.
I think it's this, around line 1059 in coregrind/m_syswrap/syswrap-main.c:
/* Tell the tool that the assignment has occurred, so it can update
shadow regs as necessary. */
VG_TRACK( post_reg_write, Vg_CoreSysCall, tid, layout.o_retval,
sizeof(UWord) );
It assumes only a single return value from syscalls, so you'll need to
generalise it. You're probably used to doing that by now, though :)
> (Darwin update: I'm working towards a Leopard-i386 open-source
> release as soon after Leopard ships as possible.)
Yay! Roughly when would that be?
Nick
|
|
From: Greg P. <gp...@us...> - 2007-09-03 03:38:36
|
Nicholas Nethercote writes: > On Sat, 31 Aug 2007, Greg Parker wrote: > > Where's the code that sets the definedness bits for syscall results? > > (e.g. eax on linux-x86, r3+cr0 on linux-ppc64, etc) > > > > darwin-x86 expects results in eax, edx, and eflags.c. I've missed > > something somewhere, because if eflags is marked undefined before > > the syscall then memcheck complains about the error-checking code > > after the syscall. I can't find the analogous code for other CPUs. > > I think it's this, around line 1059 in coregrind/m_syswrap/syswrap-main.c: > > /* Tell the tool that the assignment has occurred, so it can update > shadow regs as necessary. */ > VG_TRACK( post_reg_write, Vg_CoreSysCall, tid, layout.o_retval, > sizeof(UWord) ); > > It assumes only a single return value from syscalls, so you'll need to > generalise it. You're probably used to doing that by now, though :) Yep, that's it. (In fact, I changed that line a long time ago to do double-word returns, then forgot about it.) That code doesn't handle linux-ppc[32|64], which use cr0.so, or AIX-ppc[32|64], which use r4. The way the current code can call post_reg_write and then change the result registers again (i.e. if the syscall post handler mangled them) also looks suspicious. I moved the post_reg_write call(s) into putSyscallStatusIntoGuestState() for now, where each platform explicitly writes the registers it cares about, instead of using the arg layout. > > (Darwin update: I'm working towards a Leopard-i386 open-source > > release as soon after Leopard ships as possible.) > > Yay! Roughly when would that be? "October" for the OS itself. Leopard OS open-source release will follow the OS itself, and I'd guess that the lawyers wouldn't let valgrind out before the OS open-source release. -- Greg Parker gp...@us... |