[uClibc] Hyperstone E1-32X Port for uClibc-0.9.19

David McCullough davidm at snapgear.com
Fri Sep 12 00:54:09 UTC 2003


Jivin Erik Andersen lays it down ...
> > While the prototype of open in include/fcntl.h takes a variable number 
> > of parameters the actual implementation receives a fixed number of 
> > parameters. In some architectures that the compiler handles differently 
> > a fixed and a variable list of arguments both in the calling and the 
> > called function this can be a problem and parameter passing can be 
> > totally wrong.
> > 
> > To be a little more specific on the problem, our architecture affords 
> > two separate stacks in the same user level process. When using a fixed 
> > number of parameters the compiler passes arguments through the 1st 
> > stack, while when using a variable number of parameters the compiler 
> > passes arguments through the second stack.
> 
> I see.
> 
> > When the prototype indicates a variable parameter list the calling 
> > function passes parameters through the second stack, but the called 
> > function that is build with a fixed number of parameters receives 
> > parameters through the first stack. This gives an impression of the 
> > mess. The result is an unexpected and severe kernel crash.
> 
> Certainly sounds like you need to fix your kernel!  But it also
> seems like a good way to catch/find/fix such problems in uClibc.

This is a coding bug,  if you prototype with the "...",  then you had
better implement it that way as well.  Not all arches pass parameters
like the x86/m68k/arm guys.

Archs that pass args in registers by default also get caught by this
(ie., SuperH and H8).

Given this beast is a nommu platform,  it probably can't deal with
mixed up stacks very well :-(

> > Are there any other system calls that have a variable number of 
> > parameter list in their prototype but a fixed list in their 
> > implementation? I would like to check similar problems before we provide 
> > our sources along with the required patches for the architecture 
> > independent files.
> 
> Possibly, but I am not certain without spending the time to audit
> all the syscalls.  Since it works for other arches, but not for
> the e1nommu, and because I am feeling a bit lazt,  I'd rather
> leave the burden of spending a couple of tedious hours comparing
> the code to the SuSv3 spec, and/or C99 spec to you.  Converting
> such syscalls to instead use varargs should be relatively straigt
> forward work.  I would be happy to apply a patch making such a
> change to all the common code.

I had gone through this myself,  I thought I had updated uClibc.org with
the changes.  Is it just that these guys are still using an old version
of uClibc which doesn't have __libc_fcntl implemented appropriately ?

I checked syscalls.c and __libc_fcntl is implemented using varargs.
The one I fixed months back was __libc_open.

Cheers,
Davidm

-- 
David McCullough, davidm at snapgear.com  Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security   Fx:+61 7 38913630 http://www.uCdot.org



More information about the uClibc mailing list