[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] TCC on ARM
Re: [Tinycc-devel] TCC on ARM
Sat, 2 Dec 2006 12:40:34 -0500
On Friday 01 December 2006 4:21 pm, tike64 wrote:
> Rob Landley <address@hidden> wrote:
> > On Friday 01 December 2006 2:07 pm, Rob Landley wrote:
> > > The only way this _can_ matter is if A) this sub_ddmmss() thing
> > > on the host, not on the target (in which case, why the heck is it
> > > assembly?), B) the test is wrong and confusing host with target.
> I can't understand too clearly what is the libtcc1 needed for. Could it
> be that it is for long-long and float operations and those are not
> supported on arm target? Then the libtcc1 would not be built for cross
> compiler at all
Exactly. If tcc has the code to create arm binaries when running on i386,
then it has the code to create arm binaries when running on arm. Something
> but is tried to build for native arm-arm compiler in
> error. Shouldn't I then fix the Makefile to never build libtcc1 for arm
I think we need to figure out what libtcc1 does. Glancing at libtcc1.c it
seems to be the same as libgcc, I.E. functions to support for 64 bit math on
32 bit platforms (calls to which get generated when you do math on uint64_t
or "long long" -- when there's no assembly opcode for this, it has to call a
function behind the scenes).
For some of the 64-bit math, they have hand-optimized assembly routines to do
it. But this becomes part of the generated binary, which means this is for
the _target_, and the test they're doing is for the _host_, which is wrong.
The question is, how the heck does this work when cross-compiling? Either
there's code somewher else to do this (perhaps unoptimized C routines, which
would suck but suck portably), or else it's spitting out i386 machine code in
the arm binaries and attempts to use uint64_t on arm just don't work right
now, and nobody's noticed yet.
There may already be a patch for this in the mailing list archive...
> > Ok, looking closer:
> > 1) It's not in assembly, it's just ugly.
> > 2) It's not actually necessary.
> > This thing is only used in rt_error(), which is called from a signal
> > handler to try to give a better error message rather than just
> > the signal kill the compiler in case of a division by zero error or
> > some such.
> Now you are probably talking about the rt_get_caller_pc warning.
You're right, I was looking at the wrong chunk.
> on your notes I think that the code does the right thing and maybe the
> #warning could be simply removed
Actually, what I did in my fork (http://landley/hg) was just remove that whole
debug signal handler thing. If tcc segfaults itself, I can run it under gdb
or something to see what the heck happened. This is exactly the kind of
host-specific knowledge that I really don't think a compiler should have.
A compiler really isn't special, it's just a program for converting input
files into output files. So is a png->gif converter. This whole "host vs
target" thing just doesn't come _up_ with a png->gif converter, and if you
stop and think about it why does a compiler care either? You produce
binaries for $TARGET. Whether or not they run on the current machine is
P.S. Yes, I know I've been ignoring my fork for the last 6 weeks because I
don't want to step on Fabrice's toes, nor do I particularly have time to
maintain the thing for anyone but myself. But you know what? I'm going to
ignore the whole issue and putter away as I feel like it. I'm going to make
it work for me, and merge the patches I feel like merging, and if anybody
wants to use my tree (or take patches from my tree and apply them to cvs)
they're welcome to. Personally, find CVS a bit of a pain to work with.
(Oh, and now that I've got a real mercurial web thingy up,
http://landley.net/hg/tinycc has links to produce tarballs at the top of it.)
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Re: [Tinycc-devel] TCC on ARM, Daniel Glöckner, 2006/12/01