On Monday 11 September 2006 9:23 pm, Daniel Glöckner wrote: > Attached is a patch that modifies current cvs to allow it to compile > itself on Linux ARM EABI.
So I'm pondering applying this to my mercurial tree, and I'd like to ask a few questions. What exactly does this do? I mean, what _is_ arm EABI? The codesourcery page on this says that EABI is a nickname for Arm's documented ABI: http://www.codesourcery.com/gnu_toolchains/arm/faq.html#q_ABI_what_is_abi So what was tcc on arm doing _before_? (Producing working but nonstandard binaries that couldn't trade .o files with gcc, maybe?) I'm confused by the start of your patch: - $(CC) $(CFLAGS) -DTCC_TARGET_ARM -o $@ $< $(LIBS) + $(CC) $(CFLAGS) -DTCC_TARGET_ARM -DTCC_ARM_EABI -o $@ $< $(LIBS) ... +#ifdef TCC_ARM_EABI +#define TCC_ARM_VFP +#endif I take it that -DTCC_TARGET_ARM does not already imply -DTCC_ARM_EABI? There's some value in selecting them independently? (Should we have something like menuconfig? I'm in the process of helping genericize that infrastructure so it can be more easily applied to other projects...) Same question for TCC_ARM_VFP, there's some value in being able to select it discreetly? > I also made enums EABI compliant by changing VT_ENUM into a flag and > setting the basetype according to the enum values. But when I saw that > GCC behaves non-conforming, I undid that change. Is this for compatability with gcc, or is this because that part of the ABI seems kinda pointless if nobody implements it? > ARM EABI is enabled by compiling TCC with -DTCC_ARM_EABI in addition to > -DTCC_TARGET_ARM. VFP can be enabled independently by compiling with > -DTCC_ARM_VFP. Why? What's a non-EABI ARM? (Different kernel versions? Different processors?) Back to the basic "what does this fix, what does switching it off mean" question above... > Btw.: > ln -s /lib/libgcc_s.so.1 /usr/lib/tcc/libtcc1.a > is sufficient for most programs. What does that do? (I know about libgcc_s and consider it kind of horrible, I'm wondering what circumstances the above is recommended for. Do you mean this fakes out existing makefiles, or some kind of compatability when bits of the program are compiled with gcc and other bits with tcc, or running programs compiled with gcc on a machine that doesn't have gcc's shared libraries, or...?) > Daniel I am waaaaay out of my element here... :) Rob -- Never bet against the cheap plastic solution. _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
