On 9/23/2010 2:39 PM, René Rebe wrote:
Hi,
On Sep 23, 2010, at 20:13 , Jan Rovins wrote:
On 9/23/2010 1:37 PM, Rene Rebe wrote:
Porting the MIPS bits in dietlibc to 64 bit may only take some hours of trial
and error. In fact I may even do so the next days (donations welcome :-).
I looked at that dietlibc code a while ago, and tried to do some things so it
would build for mips64, but I gave up because there was too much mips32
specific assembly code in there that would need porting, and my knowledge of
Mips64 assembly was not sufficient to do this in a reasonable amount of time,
If you can find a way to bypass those assembly code issues, or are not daunted
by coding at that level, perhaps a few hours will do it.
well, I'm doing such stuff for years.
You could mark dietlibc [R] - mips64 temporarily (in it's .desc).
Thanks for the tip.
I have a local mips64 glibc fix that i am just test build to check regressions
and hope to commit any minute.
The glibc solution is at the heart of the mips64 building troubles, I was never
able to get multilib working, so I bailed out into building it either as n64abi
or n32abi. for embedded purposes, it may still be good to let the user specify
whether its multilib, single lib n64 or single lib n32.
In building off the trunk as it is right now, I am getting the o32 abi libs in
/lib and the n32 abi libs in /lib64.
The question arises as to which libs really should be used where. The o32 abi
libs are the true old 32 bit libs which will allow the running of the ancient
mips32 binaries on a mips64 system, but the n32 abi libs are of more interest
to someone running on modern 64bit hardware, and wants to maintain a 32 bit
user space. the n32 abi relies on some 64bit hardware features, and is not
usable on 32bit hardware, but it is still a 32 bit abi, not a full 64bit abi. I
think n32 would be the most common choice for a 32bit abi on current Mips
technology. I think the true n64 abi should be in /lib64. The question is:
does one library solution make sense for every one using Mips64, or should we
let them pick their own combos?
Personally I would set it up like powerpc64, or x86-64, that is default to the
full 64bit binaries in lib64 and have fully backward compatible lib/ support to
support running the vanilla 32bit binaries of the architecture, which for MIPS
would mean o32.
Yes that makes sense in respect to keeping the /lib setup consistent across all the
different architectures supported by T2.
I see little benefit in supporting the n32 variant. Of course anyone is free to
setup his target to build n32 if they want to gain the extra performance %
digit, ... But as outlined I would default to reasonable choices, the efforts
to keep them working are already high enough. The Linux kconfig has this:
Select this option if you want to run n32 binaries. These are
64-bit binaries using 32-bit quantities for addressing and certain
data that would normally be 64-bit. They are used in special
cases.
If unsure, say N.
Even though the kernel says "Say No", I think n32 will be of high intrest to embedded
developers, working on new Mips64 hardware. Once you have the fundamental multilib issues
sorted out, I will submit an other patch to allow the use of n32 in some way that makes
sense, and hopefully won't involve too much effort to maintain.
Jan
So this would mean fixing trunk to built n64 binaries instead of n32 gcc is
apparently (accidentally) defaulting to.
René
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
