[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