syscalls and fpc

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

syscalls and fpc

ik-6
Hi,

I found that the Do_Syscalls are written in assembly and have only
limited number of parameters (up to 6). Is there a way to write it
using array of TSysParam instead of having 7 different functions ?
Another question is, is there a way to use it witthout writing
assembly, like using it in libc or some other way ?

Thanks,
Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Jonas Maebe-2

On 10 Feb 2008, at 10:33, ik wrote:

> I found that the Do_Syscalls are written in assembly and have only
> limited number of parameters (up to 6). Is there a way to write it
> using array of TSysParam instead of having 7 different functions ?
> Another question is, is there a way to use it witthout writing
> assembly, like using it in libc or some other way ?

The libc versions are macros which also create assembler code (and  
also with separate macros for each amount of parameters).


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Micha Nelissen
In reply to this post by ik-6
ik wrote:
> Hi,
>
> I found that the Do_Syscalls are written in assembly and have only
> limited number of parameters (up to 6). Is there a way to write it
> using array of TSysParam instead of having 7 different functions ?

Maybe but it wouldn't make the assembler easier to read :-).

> Another question is, is there a way to use it witthout writing
> assembly, like using it in libc or some other way ?

Calling them doesn't require assembler, or what do you mean? You can try
to extend the compiler to support inlining of assembly functions ;-).

Micha
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Marco van de Voort

> > Another question is, is there a way to use it witthout writing
> > assembly, like using it in libc or some other way ?
>
> Calling them doesn't require assembler, or what do you mean? You can try
> to extend the compiler to support inlining of assembly functions ;-).

Or custom calling conventions. That would work at least for the freebsd
syscalls. It is like that in C.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

ik-6
In reply to this post by Micha Nelissen
On Thu, Feb 14, 2008 at 11:02 PM, Micha Nelissen <[hidden email]> wrote:
> ik wrote:
>  > Hi,
>  >
>  > I found that the Do_Syscalls are written in assembly and have only
>  > limited number of parameters (up to 6). Is there a way to write it
>  > using array of TSysParam instead of having 7 different functions ?
>
>  Maybe but it wouldn't make the assembler easier to read :-).

Actually the assembler is not that hard to understand :)
My point is, that I don't like the idea of 7 or 20 or 100 amount of
parameters to give answer to every need. I think we should find a
better way to implement it, like var args in C or open array in
pascal...

>
>
>  > Another question is, is there a way to use it witthout writing
>  > assembly, like using it in libc or some other way ?
>
>  Calling them doesn't require assembler, or what do you mean? You can try
>  to extend the compiler to support inlining of assembly functions ;-).

Well, I just don't like the idea of using assembler if there is a way
to avoid it... So my question is, is there a way to avoid it ?

>
>  Micha
>


Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Peter Vreman
In reply to this post by ik-6
>>  > I found that the Do_Syscalls are written in assembly and have only
>>  > limited number of parameters (up to 6). Is there a way to write it
>>  > using array of TSysParam instead of having 7 different functions ?
>>
>>  Maybe but it wouldn't make the assembler easier to read :-).
>
> Actually the assembler is not that hard to understand :)
> My point is, that I don't like the idea of 7 or 20 or 100 amount of
> parameters to give answer to every need. I think we should find a
> better way to implement it, like var args in C or open array in
> pascal...

I don't see any reason why it needs to be changed.
- It already works like var args in C from a program point of view.
- Syscalls have a known limited number of parameters.
- The way it now is programmed allows better code generation for the syscalls with
limited parameters.
- It is a syntax issue and there is a FAQ about syntax changes.

Peter


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Micha Nelissen
In reply to this post by ik-6
ik wrote:
> Actually the assembler is not that hard to understand :)
> My point is, that I don't like the idea of 7 or 20 or 100 amount of
> parameters to give answer to every need. I think we should find a
> better way to implement it, like var args in C or open array in
> pascal...

The linux kernel interface is always using registers, and since there
are a limited amount of registers, there is a max. number of arguments.
IIRC the maximum is 6, i386 limited: eax, ebx, ecx, edx, esi, edi, ebp.

Micha
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Vincent Snijders
Micha Nelissen schreef:

> ik wrote:
>> Actually the assembler is not that hard to understand :)
>> My point is, that I don't like the idea of 7 or 20 or 100 amount of
>> parameters to give answer to every need. I think we should find a
>> better way to implement it, like var args in C or open array in
>> pascal...
>
> The linux kernel interface is always using registers, and since there
> are a limited amount of registers, there is a max. number of arguments.
> IIRC the maximum is 6, i386 limited: eax, ebx, ecx, edx, esi, edi, ebp.

Fortunately I studied mathematics, so I can count the mentioned
registers: 7.

Vincent
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Florian Klämpfl
Vincent Snijders schrieb:

> Micha Nelissen schreef:
>> ik wrote:
>>> Actually the assembler is not that hard to understand :)
>>> My point is, that I don't like the idea of 7 or 20 or 100 amount of
>>> parameters to give answer to every need. I think we should find a
>>> better way to implement it, like var args in C or open array in
>>> pascal...
>>
>> The linux kernel interface is always using registers, and since there
>> are a limited amount of registers, there is a max. number of arguments.
>> IIRC the maximum is 6, i386 limited: eax, ebx, ecx, edx, esi, edi, ebp.
>
> Fortunately I studied mathematics, so I can count the mentioned
> registers: 7.

One stores the syscall number.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Marco van de Voort
In reply to this post by Vincent Snijders
> Micha Nelissen schreef:
> > ik wrote:
> >> Actually the assembler is not that hard to understand :)
> >> My point is, that I don't like the idea of 7 or 20 or 100 amount of
> >> parameters to give answer to every need. I think we should find a
> >> better way to implement it, like var args in C or open array in
> >> pascal...
> >
> > The linux kernel interface is always using registers, and since there
> > are a limited amount of registers, there is a max. number of arguments.
> > IIRC the maximum is 6, i386 limited: eax, ebx, ecx, edx, esi, edi, ebp.
>
> Fortunately I studied mathematics, so I can count the mentioned
> registers: 7.

Then you should also see dangerous hidden assumptions:

Not all parameters occupy a single register. off_t for 64-bit fs calls e.g.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

ik-6
In reply to this post by Micha Nelissen
On Fri, Feb 15, 2008 at 8:36 PM, Micha Nelissen <[hidden email]> wrote:

> ik wrote:
>  > Actually the assembler is not that hard to understand :)
>  > My point is, that I don't like the idea of 7 or 20 or 100 amount of
>  > parameters to give answer to every need. I think we should find a
>  > better way to implement it, like var args in C or open array in
>  > pascal...
>
>  The linux kernel interface is always using registers, and since there
>  are a limited amount of registers, there is a max. number of arguments.
>  IIRC the maximum is 6, i386 limited: eax, ebx, ecx, edx, esi, edi, ebp.

You are welcome to correct me if I wrong, but can't I use prameters as follows:

push param1
push param2
push param3
....
push paramX
call syscall

?

If so, then I don't think there is a specific need for using the eax,
ebx registers etc..
Please look at the C deceleration of the syscall:
int syscall(int number, ...);


It uses var_args, and therefor 6 registers are not enough imho...
because tomorrow some one can add new call with 10 params, and then
what ? I can't find any documentation that limit the amount of
parameters that can be given to the function (at least in Linux, maybe
POSIX/BSD/Solaris/Other have different rules)

>  Micha


Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

ik-6
Another issue (I should report it as a bug imho) is that Do_Syscall is
not really usable if you require to use different parameters then
integer value, for example: PChar.

A call for example that use PChar as one of it's parameter is
inotify_add_watch .

I think that the entire design of the Do_SysCall is malformed in the
way it assumes the number of parameters and also the type of them, so
as I asked before, how I can either call the syscall command without
assembler, or how I can pass an array of const (prior to that I asked
regarding array of TSysParam) to assembly if three is no other way to
use syscall ?

Ido

On Feb 15, 2008 9:50 PM, ik <[hidden email]> wrote:

> On Fri, Feb 15, 2008 at 8:36 PM, Micha Nelissen <[hidden email]> wrote:
> > ik wrote:
> >  > Actually the assembler is not that hard to understand :)
> >  > My point is, that I don't like the idea of 7 or 20 or 100 amount of
> >  > parameters to give answer to every need. I think we should find a
> >  > better way to implement it, like var args in C or open array in
> >  > pascal...
> >
> >  The linux kernel interface is always using registers, and since there
> >  are a limited amount of registers, there is a max. number of arguments.
> >  IIRC the maximum is 6, i386 limited: eax, ebx, ecx, edx, esi, edi, ebp.
>
> You are welcome to correct me if I wrong, but can't I use prameters as follows:
>
> push param1
> push param2
> push param3
> ....
> push paramX
> call syscall
>
> ?
>
> If so, then I don't think there is a specific need for using the eax,
> ebx registers etc..
> Please look at the C deceleration of the syscall:
> int syscall(int number, ...);
>
>
> It uses var_args, and therefor 6 registers are not enough imho...
> because tomorrow some one can add new call with 10 params, and then
> what ? I can't find any documentation that limit the amount of
> parameters that can be given to the function (at least in Linux, maybe
> POSIX/BSD/Solaris/Other have different rules)
>
>
> >  Micha
>
>
> Ido
> --
> http://ik.homelinux.org/
>



--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Marco van de Voort
> Another issue (I should report it as a bug imho) is that Do_Syscall is
> not really usable if you require to use different parameters then
> integer value, for example: PChar.

> I think that the entire design of the Do_SysCall is malformed in the
> way it assumes the number of parameters and also the type of them, so
> as I asked before, how I can either call the syscall command without
> assembler, or how I can pass an array of const (prior to that I asked
> regarding array of TSysParam) to assembly if three is no other way to
> use syscall ?

So we can write you up as volunteer to write up prototypes (and worse
maintain them) for about 300 calls per OS per arch?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

ik-6
On Feb 16, 2008 2:00 AM, Marco van de Voort <[hidden email]> wrote:

> > Another issue (I should report it as a bug imho) is that Do_Syscall is
> > not really usable if you require to use different parameters then
> > integer value, for example: PChar.
>
> > I think that the entire design of the Do_SysCall is malformed in the
> > way it assumes the number of parameters and also the type of them, so
> > as I asked before, how I can either call the syscall command without
> > assembler, or how I can pass an array of const (prior to that I asked
> > regarding array of TSysParam) to assembly if three is no other way to
> > use syscall ?
>
> So we can write you up as volunteer to write up prototypes (and worse
> maintain them) for about 300 calls per OS per arch?

So what you are saying is, that because there are many commands that
can be used by syscall, you prefer to give support only to the ones
that actually in use by most programs, rather then to write something
more general that will support everything, and will do it right ?

Sorry but I still don't understand... The problem is the
design/approach of the way syscall is implemented in FPC, while you
are saying that because there are so many OS/commands that each use it
differently, you just want to leave it as-is because it works for you
...
So according to what you say, I can either mark that there is no
support for syscall in FPC (half work for most of the times is not
enough, it's just wrong desgin), or I don't understand whats going on.


Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Marco van de Voort
> On Feb 16, 2008 2:00 AM, Marco van de Voort <[hidden email]> wrote:
> > > way it assumes the number of parameters and also the type of them, so
> > > as I asked before, how I can either call the syscall command without
> > > assembler, or how I can pass an array of const (prior to that I asked
> > > regarding array of TSysParam) to assembly if three is no other way to
> > > use syscall ?
> >
> > So we can write you up as volunteer to write up prototypes (and worse
> > maintain them) for about 300 calls per OS per arch?
>
> So what you are saying is, that because there are many commands that
> can be used by syscall, you prefer to give support only to the ones
> that actually in use by most programs, rather then to write something
> more general that will support everything, and will do it right ?

There is no need to support all of them in the first place, and with formal
typing and support, also maintaining the structs come into play, making a
testsuite etc. Nothing that supports everything is easy, and nothing is ever
exactly right once reality comes crashing in, except the helicopter view
before actually getting your hands wet.
 
> Sorry but I still don't understand... The problem is the
> design/approach of the way syscall is implemented in FPC, while you
> are saying that because there are so many OS/commands that each use it
> differently, you just want to leave it as-is because it works for you

No, because it works period.

> So according to what you say, I can either mark that there is no
> support for syscall in FPC (half work for most of the times is not
> enough, it's just wrong desgin), or I don't understand whats going on.

I still haven't the faintest clue what your problem actually is, aside from
style issues. Sure it is not the neatest solution, but neither are syscalls
in general.

gcc solves it slightly better with heaps of macros and custom calling
conventions, a luxury that we don't have. And different per OS-arch
combination too. Moreover, there are multiple teams involved there (the
respective kernel teams, glibc, kernel), and we have to do it ourselves.

Moreover since more and more subsystems use functionality in libc that is
more than a mere wrapper (unicode is getting more popular, the
authentication and resolving systems get increasingly complicated due to
security), and duplicating that on bare bones syscalls is both an awful lot
of hard to get right work, and a security risk.

But if you want me to get you of the "maintain calls" list, and put you onto
the "create custom calling conventions by having directives that can assign
each and other param to a precies reg" list, by all means, say so. I'd be
happy to. I can write you up for the native unicode list and to fix netdb
too if you wish.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

ik-6
OK, so why don't you just say that you do not understand ?!

Let me start again. I never said that you, Micha, Daniel, Peter,
Florian, or even the big bad wolf should implement all of the given
syscall functions in the each platform in the world.

The design of Do_SysCall at this time is hurting the usage of
syscalls, for 3 reasons:

1. There is a support only for up to 6 parameters (plus the instruction itself).
2. It support only integer base parameters, while you can not pass
pointers, chars, array, record or floating point types.
3. Each OS changes/add/remove functions frequently, so assuming one of
the above making the functions unusable for anything that is not an
integer and up to 6 parameters.

(If you do not understand my points please ask, and I'll try to clear it up)

Now one *example* (that caused me to notice this issues) is the following:

extern int inotify_add_watch (int __fd, const char *__name, uint32_t __mask)

(Inotify is a Linux *only* feature that allows you to listen to any
file system event on request, and it replacing the dnotify event, that
had many issues).

So as you can see by the Do_SysCall function(s):

function Do_SysCall(sysnr,param1,param2,param3,param4,param5,param6:TSysParam):TSysResult;
 external name 'FPC_SYSCALL6';

They unable to give you an answer to the above deceleration.
So my questions are (still):

1. Is there a way to implement the above with array of const ?
2. Is there a way to implement the above without using assembly, and
if you must use assembly, then is there a way to use array of const
inside the assembly, and if so, how ?

As you can see, I still haven't requested anyone to do it for me, I'm
only trying to figure out how to achieve the above request with
syscall using FPC !

Here is a small way to do it btw, but it will be problematic with
records (if you use assembly):

function Do_SysCall(sysnr : TSysParam; const
param1,param2,param3,param4,param5,param6) : TSysResult;  external
name 'FPC_SYSCALL6';

The problem is of course the number of bits that the registers can
store in them (32 bit in i386 and 64 bit on x86_64).
So when Micha mentioned the registers, I asked if my knowledge is
valid, that you can do the following:

push param1
push param2
push param3
...
push param6

And as you can see, you do not need to use specific register, but the
system handle the bits for you.
I hope you do understand the problematic design of Do_SysCall, and I
hope you now understand what I'm asking and talking about. If you do
not understand any point, please ask instead of arguing.


Regardless of that, I do not expect FPC to have implementation of 100%
of each system SysCall, because if I require to use a syscal, I'll
call it,. or bind it:

function Do_SysCall(sysnr : TSysParam; const
param1,param2,param3,param4,param5,param6) : TSysResult;  external;

That way, it will be binding to he running environment of Linux or any
other supported system. However I do not like this method, and
therefor I prefer the usage of syscall instead.


Ido

On Feb 16, 2008 2:31 AM, Marco van de Voort <[hidden email]> wrote:

> > On Feb 16, 2008 2:00 AM, Marco van de Voort <[hidden email]> wrote:
> > > > way it assumes the number of parameters and also the type of them, so
> > > > as I asked before, how I can either call the syscall command without
> > > > assembler, or how I can pass an array of const (prior to that I asked
> > > > regarding array of TSysParam) to assembly if three is no other way to
> > > > use syscall ?
> > >
> > > So we can write you up as volunteer to write up prototypes (and worse
> > > maintain them) for about 300 calls per OS per arch?
> >
> > So what you are saying is, that because there are many commands that
> > can be used by syscall, you prefer to give support only to the ones
> > that actually in use by most programs, rather then to write something
> > more general that will support everything, and will do it right ?
>
> There is no need to support all of them in the first place, and with formal
> typing and support, also maintaining the structs come into play, making a
> testsuite etc. Nothing that supports everything is easy, and nothing is ever
> exactly right once reality comes crashing in, except the helicopter view
> before actually getting your hands wet.
>
> > Sorry but I still don't understand... The problem is the
> > design/approach of the way syscall is implemented in FPC, while you
> > are saying that because there are so many OS/commands that each use it
> > differently, you just want to leave it as-is because it works for you
>
> No, because it works period.
>
> > So according to what you say, I can either mark that there is no
> > support for syscall in FPC (half work for most of the times is not
> > enough, it's just wrong desgin), or I don't understand whats going on.
>
> I still haven't the faintest clue what your problem actually is, aside from
> style issues. Sure it is not the neatest solution, but neither are syscalls
> in general.
>
> gcc solves it slightly better with heaps of macros and custom calling
> conventions, a luxury that we don't have. And different per OS-arch
> combination too. Moreover, there are multiple teams involved there (the
> respective kernel teams, glibc, kernel), and we have to do it ourselves.
>
> Moreover since more and more subsystems use functionality in libc that is
> more than a mere wrapper (unicode is getting more popular, the
> authentication and resolving systems get increasingly complicated due to
> security), and duplicating that on bare bones syscalls is both an awful lot
> of hard to get right work, and a security risk.
>
> But if you want me to get you of the "maintain calls" list, and put you onto
> the "create custom calling conventions by having directives that can assign
> each and other param to a precies reg" list, by all means, say so. I'd be
> happy to. I can write you up for the native unicode list and to fix netdb
> too if you wish.
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>



--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Vincent Snijders
ik schreef:
> OK, so why don't you just say that you do not understand ?!

You don't understand.

>
> Let me start again. I never said that you, Micha, Daniel, Peter,
> Florian, or even the big bad wolf should implement all of the given
> syscall functions in the each platform in the world.
>
> The design of Do_SysCall at this time is hurting the usage of
> syscalls, for 3 reasons:
>
> 1. There is a support only for up to 6 parameters (plus the instruction itself).

Yes, and for i386 that is the limit, dictated by the hardware.

> 2. It support only integer base parameters, while you can not pass
> pointers, chars, array, record or floating point types.

Syscall pass registers, which are integers, so I don't see the problem.

> 3. Each OS changes/add/remove functions frequently, so assuming one of
> the above making the functions unusable for anything that is not an
> integer and up to 6 parameters.

Which syscall has more than 6 parameter or a parameter that does not fit
in a register?

>
> (If you do not understand my points please ask, and I'll try to clear it up)

See above, I think I don't understand.

>
> Now one *example* (that caused me to notice this issues) is the following:
>
> extern int inotify_add_watch (int __fd, const char *__name, uint32_t __mask)

Is this a syscal with 3 parameters that fit in a register?

>
> So as you can see by the Do_SysCall function(s):
>
> function Do_SysCall(sysnr,param1,param2,param3,param4,param5,param6:TSysParam):TSysResult;
>  external name 'FPC_SYSCALL6';
>
> They unable to give you an answer to the above deceleration.
> So my questions are (still):
>
> 1. Is there a way to implement the above with array of const ?

Why? Not needed.

> 2. Is there a way to implement the above without using assembly, and
> if you must use assembly, then is there a way to use array of const
> inside the assembly, and if so, how ?

Why? Not needed.

>
> As you can see, I still haven't requested anyone to do it for me, I'm
> only trying to figure out how to achieve the above request with
> syscall using FPC !
>
> Here is a small way to do it btw, but it will be problematic with
> records (if you use assembly):
>
> function Do_SysCall(sysnr : TSysParam; const
> param1,param2,param3,param4,param5,param6) : TSysResult;  external
> name 'FPC_SYSCALL6';
>
> The problem is of course the number of bits that the registers can
> store in them (32 bit in i386 and 64 bit on x86_64).
> So when Micha mentioned the registers, I asked if my knowledge is
> valid, that you can do the following:
>
> push param1
> push param2
> push param3
> ...
> push param6

No, you cant't because the kernel expects the parameters in the
registers and put them on the stack.

The rest *I* did not understand, so I snipped it.

For your example, I expect you to write a wrapper like (taken one at
random):
function fpugetrlimit(resource : cInt; rlim : PRLimit) : cInt;
begin
   FpUGetRLimit := do_syscall(syscall_nr_ugetrlimit,
     TSysParam(resource), TSysParam(rlim));
end;

Something like:
function fpinotify_add_watch (__fd: cint; __name: pchar; __mask:
cuint32) : cint;
begin
   fpinotify_add_watch := do_syscall(syscall_nr_inotify_add_watch,
TSysParam(__fd), TSysParam(__name), TSysParam(__mask));
end;

Vincent
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Florian Klämpfl
In reply to this post by ik-6
ik schrieb:
> 1. There is a support only for up to 6 parameters (plus the instruction itself).

Which syscall has more parameters?

> 2. It support only integer base parameters, while you can not pass
> pointers, chars, array, record or floating point types.

Did you just calculate how much functions it would take to support all
these combinations besides the fact that no kernel function takes e.g.
floats.

> 3. Each OS changes/add/remove functions frequently, so assuming one of
> the above making the functions unusable for anything that is not an
> integer and up to 6 parameters.

Example? Did you realize that the linux supports _only_ one calling
convention: taking the syscall number in a register and the other
parameters in the remaining six registers?

>
> 1. Is there a way to implement the above with array of const ?

Just add typecasts and a wrapper. Array of const is slow and not
suitable for such low level stuff.

> 2. Is there a way to implement the above without using assembly,

Just add type casts.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

ik-6
On Feb 16, 2008 10:03 PM, Florian Klaempfl <[hidden email]> wrote:
> ik schrieb:
> > 1. There is a support only for up to 6 parameters (plus the instruction itself).
>
> Which syscall has more parameters?

I don't know, but then again, up until now I did not require to use
syscall on my own (at least using FPC, because I used "write" using
"pure" assembly). But now that I do require, I found a design that I
find it problematic. But as I understand, I'm the only one that think
there is a problem, so I'll give up and I'll not bother you on this
again.

>
> > 2. It support only integer base parameters, while you can not pass
> > pointers, chars, array, record or floating point types.
>
> Did you just calculate how much functions it would take to support all
> these combinations besides the fact that no kernel function takes e.g.
> floats.

Exactly my point on the design in the first place. The corrent design
takes integers only. Regarding the Linux Kernel, I did not knew about
the floating points issues, but what about pointers, arrays, structs
etc ?

>
> > 3. Each OS changes/add/remove functions frequently, so assuming one of
> > the above making the functions unusable for anything that is not an
> > integer and up to 6 parameters.
>
> Example? Did you realize that the linux supports _only_ one calling
> convention: taking the syscall number in a register and the other
> parameters in the remaining six registers?

Yes and no, I did used assembly with syscalls for "write" (several
years ago), but I can't find any documentation about syscall that
write about it. In fact the only documentation I did found (even using
google and not only using man. However on "man 2 syscalls" I found the
following line:
"It  is  different with select and mmap.  These use five or more
parameters, and caused problems the way parameter passing on the i386
used to be set up."

At the end of the above paragraph:
"These  days  passing  five parameters is not a problem any more, and
there is a __NR__newselect (used by libc 6) that corresponds directly
to sys_select() and similarly __NR_mmap2."

So originally the problem was 5 parameters not 6 ! and there are
functions that might have more then 6 parameters, but they recommend
an "alias" that uses less, and points to the original functions.
BTW, why the C function uses var_args and not using overloads or other
"magic" to pass the valid amount of parameters ?
<int syscall(int number, ...);>

And there are changes for every type of bit:
"On newer platforms that only have 64-bit file access and 32-bit uids
(e.g., alpha, ia64, s390x) there are no *64 or *32 calls.  Where the
*64  and  *32  calls  exist,  the other versions are obsolete."

The manual is dated to 2002-01-07 (I copied it from the man page).


>
> >
> > 1. Is there a way to implement the above with array of const ?
>
> Just add typecasts and a wrapper. Array of const is slow and not
> suitable for such low level stuff.

OK

>
> > 2. Is there a way to implement the above without using assembly,
>
> Just add type casts.
>


Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: syscalls and fpc

Jonas Maebe-2

On 16 Feb 2008, at 21:55, ik wrote:

> Exactly my point on the design in the first place. The corrent design
> takes integers only. Regarding the Linux Kernel, I did not knew about
> the floating points issues,

I don't know of a single OS kernel which supports using floating point  
in kernel space.

> but what about pointers, arrays, structs
> etc ?

Pointers are the same size as TSysParam. There are no system calls  
which take arrays, structs etc.

> "These  days  passing  five parameters is not a problem any more, and
> there is a __NR__newselect (used by libc 6) that corresponds directly
> to sys_select() and similarly __NR_mmap2."
>
> So originally the problem was 5 parameters not 6 !

They added usage of ebp only later on.

> and there are
> functions that might have more then 6 parameters,

Which ones?

> BTW, why the C function uses var_args and not using overloads

C doesn't support function overloading.

> or other
> "magic" to pass the valid amount of parameters ?
> <int syscall(int number, ...);>

Function overloading is no more magic than varargs.

> And there are changes for every type of bit:
> "On newer platforms that only have 64-bit file access and 32-bit uids
> (e.g., alpha, ia64, s390x) there are no *64 or *32 calls.  Where the
> *64  and  *32  calls  exist,  the other versions are obsolete."

I don't understand what what this has to do with the way system call  
interfacing works.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12