Re: [Tinycc-devel] TCC on new ARM EABI (ARMEL) [PATCH]

[Rob Landley]

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.