Re: [Tinycc-devel] status of x86-64

[shinichiro hamaji]

Hi,

>>> 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.
>
> Hm, does that mean we support programs larger than 2GB? 4GB?

No. Suppose that the program uses printf() from main(). TCC generates
call with 32bit operand. However, on 64bit environments, the distance
between printf() and main() is larger than 32bit usually. For such
cases, current TCC generates jmp with 64bit operand near main() and
make the call point the address of jmp.

>> I've just checked this fix in. This fix includes the fix for order of
>> relocate_syms and return offset. Please revert this change if I'm
>> missing something.
>
> As to relocate_syms runned twice, it is just meant to check symbols
> already in the 1st pass, so the user doesn't have to check the
> return value of tcc_relocate twice.  That's the only reason.

Ah, I understood. I reverted this change, sorry.

> As to "runtime_plt_and_got", well, I don't know much about PLT/GOT
> but it looks like tccpe.c:1129 is doing something similar.  Basically
> it makes an indirect "jmp" and puts a reloc entry on the address
> such that it gets fixed later during normal relocate_section.
>
> It means that the jmp table need to be build BEFORE relocation,
> however isn't that what build_got_entries() is doing already, anyway?
> Couldn't it be used to add the needed entries for TCC_OUTPUT_MEMORY,
> too?  (Maybe I'm just naive)

Yes, you are right. I agree that it is better to generate indirect jmp
code before relocation. I think it takes for a while to fix, but I'll
look into it. I'm not sure if I can utilize build_got_entries. I think
the code generated by build_got_entries requires several fixes (please
grep tcc_elf_output by PLT).

Thanks,