tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] tcc on x86_64


From: Sergei Trofimovich
Subject: Re: [Tinycc-devel] tcc on x86_64
Date: Sun, 19 Jul 2009 16:11:21 +0300

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

I experienced SIGSEGV when opened/closed file in mc editor (F4/F10).
Current mob branch builds mc master and does not have this disease.
Cool!
fixed.

There is yet some non-fatal glitches. Will investigate and report.

> > 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.
This one disappeared in mob branch.
fixed.

> > 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.
Yes, this error still appears on every binary for me too.
Looks like glibc dislikes the way tcc writes dynamic library dependencies.

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

Looks great!
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.
> 
> http://repo.or.cz/w/tinycc.git?a=commitdiff;h=8cfe2d7ac3237ac77c6e6174878c1e67a86a8155
Great!
fixed.

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

qemu-0.10+ uses libtcg for this (BSDL):
http://git.savannah.gnu.org/cgit/qemu.git/tree/tcg
It has some limitations, but might be useful in tcc to
extend target support.

> Thanks again for the reports!
Thanks for response and for great software!

-- 

  Sergei

Attachment: signature.asc
Description: PGP signature


reply via email to

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