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 gparker@...