Re: [Tinycc-devel] va_* broken on x86-64: any volonteer? (fwd)
Hi, [resent because my work email is not subscribed here :-/] On Thu, 9 Jan 2014, Thomas Preud'homme wrote: That's because GCC doesn't have any problem. The problem is in TinyCC. I was compiling mksh with TinyCC (I called it tcc in my initial mail) and it gave me linker error about undefined __va_arg if I remember correctly. Are you sure it's not a bug in mksh, and in which version anyway? The stdarg testcases from the testsuite all work just fine. I can also build mksh-R48b with tcc just fine: % uname -a % cd /matz/git/tinycc; git log --online HEAD^.. 767410b Various Makefile fixes for cross-compilation % ./configure; make; make test ... all works ... % cd /tmp/ % tar xvf mksh-R48b.tgz % mkdir mksh/build; cd mksh/build % CC=/matz/git/tinycc/tcc -B/matz/git/tinycc/ /bin/sh ../Build.sh ... Run the regression test suite: ./test.sh Please also read the sample file dot.mkshrc and the fine manual. % ./mksh ./test.sh ... Total failed: 0 Total passed: 466 So, if you want anything fixed we'd first need to know what is broken, e.g. a testcase ;) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] va_* broken on x86-64: any volonteer?
Le jeudi 9 janvier 2014, 14:14:52 Michael Matz a écrit : Hi, On Thu, 9 Jan 2014, Thomas Preud'homme wrote: That's because GCC doesn't have any problem. The problem is in TinyCC. I was compiling mksh with TinyCC (I called it tcc in my initial mail) and it gave me linker error about undefined __va_arg if I remember correctly. Are you sure it's not a bug in mksh, and in which version anyway? The stdarg testcases from the testsuite all work just fine. I can also build mksh-R48b with tcc just fine: % uname -a % cd /matz/git/tinycc; git log --online HEAD^.. 767410b Various Makefile fixes for cross-compilation % ./configure; make; make test ... all works ... % cd /tmp/ % tar xvf mksh-R48b.tgz % mkdir mksh/build; cd mksh/build % CC=/matz/git/tinycc/tcc -B/matz/git/tinycc/ /bin/sh ../Build.sh ... Oh I see. I compiled with --with-libgcc and gcc doesn't provide __va_* like libtcc1 does. So I guess either libgcc should not be proposed for x86-64 systems or libtcc1 should always be linked in as well as to fill in the blank. Or maybe now that arm can uses libtcc1 this option could be just removed. If there is some value in keeping it, it could also be nice that tcc can work directly with libgcc (and thus have va_* macros builtin, see stdarg.h from gcc and gcc's source code). Dear users, does any of you see value in the --with-libgcc switch of configure? Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] va_* broken on x86-64: any volonteer?
Hi, [bah, resent again because of suse.de not being the subscribed address here :-/ ] On Thu, 9 Jan 2014, Thomas Preud'homme wrote: Oh I see. I compiled with --with-libgcc and gcc doesn't provide __va_* like libtcc1 does. So I guess either libgcc should not be proposed for x86-64 systems or libtcc1 should always be linked in as well as to fill in the blank. Yeah. tcc meanwhile also emits references to other symbols that aren't in libgcc. E.g. __floatundixf. Or maybe now that arm can uses libtcc1 this option could be just removed. If there is some value in keeping it, it could also be nice that tcc can work directly with libgcc (and thus have va_* macros builtin, see stdarg.h from gcc and gcc's source code). You can't without providing the implementation currently residing in libtcc directly as inline variant in the code generator (as libgcc doesn't contain any implementation of that stuff). As the x86_64 variant of stdargs is a bit convoluted (as in, more that three/four instructions) that doesn't seem like the best solution. So, ... Dear users, does any of you see value in the --with-libgcc switch of configure? ... if the possibility of using libgcc should be retained, then yes, libtcc needs to be linked in additionally. Which seems to make sense as that lib indeed is supposed to provide the runtime parts that the compiler (here tcc) specifically wants to rely on. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] va_* broken on x86-64: any volonteer?
On Fri, Jan 10, 2014 at 1:13 AM, Michael Matz matz@frakked.de wrote: Hi, [bah, resent again because of suse.de not being the subscribed address here :-/ ] On Thu, 9 Jan 2014, Thomas Preud'homme wrote: Oh I see. I compiled with --with-libgcc and gcc doesn't provide __va_* like libtcc1 does. So I guess either libgcc should not be proposed for x86-64 systems or libtcc1 should always be linked in as well as to fill in the blank. Yeah. tcc meanwhile also emits references to other symbols that aren't in libgcc. E.g. __floatundixf. Or maybe now that arm can uses libtcc1 this option could be just removed. If there is some value in keeping it, it could also be nice that tcc can work directly with libgcc (and thus have va_* macros builtin, see stdarg.h from gcc and gcc's source code). You can't without providing the implementation currently residing in libtcc directly as inline variant in the code generator (as libgcc doesn't contain any implementation of that stuff). As the x86_64 variant of stdargs is a bit convoluted (as in, more that three/four instructions) that doesn't seem like the best solution. So, ... Yeah, I have looked at how GCC handles stdarg for x86-64, but I chose the current way because I didn't want to make TCC unnecessary bigger. Hard-coding va_* would be appropriate for GCC, but might be inappropriate for TinyCC :) BTW, I have just noticed http://repo.or.cz/w/tinycc.git/commitdiff/55ea6d3fc175b0e01e2e946ca9b319c1fbe8aa67?hp=3f1d971eeebe315795079c3adbe4022d6d19. I knew my first implementation did not follow the x86-64 ABI but I was too lazy to implement it correctly. It should have been working for basic types and printf was OK, and everything should have been working if you build everything with TCC, so I stopped fixing this. A big kudos to James! Dear users, does any of you see value in the --with-libgcc switch of configure? ... if the possibility of using libgcc should be retained, then yes, libtcc needs to be linked in additionally. Which seems to make sense as that lib indeed is supposed to provide the runtime parts that the compiler (here tcc) specifically wants to rely on. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Use an anonymous file to back mmap
Hi All, I just submitted a tentative patch to the mob branch about mmap. When selinux is enabled, tccrun.c uses mmap to hold the dynamically generated code/data. It is backed by a randomly named file under /tmp directory. My patch is to use an anonymous file in mmap instead, so that the generated code/data only resides in memory, and tcc does not depend on a writable /tmp anymore. tcc is fantastic! I am new to this community. Your comments are very welcome! http://repo.or.cz/w/tinycc.git/commit/935d8169b8e3570f1a5e726c5295be2f460c1540 Best, Keren Tan ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] fixes in 86_64 PE
Hello everyone!
I've commited a patch for x86_64 PE target to fix fails in code like:
int (*fn1)() = 0x00013fbd16b5;
and code like:
int fn1() {...}
struct {
int (*fn2)();
} b = { fn1 };
p.s. most difficult in this work is git commit - instruction on site repo.or.cz
sucks.
---
Zimbabwe CMS - best c script(tcc) based CMS ever!___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Use an anonymous file to back mmap
Le jeudi 9 janvier 2014, 14:21:59 Keren Tan a écrit : Hi All, I just submitted a tentative patch to the mob branch about mmap. When selinux is enabled, tccrun.c uses mmap to hold the dynamically generated code/data. It is backed by a randomly named file under /tmp directory. My patch is to use an anonymous file in mmap instead, so that the generated code/data only resides in memory, and tcc does not depend on a writable /tmp anymore. tcc is fantastic! I am new to this community. Your comments are very welcome! Here is my comment: you removed the line s1-mem_size = ret; which is used to unmap these memory regions in libtcc.c http://repo.or.cz/w/tinycc.git/commit/935d8169b8e3570f1a5e726c5295be2f460c15 40 Best, Keren Tan Thanks for your patch. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] va_* broken on x86-64: any volonteer?
Le jeudi 9 janvier 2014, 17:13:41 Michael Matz a écrit : Yeah. tcc meanwhile also emits references to other symbols that aren't in libgcc. E.g. __floatundixf. Indeed. Or maybe now that arm can uses libtcc1 this option could be just removed. If there is some value in keeping it, it could also be nice that tcc can work directly with libgcc (and thus have va_* macros builtin, see stdarg.h from gcc and gcc's source code). You can't without providing the implementation currently residing in libtcc directly as inline variant in the code generator (as libgcc doesn't contain any implementation of that stuff). As the x86_64 variant of stdargs is a bit convoluted (as in, more that three/four instructions) that doesn't seem like the best solution. So, ... That's what gcc does but indeed, tcc tries to be smaller and faster than gcc so indeed. Dear users, does any of you see value in the --with-libgcc switch of configure? ... if the possibility of using libgcc should be retained, then yes, libtcc needs to be linked in additionally. Which seems to make sense as that lib indeed is supposed to provide the runtime parts that the compiler (here tcc) specifically wants to rely on. Right, I'm tempted to remove the libgcc switch but I need to look again at the commit that introduced it for the reasons. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] shared libraries with tcc - any ETA?
Hi. I've reported before, that on i386 and x86_64 Linux, tcc produces shared libraries that sometimes can't be used. This is in the context of gawk (GNU Awk). I get errors like this: ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `free' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `free' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation [ ... and many more ] This is the only thing preventing me from switching to tcc for everday development, which is a shame, as it is S O M U C H F A S T E R than gcc is. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
