On Monday 09 November 2009 16:09:05 Mike Frysinger wrote:
> On Sunday 08 November 2009 19:12:57 Rob Landley wrote:
> > #define EM_XTENSA 94 /* Tensilica Xtensa Architecture
> > */ #define EM_IP2K 101 /* Ubicom IP2022 micro
> > controller #define EM_CR 103 /* National
> > Semiconductor 3define EM_MSP430 105 /* TI msp430 micro
> > controller */ #define EM_BLACKFIN 106 /* Analog Devices
> > Blackfin */ #define EM_ALTERA_NIOS2 113 /* Altera Nios II soft-core
> > processor */ #define EM_CRX 114 /* National
> > Semiconductor CRX */ #define EM_NUM 95
> >
> > Isn't EM_NUM supposed to be one higher than the largest number used?
>
> yes, but i dont think anyone actually uses this thing.
If I wasn't trying to use it I wouldn't have asked about it.
As for one obscure little user, when the Linux kernel creates an x86 bzImage
from a vmlinux image it uses arch/x86/boot/compressed/relocs.c, and line 8 is
"#include <elf.h>". So if you yank that header, you can't build an ARCH=x86
Linux kernel with a uClibc toolchain. (And probably other ARCHes, that's just
the one I'm familiar with off the top of my head. They all start with
vmlinux...)
The reason I know that is if you try to build a Linux kernel on a macintosh
host, it dies when it gets to that point due to mac's mach-o based headers not
having ELF support. (The Linux kernel guys' rationale is that relocs.c is a
utility you build and run on the host, and thus uses the host headers. You
can patch it to use linux/elf.h, and that's what you in fact need to do to
build a Linux kernel on a macintosh host, but it's nontrivial and they haven't
wanted to take the patch upstream yet.)
By the way, how do you think uClibc's own dynamic linker is supposed to get
these constants? Hint: ldso/ldso/$ARCH/dl-sysdep.h #includes <elf.h>, for
over a dozen different $ARCH values. Without this header, the dynamic linker
can't get the EM_ values it needs to recognize native binaries.
The reason I know _that_ is because sparc gets it wrong, and I've been
carrying this patch for ages:
Sparc v8 and v9 should still support EM_SPARC binaries, not _just_
SPARC32PLUS.
--- uClibc/ldso/ldso/sparc/dl-sysdep.h 2008-09-15 11:36:11.000000000 -0500
+++ uClibc.bak/ldso/ldso/sparc/dl-sysdep.h 2009-04-08 01:09:53.000000000 -0500
@@ -29,13 +29,8 @@
/* Here we define the magic numbers that this dynamic loader should accept
* Note that SPARCV9 doesn't use EM_SPARCV9 since the userland is still 32-
bit.
*/
-#if defined(__sparc_v9__) || defined(__sparc_v8__)
#define MAGIC1 EM_SPARC32PLUS
-#else
-#define MAGIC1 EM_SPARC
-#endif
-
-#undef MAGIC2
+#define MAGIC2 EM_SPARC
/* Used for error messages */
#define ELF_TARGET "sparc"
Support for the newer binary type doesn't necessarily mean you drop support
for the older one...
> might be easier to just punt it.
And abandoning the entire project rather than ever fixing any issues pointed
out in it would be even easier to do, but might not be the right thing from an
engineering standpoint.
(I still don't understand why Erik's readelf.c got yanked. Worked fine for
years, and it took me about 5 minutes to get it building against both glibc
and uClibc with a simple "gcc readelf.c". Too much trouble to maintain?
Really?)
> if we do fix it, we should important the holes from
> binutils. -mike
It seems to me that the logical thing to do with the EM_ symbols list
(presumably what was giving you headaches with readelf.c) is to trim it down
to the set of systems uClibc actually supports. Go ahead and let the rest be
unknown, there's nothing wrong with that. There _will_ be unknowns, and
identifying what _kind_ of lack of support we have is of dubious utility.
(The "file" command has its own database for that sort of thing.) But lots of
things need the constants for the current host, so we _do_ need the values for
all the targets uClibc runs on.
It also seems to me that most of the interesting stuff is in linux/elf.h
already, which could presumably be #included from an elf.h one level up. The
kernel guys don't quite sanitize it in headers_install (the 32 and 64 bit base
types are still in kernel __u64 and friends), but Linux adheres to the LP64
standard:
http://www.unix.org/whitepapers/64bit.html http://www.unix.org/version2/whatsnew/lp64_wp.htmSo it's a fairly simple sed to convert 'em all. Something like (off the top of
my head, untested):
sed -e 's/__u16/unsigned short/g' -e 's/__u32/unsigned int/g' \
-e 's/__u64/unsigned long long/g' -e 's/__s16/signed short/g' \
-e 's/__s32/signed int/g' -e 's/__s64/signed long long/' \
-i linux/elf.h
And then 2/3 of elf.h presumably becomes "#include <linux/elf.h>"
(Dunno if it would actually work, but the kernel guys are riffing on a standard,
and gratuitous deviations from that standard are something they're likely to
avoid for code hygiene reasons, and might take upstream patches for if any
were found.)
There are still things linux/elf.h hasn't got, such as the EM_ constants and
the wrappers to provide "current host size" for 32 bit or 64 bit types. The
top level elf.h wouldn't be _just_ a wrapper. But it's a lot _less_ to
maintain, and the Linux guys have to support their elf.h or they can't _run_
elf binaries.
Anyway, that seems like a more interesting direction to explore than "I don't
understand this, let's drop it".
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc
signature.asc (853 bytes) 