This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
re: SPARC64 & SPARC binutils
- To: David Dudley <binutils at starblade dot com>
- subject: re: SPARC64 & SPARC binutils
- From: matthew green <mrg at cygnus dot com>
- Date: Sun, 07 Jan 2001 17:03:05 +1100
- Cc: binutils at sources dot redhat dot com
- organisation: Red Hat, Inc.
When I configure for 'sparc-elf', no problem, except that I generate
'elf32-sparc' output files, and I can't generate any sparc-V9 specific
code, or files.
this is to be expected.
When I configure for 'sparc64-elf', things generate fine, except that make
check fails myserably... and code that is generated (which DOES allow sparc-V9
i hadn't run "make check" for a while, and i do get two failures there:
FAIL: objcopy (simple copy)
FAIL: readelf -S
ops), won't load in the target, and processing them on the host (like, say,
why won't it load onto the target? what fails? this sounds like some other
problem related to your environment to me...
objcopy, for one), changes the actual output file, even if I tell it to do a
straight copy.
i believe the objcopy failure is caused by a bit being lost in the ELF
header... i thought i even posted about that here a couple of months
ago... but it shouldn't cause any failures to load, the bit is used to
determine what memory model the program should run with. the readelf
-S failure i am unfamiliar with.
And yes, I do need the GCC support,... I'm waiting hard for that one, and
finding out that the code generated for the SPARC, is still pretty good,
although not quite up to the sparc64 level.
i don't understand this. gcc 2.95.2 produces vaguely useful sparc64 code,
but there are many, many *serious* bugs in it. gcc-current last i tried
wouldn't even build for "sparc64-elf", either as a native target or cross
compiled (from x86). see the two PR's i logged against gcc.