|
From: tin.cans.and.string on 20 Apr 2008 00:38 On Apr 19, 4:53 pm, tin.cans.and.str...(a)gmail.com wrote: > Actually, disregard, please - found the generic include file on your > website. This is good stuff. Thank you! Chuck: You've been extremely helpful, and I appreciate it. I *thought* I understood what p0, p1, and p2 were, but it's becoming increasingly apparent with every failure that I don't yet get it. It looks very much to me like these are the placeholders for the parameters which would be passed in C to 'socket()' while creating the fd, as in 'socketfd = socket(PF_INET, SOCK_STREAM, 0);', so I assumed we were dealing with a stack frame, at first, but that didn't do the job. Seeing as they're not explicitly pointed to by any register at the time of the syscall, I couldn't see that there was much use specifically defining them as data. If you're of the inclination to elaborate on the nature of p0-p2, I'd be very grateful. Thanks for all your help.
From: Chuck Crayne on 20 Apr 2008 01:38 On Sat, 19 Apr 2008 21:38:40 -0700 (PDT) tin.cans.and.string(a)gmail.com wrote: > Seeing as they're not explicitly pointed to by any register at > the time of the syscall, I couldn't see that there was much use > specifically defining them as data. They are components of the sparms field, which is pointed to by the ecx register. The association is done with a technique in Fasm which may have to be changed a bit if you are using some other assembler. Specifically, Fasm allows the following declaration, virtual at sparms p0 dd ? p1 dd ? p2 dd ? p3 dd ? p4 dd ? p5 dd ? end virtual which is similar to a union or common declaration. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Frank Kotler on 20 Apr 2008 03:52 Chuck Crayne wrote: > On Sat, 19 Apr 2008 21:38:40 -0700 (PDT) > tin.cans.and.string(a)gmail.com wrote: > >> Seeing as they're not explicitly pointed to by any register at >> the time of the syscall, I couldn't see that there was much use >> specifically defining them as data. > > They are components of the sparms field, which is pointed to by the ecx > register. The association is done with a technique in Fasm which may > have to be changed a bit if you are using some other assembler. > > Specifically, Fasm allows the following declaration, > > virtual at sparms > p0 dd ? > p1 dd ? > p2 dd ? > p3 dd ? > p4 dd ? > p5 dd ? > end virtual > > which is similar to a union or common declaration. I can see how "tin cans and string" could be confused by this, if he wasn't familiar with the idiom. The whole "socketcall" setup is confusing. C examples use "wrappers" that make "socket", "connect", "bind", "listen", etc. look like separate calls, and the asmutils macros will let you do the same thing. But at the "sys_call" level, there's really only one - "mov eax, 102" - ebx takes the "command", or "subfunction", "SYS_SOCKET", "SYS_BIND", "SYS_CONNECT", etc. and ecx takes a pointer to a "parameter structure". The meanings of the parameters differs depending on which "subfunction" we're doing, but (for some reason) we recycle the same "structure". A naive way might be to do: parameters_for_socket_socket: dd PF_INET dd SOCK_STREAM dd 0 ; ? parameters_for_socket_bind: fd dd 0 ; has to be filled in at runtime! dd sin ; address of socket address structure dd sin_length ; length of same parameters_for_..... but this would get old pretty quick. So I guess it makes sense to recycle this structure - "socket programming" seems always to do it that way - but it can make it hard to see what's going on. This example shows memory for the parameter structure allocated in static memory... "sparms rd 6"... that's in ".bss" I guess? Could go on the stack, as "tin cans and string" suspected... push ebp mov ebp, esp sub esp, 12 ; do we need more than three, ever? %define sparm ebp - 12 %define p0 sparm + 0 %define p1 sparm + 4 %define p2 sparm + 8 ; then go on to: mov [p0],PF_INET mov [p1],SOCK_STREAM etc... (that would be Nasm syntax... just "define" for Fasm??? What assembler are you using, TC&S?) Best, Frank
From: tin.cans.and.string on 20 Apr 2008 09:45 On Apr 19, 11:38 pm, Chuck Crayne <ccra...(a)crayne.org> wrote: > They are components of the sparms field, which is pointed to by the ecx > register. The association is done with a technique in Fasm which may > have to be changed a bit if you are using some other assembler. Ah. I'm using NASM. > Specifically, Fasm allows the following declaration, > > virtual at sparms > p0 dd ? > p1 dd ? > p2 dd ? > p3 dd ? > p4 dd ? > p5 dd ? > end virtual > > which is similar to a union or common declaration. This is fantastic information, Chuck. Thanks again.
From: tin.cans.and.string on 20 Apr 2008 09:52 On Apr 20, 1:52 am, Frank Kotler <fbkot...(a)verizon.net> wrote: > But at the "sys_call" level, there's really only one - "mov eax, 102" > - ebx takes the "command", or "subfunction", "SYS_SOCKET", > "SYS_BIND", "SYS_CONNECT", etc. and ecx takes a pointer to > a "parameter structure". The meanings of the parameters differs > depending on which "subfunction" we're doing, but (for some reason) > we recycle the same "structure". Righto - and there's a dearth of information available on the web concerning how to make use of the socketcall function at the assembly level. If any of you know of a treasure trove of ASM-level documentation on sockets programming, I'd love to get my grubby mitts on it. > (that would be Nasm syntax... just "define" for Fasm??? What assembler > are you using, TC&S?) I'm using NASM.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Calling libraries from assembler. Next: Newbie Alert !!! |