[uClibc] Hyperstone E1-32X Port for uClibc-0.9.19
Erik Andersen
andersen at codepoet.org
Thu Sep 11 10:18:13 UTC 2003
On Wed Sep 10, 2003 at 02:50:59PM +0000, George Thanos wrote:
>
> Dear Erik, list,
>
> I would like to announce the porting of uClibc v 0.9.19 for the
> Hyperstone's E1-32X architecture. A parallel port of uClinux-2.4.x and
> uClibc took place by Hyperstone (www.hyperstone.com) and GDT
> (www.gdt.gr). The uClinux E1-32X sources are already in the uClinux CVS
> repository under the name "e1nommu".
Cool, thanks!
> We would also like to publicise our uClibc port by uploading it to the
> uClibc CVS. How this can be done? Should I send a patch file or a
> tarball with the architecture dependent files?
A patch and/or a tarball works just fine. You will probably want
to send the patch/tarball directly to me (rather than to the
list) since it will probably exceed 40k (the current msg size
limit for the list).
> 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.
> 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.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
More information about the uClibc
mailing list