Sunday, December 28, 2008

glibc doesn't build with linux-header-2.6.28 on loongson

Update: It is said that this problem has already been fixed. I will test it later.

Actually I intended to send this to LKML, but just before I was about to send I found there was already some discussions about this . So instead I decided to just post it here.

To make long story short, please take a look at these two files first:

The first file, which will become part of /usr/include/endian.h. This file defines both __LITTLE_ENDIAN and __BIG_ENDIAN. And this file will be included by the second file.

The second file, which will be /usr/include/linux/byteorder.h

Obviously, this test in the second file will fail:
#if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)
# error Fix asm/byteorder.h to define one endianness
#endif
It seems that there is an inconsistency between Linux and glibc on handling __LITTLE_ENDIAN and __BIG_ENDIAN. Linux treats them like a flag, while glibc treats them like a value. glibc uses __BYTE_ORDER to determine the endianness.

This problem must be solved, or any userland program including kernel headers which include {asm,linux}/byteorder.h will fail to build, e.g. glibc.

It seems to me that the most straight forward way, but also very intrusive way is to make the handling of these two marco consistent in the two projects. That'll be a very large changeset. Also it will suddenly change a convention in a project that has already been followed for a long time. So I don't think people will accept this.

How this problem will be solved is still remained to be seen.

EDIT: someone reported that it worked well on ~amd64. So I modified the title and removed the last sentence. I will see if this problem still exists on my x86 notebook.

EDIT 2: I confirm that this problem does not exists on x86. I will find out what exactly is going on loongson, or rather mips. :)

Labels: ,

Thursday, December 25, 2008

Works I have done related to Loongson in recent months

I got a donation of a Lemote Loongson 2F box somewhere around July this year and have been working on it in my spare time since I got it.

The other day I made a summary about what I have done so far and posted it on Lemote's bbs. The links is http://www.lemote.com/bbs/viewthread.php?tid=20134
My work involves toolchain, kernel, xorg-server MIPS or Loongson support and userland library/application gcc 4.4 patch.

The most prominent achievement so far is an N32 ABI stage3 (well, actually just a tarball, not made using catalyst) optimized for Loongson 2F with MIPS PLT support. It is actually not that easy as you would've imagined, N32 has many problems as you can see from the above posted link. I posted it on Lemote's bbs along with some instructions of how to use it: http://www.lemote.com/bbs/viewthread.php?tid=20125

According to some testers, performance of some applications in this system has an up to 30% increase comparing with the performance of the same apps in system Using O32 ABI without optimization for Loongson 2F and MIPS PLT support.

I have just got laid off by my former employer (however no need to worry for me, new jobs will find me soon), that means currently I have a lot of time doing things I'd like to do, like Loongson. Now I am still working on the problems I have encountered so far, currently xulrunner for N32 ABI, which will lead ultimately to firefox on MIPS N32 ABI userland system.
https://developer.mozilla.org/en/xptcall_FAQ
http://mxr.mozilla.org/mozilla/source/xpcom/reflect/xptcall/porting.html
I wish I could finish it before 2009 comes, ;)

Labels: ,