[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] tcc on x86_64

From: shinichiro . h
Subject: Re: [Tinycc-devel] tcc on x86_64
Date: Sun, 19 Jul 2009 07:21:55 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj┼Ź) APEL/10.7 Emacs/22.3 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI)

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!).


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


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.


> 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.


> 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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]