Hi, MIPS64 appears to be building much better now in trunk, with n64/o32 multilib.
You can likewise adapt the patches to just build either of those or o32. Have fun! René Sent abroad - http://ExactCODE.com Germany. On Sep 23, 2010, at 21:19, Jan Rovins <[email protected]> wrote: > 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
