On Thu, Aug 23, 2012 at 09:37:44PM +1000, Jonathan Gray wrote: > On Thu, Aug 23, 2012 at 07:33:37AM -0400, Brad Smith wrote: > > On Thu, Aug 23, 2012 at 09:30:03PM +1000, Jonathan Gray wrote: > > > On Thu, Aug 23, 2012 at 01:11:24AM -0400, Brad Smith wrote: > > > > On Thu, Aug 23, 2012 at 02:56:16PM +1000, Jonathan Gray wrote: > > > > > On Tue, Aug 21, 2012 at 02:48:59PM -0400, Brian Callahan wrote: > > > > > > I noticed that devel/llvm now has target support for mips64 and > > > > > > mips64el. The following patch is needed for those two archs. LLVM > > > > > > builds and seems to work OK from my admittedly basic testing on > > > > > > mips64el. > > > > > > > > > > > > Clang builds only with a newer version of gas (I used 2.22) but it > > > > > > does not compile anything; it crashes when you try to compile even a > > > > > > simple Hello World. I've reported it upstream but I'm unable to > > > > > > follow any of their suggestions - my yeeloong cannot compile clang > > > > > > with -O0 or a debug build because it runs out of memory (ulimit -d > > > > > > is maxed at 1G in the kernel). > > > > > > > > > > > > Thanks. > > > > > > > > > > > > ~Brian > > > > > > > > > > You'll likely want the following as well. mips binutils is very > > > > > fragile, I doubt you want 2.22 and 2.17 in the tree needs more work > > > > > for mips64. > > > > > > > > The additions of __MIPSEB__/__MIPSEL__ and __mips__ are redundant > > > > over what is already there. __mips64__ is fine. > > > > > > actually it is required, in the kernel alone: > > > > > > $ fgrep -r __mips__ /usr/src/sys/* | wc -l > > > 10 > > > $ fgrep -r __MIPSEL__ /usr/src/sys/* | wc -l > > > 15 > > > $ fgrep -r __MIPSEB__ /usr/src/sys/* | wc -l > > > 22 > > > > What I mean is the existing config already has those symbols set. > > ah, seems you are correct indeed. It is strange how __x86_64__ is > explictly set then.
Some of the symbols are provided without the underscores on each side like i386/mips/sparc only when in GNU mode (-std=gnu99) to mimic what GCC does but they probably don't want to add more unless GCC was already doing so in the past so newer symbols like for amd64 do not do that. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
