[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] status of x86-64
From: |
shinichiro . h |
Subject: |
Re: [Tinycc-devel] status of x86-64 |
Date: |
Fri, 17 Apr 2009 08:12:35 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.2 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI) |
Hi,
> Two questions to you:
> - The TOK_builtin_malloc/free handlers in tcc.c looked a bit messy.
> I'd like to suggest something different:
> http://repo.or.cz/w/tinycc.git?a=commitdiff;h=76fe1ed5
> Does this what you need?
Yes, definitely. Actually, I considered this way, but I somehow
hesitated to add tokens.
> - Also, I had a version of tcc_relocate() that crams everything into one
> buffer allocated by the caller, such that it can be run independent
> from a TCCState:
> http://repo.or.cz/w/tinycc.git?a=commitdiff;h=495dc312
> Would this would work on x64 instead of your version?
I like this idea. But unfortunately, this needs some fixes for
x86-64. On x86-64, relocation may fail when the distance between
caller and callee is larger than 32bit. In such case, x86-64 TCC
generates PLT and GOT during relocation and it requires extra memory.
Anyway, I'll fix this.
I have two comments on this change.
1. I'm not sure, but you may be able to swap
/* relocate symbols */
relocate_syms(s1, 1);
if (s1->nb_errors)
return -1;
and
if (0 == mem)
return offset + 15;
so that we don't run relocate_syms() twice?
2. How about adding comment which mentions tcc_relocate accepts
(void *)1 as ptr? If you agree and write some comments, please
mention that this won't work on x86-64.
> Also two questions to everyone:
> - I changed some prototypes for libtcc, for tcc_relocate() and two other
> http://repo.or.cz/w/tinycc.git?a=commitdiff;h=4a3907a18
> I know, people might need to update if they use libtcc in their code.
> Does anyone think this is a bad idea (or that the changes are per se)?
As I already wrote, I like the new interface of tcc_relocate(). I
guess changing the usage would be acceptable, but I'm not sure.
> - Also, should we make some subdirs now? I was thinking of
> * include (tcc stdxxx.h)
> * lib (libtcc1.c, bcheck.c, allocaX.S)
> * tests (tcctest etc.)
> It could look cleaner in the distro but less clean in the makefile(s)
> What do you think?
I think this change would be great. Especially adding tests directory
is nice. I wanted to add some tests which exercise combination of TCC
and GCC (e.g., compile by GCC, and link by TCC), but I didn't add
since I didn't want to increase number of files in the tinycc
directory.
Thanks,