[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