|
From: Naveen K. <g_n...@ya...> - 2005-02-18 22:55:13
|
Hi, Why is stage1 linked to be a static executable ? It didn't seem to be so during 2.2.0. The reason I ask is that on x86-solaris there doesnt seem to be any auxv info for static executables. I was initially making changes off 2.2.0 for x86-solaris but decided to see if I could track cvs latest. It wasnt too difficult and within a day I am at the same point that I was at for 2.2.0. The platform related partitioning changes seems to be pretty good. On another note I was wondering if anyone could suggest a way of implementing vg_(do_syscall) on x86-solaris. Currently my implementation is something like this vg_(do_syscall) popl %edx popl %eax pushl %edx lcall $0x27, $0x0 push (%esp) ret The system call number goes in %eax and the lcall does the system call. Return value is in %eax however if the condition flag is set then this signals an error and %eax contains the error number(positive value). My question is how do I convey all this to the calling function ? Do I move the error value to errno and then use vk_(is_kerror)(errno) to decide what value the calling function returns ? Thanks Naveen __________________________________ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com |
|
From: Nicholas N. <nj...@cs...> - 2005-02-19 00:25:00
|
On Fri, 18 Feb 2005, Naveen Kumar wrote: > Why is stage1 linked to be a static executable ? It > didn't seem to be so during 2.2.0. The reason I ask is > that on x86-solaris there doesnt seem to be any auxv > info for static executables. I was initially making > changes off 2.2.0 for x86-solaris but decided to see > if I could track cvs latest. It wasnt too difficult > and within a day I am at the same point that I was at > for 2.2.0. The platform related partitioning changes > seems to be pretty good. I don't know why it is a static executable, but I would say that tracking CVS is a very good idea. > On another note I was wondering if anyone could > suggest a way of implementing vg_(do_syscall) on > x86-solaris. Currently my implementation is something > like this > > vg_(do_syscall) > popl %edx > popl %eax > pushl %edx > lcall $0x27, $0x0 > push (%esp) > ret > > The system call number goes in %eax and the lcall does > the system call. Return value is in %eax however if > the condition flag is set then this signals an error > and %eax contains the error number(positive value). My > question is how do I convey all this to the calling > function ? Do I move the error value to errno and then > use vk_(is_kerror)(errno) to decide what value the > calling function returns ? I believe that on x86/Linux %eax gets the return value, and you can tell if it's an error if the value is in the range -4096 <= ret <= -1, and that the current Valgrind code assumes this when using VG_(do_syscall)(). So if that's not true for Solaris then perhaps the way VG_(do_syscall)() works needs to change a little, eg. return 2 values, one for the return value, and one a boolean that indicates whether it's an error code. But I'm not certain about that. N |
|
From: Greg P. <gp...@us...> - 2005-02-19 21:28:04
|
Nicholas Nethercote writes: > I believe that on x86/Linux %eax gets the return value, and you can tell > if it's an error if the value is in the range -4096 <= ret <= -1, and that > the current Valgrind code assumes this when using VG_(do_syscall)(). > > So if that's not true for Solaris then perhaps the way VG_(do_syscall)() > works needs to change a little, eg. return 2 values, one for the return > value, and one a boolean that indicates whether it's an error code. But > I'm not certain about that. Mac OS X definitely doesn't do it this way. The VG_(is_kerror)() model doesn't work at all. Returning two values would work. However, I've found it easier to use VG_(do_syscall) only for syscalls on Valgrind's behalf, and write a different dispatcher for client syscalls. The PowerPC's syscall instruction always returns a result in register r3. The difference between success and error is the instruction at which execution resumes after the syscall: (syscall+4) means error, and (syscall+8) means success. For native libc, the success case simply returns, and the error case branches to some code that moves the syscall result to errno and returns -1. My client syscall dispatcher takes a ThreadState argument, and reads the syscall and syscall parameters from that ThreadState. On return, the result (good or bad) is left in virtual r3, and a per-ThreadState syscall_failed is set on error. In addition, the wrapper updates the virtual PC to the correct destination. The syscall wrappers use syscall_failed and the virtual r3 directly. (Throwing a wrench into the mix is the distinction between BSD syscalls and Mach traps. The Mach traps use the same syscall instruction but return to (syscall+4) unconditionally, which looks like the BSD failure case. So there are in fact two client dispatchers, one for BSD and one for Mach, based on the syscall number. This could probably be unified if the Mach wrappers carefully ignored syscall_failed, but I haven't bothered to rearrange it that way yet.) -- Greg Parker gp...@us... |
|
From: Jeremy F. <je...@go...> - 2005-02-20 07:33:56
|
Greg Parker wrote:
>Mac OS X definitely doesn't do it this way. The VG_(is_kerror)() model
>doesn't work at all. Returning two values would work. However, I've
>found it easier to use VG_(do_syscall) only for syscalls on Valgrind's
>behalf, and write a different dispatcher for client syscalls.
>
>
That's also true on the x86-linux port. Client syscalls need to be done
very carefully to make sure signals are dealt with properly;
VG_(do_syscall) should never be used for client syscalls (well, except
indirectly for special syscalls).
>The PowerPC's syscall instruction always returns a result in register
>r3. The difference between success and error is the instruction at
>which execution resumes after the syscall: (syscall+4) means error,
>and (syscall+8) means success. For native libc, the success case
>simply returns, and the error case branches to some code that moves
>the syscall result to errno and returns -1.
>
>
Yeah, its obvious that combining normal returns and error returns is a
bit Linux-specific.
J
|
|
From: Jeremy F. <je...@go...> - 2005-02-19 00:35:17
|
Naveen Kumar wrote:
>Hi,
> Why is stage1 linked to be a static executable ? It
>didn't seem to be so during 2.2.0. The reason I ask is
>that on x86-solaris there doesnt seem to be any auxv
>info for static executables.
>
Its static to make sure it is all together in one place. If it were
dynamic, then its libraries might be placed where we want to put stage2.
Can you just make up a complete auxv? It doesn't really need to see the
kernel's one.
> I was initially making
>changes off 2.2.0 for x86-solaris but decided to see
>if I could track cvs latest. It wasnt too difficult
>and within a day I am at the same point that I was at
>for 2.2.0. The platform related partitioning changes
>seems to be pretty good.
>
>
Good.
>The system call number goes in %eax and the lcall does
>the system call. Return value is in %eax however if
>the condition flag is set then this signals an error
>and %eax contains the error number(positive value). My
>question is how do I convey all this to the calling
>function ? Do I move the error value to errno and then
>use vk_(is_kerror)(errno) to decide what value the
>calling function returns ?
>
>
BSD seems to have a similar (identical?) syscall convention. I haven't
really thought about it, but we could change do_syscall to something
like "int VG_(do_syscall)(int *ret, int syscall, ...)", and have it
return 0 if OK or 1 on error; *ret would always get the sycall return
value. Does Solaris ever return 64 bit results in eax:edx?
J
|