From: tin.cans.and.string on
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
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
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
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
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 !!!