Re: [Tinycc-devel] tcc on x86_64

[shinichiro . h]

Hi, thanks for the bug reports!

> I tried to play with it and have managed to build master branch of 
> http://midnight-commander.org/
> by tcc on amd64. I grabbed tcc from git://repo.or.cz/tinycc.git
> 
> 1.
> mc compiled and even runs but fails on certain user's operations. I suspect 
> it's a tcc's miscompilation.

One bug I've seen with midnight-commander happened after I ran some
shell commands. This bug has already been fixed by grischka (thanks!).

http://repo.or.cz/w/tinycc.git?a=commitdiff;h=bb5e0df79acbe7fa36d0ff14485657b94cc5cd5f

Could you check midnight-commander still fails using the latest
mob-branch? I don't know about midnight-commander well. If you still
see some bugs, please tell us how to reproduce the failure.

> In order to debug it i tried valgrind, but even hello_world tcc's produced 
> binaries are
> unvalgrindable on my gcc/glibc:
> $ cat > hello.c<<EOF
> ....> int main() { printf("hello!\n"); return 0; }
> ....> EOF
> $ tcc ./hello.c -o hi
> $ valgrind ./hi
> --12247-- WARNING: Serious error when reading debug info
> --12247-- When reading debug info from /tmp/hi:
> --12247-- Last block truncated in .debug_info; ignoring

Though I didn't see this error message with my valgrind-3.3.1, I've
noticed that x86_64's debug info was broken by a bug I introduced.
I think I could fix the bug by

http://repo.or.cz/w/tinycc.git?a=commitdiff;h=d347b2cff32e4546beb34ea15162a6a8fc7f457f

Please let me know the version of valgrind if you still see this
message and I'll investigate it.

> Inconsistency detected by ld.so: rtld.c: 1243: dl_main: Assertion 
> `_rtld_local._dl_rtld_map.l_libname' failed!
> Glibc screwed. Where is an error? glibc being too restrictive? tcc generating 
> bad elf64? valgrind misloading
> nonstandard elf?

Even after my fix, this error still alives. I'll investigate more when
I have time.

> 2.
> During compilation I've noticed some evil warnings:
> tccgen.c:4091: warning: cast to pointer from integer of different size
> tccgen.c:4114: warning: cast to pointer from integer of different size
> 
> They frightened me as 'long' is 64bit on gcc and 'int' is 32bit.
> Are those generated jumps incorrect or tcc emits 32bit wide addresses?

Again, grischka introduced s->jnext as long. So this should be fixed.

http://repo.or.cz/w/tinycc.git?a=commitdiff;h=035918ef2f33c4d9f1312dab3fde6f08b80a3766

> 3.
> ./include/stddef.h:typedef __SIZE_TYPE__ size_t;
> ./libtcc.c:    tcc_define_symbol(s, "__SIZE_TYPE__", "unsigned int");
> ./libtcc.c:    tcc_define_symbol(s, "__PTRDIFF_TYPE__", "int");
> Is it ok? I expected 'unsigned long' and 'long' here on X86_64.

I think it's not OK. I've pushed a patch into mob branch.

http://repo.or.cz/w/tinycc.git?a=commitdiff;h=8cfe2d7ac3237ac77c6e6174878c1e67a86a8155

> 4.
> $ cat f.c
> int f() { return 3; }
> $ tcc -c f.c -o f.o
> $ objdump -d f.o
> 
> f.o:     file format elf64-x86-64
> 
> Disassembly of section .text:
> 
> 0000000000000000 <f>:
>    0:   55                      push   %rbp
>    1:   48 89 e5                mov    %rsp,%rbp
>    4:   48 81 ec 00 00 00 00    sub    $0x0,%rsp
>    b:   b8 03 00 00 00          mov    $0x3,%eax
>   10:   e9 00 00 00 00          jmpq   15 <f+0x15>
>   15:   c9                      leaveq 
>   16:   c3                      retq 
> 
> I understand, tcc isn't intended to generate efficient code, but:
> 
> * -fomit-frame-pointer would be cool to have (it should be easy to implement)
> * 'sub    $0x0,%rsp' could be eliminated as a trivial common case
> * 'jmpq 15' could be eliminated as a trivial common case

As Hanzac mentioned, eliminating them may need another pass. Sometimes
I wonder it would be nice if we support "tiny optimizer" which does
peephole optimizations introducing another pass.

Thanks again for the reports!