Dmitry Selyutin | 4 Sep 00:30 2015
Picon

Shared libraries: startup and cleanup

Hello guys,

first of all I'd like to thank everyone who takes part in tcc development: it's amazing tool and actually the fastest and smallest compiler I know about! I'm glad that I've found it some years ago and especially glad that it is being developed even now.

The question I have is that I write an open-source project, a big library which provides some Unicode functionality as well as portable filesystem functions and various I/O stuff. I write in C89 with the POSIX standard in mind, but Woe32 is supported as well. The only difficulty I met is that I need to find some analogue for GCC's `__attribute__((constructor))' and `__attribute__((destructor))'. This is the absolutely necessary evil, since I want to get path to current directory right before `main()' is called.

These attributes work under gcc and clang; they also seem to work with pcc, though I prefer to use `_Pragma("init")' and `_Pragma("fini")' instead. I even found the way to achieve the same goal in MSVC. However, tcc seems to ignore `__attribute__', so this approach doesn't help.

A quick search approves my own investigations. It is a pity that tcc lacks this feature; I know it is a non-standard but this is the only reliable way to make an automatic library startup/cleanup without forcing user to call some `weird_lib_init()' and `weird_lib_fini' functions. Is this feature hard to implement? I don't know an assembler, I only heard that this functionality is usually achieved via some kind of `.ctors/.dtors' or `.init_array/.fini_array', where pointers to functions (or their code?) are stored (well, for ELF). But probably there may be a simpler way.

I'd also like to help if this problem can be solved without assembler code. If there is anything I can do I'd like to be useful, so please don't hesitate to ask me! Could you please think about implementing this feature?

Thank you for your help!

<div>
<p dir="ltr">Hello guys,</p>
<p dir="ltr">first of all I'd like to thank everyone who takes part in tcc development: it's amazing tool and actually the fastest and smallest compiler I know about! I'm glad that I've found it some years ago and especially glad that it is being developed even now.</p>
<p dir="ltr">The question I have is that I write an open-source project, a big library which provides some Unicode functionality as well as portable filesystem functions and various I/O stuff. I write in C89 with the POSIX standard in mind, but Woe32 is supported as well. The only difficulty I met is that I need to find some analogue for GCC's `__attribute__((constructor))' and `__attribute__((destructor))'. This is the absolutely necessary evil, since I want to get path to current directory right before `main()' is called.</p>
<p dir="ltr">These attributes work under gcc and clang; they also seem to work with pcc, though I prefer to use `_Pragma("init")' and `_Pragma("fini")' instead. I even found the way to achieve the same goal in MSVC. However, tcc seems to ignore `__attribute__', so this approach doesn't help.</p>
<p dir="ltr">A quick search approves my own investigations. It is a pity that tcc lacks this feature; I know it is a non-standard but this is the only reliable way to make an automatic library startup/cleanup without forcing user to call some `weird_lib_init()' and `weird_lib_fini' functions. Is this feature hard to implement? I don't know an assembler, I only heard that this functionality is usually achieved via some kind of `.ctors/.dtors' or `.init_array/.fini_array', where pointers to functions (or their code?) are stored (well, for ELF). But probably there may be a simpler way.</p>
<p dir="ltr">I'd also like to help if this problem can be solved without assembler code. If there is anything I can do I'd like to be useful, so please don't hesitate to ask me! Could you please think about implementing this feature?</p>
<p dir="ltr">Thank you for your help!</p>
</div>
Jacek Wielemborek | 2 Sep 18:10 2015
Picon

WARNING: TinyCC segmentation faults

Hi,

I ran afl-fuzz against tcc and found an example of a 9-byte file that
crashes the compiler:

root <at> 270aea9e84e5:~/o/crashes# hexdump -C
id\:000000\,sig\:11\,src\:000000\,op\:arith8\,pos\:1\,val\:-6
00000000  6d 5b 69 6e 28 29 7b 7d  0a                       |m[in(){}.|
00000009

There are also other crashes - if anybody is still hacking on TCC, I can
forward you the test cases and/or instruct on how to fuzz the program.

Cheers,
d33tah

Hi,

I ran afl-fuzz against tcc and found an example of a 9-byte file that
crashes the compiler:

root <at> 270aea9e84e5:~/o/crashes# hexdump -C
id\:000000\,sig\:11\,src\:000000\,op\:arith8\,pos\:1\,val\:-6
00000000  6d 5b 69 6e 28 29 7b 7d  0a                       |m[in(){}.|
00000009

There are also other crashes - if anybody is still hacking on TCC, I can
forward you the test cases and/or instruct on how to fuzz the program.

Cheers,
d33tah

Sergey Korshunoff | 30 Aug 03:53 2015
Picon

[RFC] tinycc and rock compiler

Hi all!
I think there is a problem wiith using tcc for compiling a rock parser
sources. Some snippet (NagaQueen.c):

if (!yymatchClass(G, (const unsigned char
*)"\000\000\000\000\000\000\377\003\376\377\377\207\376\377\377\007\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000",
"a-zA-Z0-9_")) goto l920;

l921:;
{  int yypos922= G->pos, yythunkpos922= G->thunkpos;
if (!yymatchClass(G, (const unsigned char
*)"\000\000\000\000\000\000\377\003\376\377\377\207\376\377\377\007\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000",
"a-zA-Z0-9_")) goto l922;

And a test program:

#include <stdio.h>
int main()
{
    const char *const p1 = "1234567890qwertyuiopasdfghjklzxcvbnm";
    const char *const p2 = "1234567890qwertyuiopasdfghjklzxcvbnm";
    if (p1 == p2 )
        printf("OK\n");
    else
        printf("There is a problem\n");
}

A gcc output: OK
A tcc output:  There is a problem

A proposal: introduce a string constant cache in a function scope
level (like this is done for the identifers). Would this help for a
general purpose programs? How often this programming style is used?

PS: this is only a size of the produced exe problem

Alex Rozenman | 19 Aug 16:35 2015
Picon

x86_64 code generate issues

Hello TCC maintainers,

I am compiling the following code (using libtcc, I checked also mob branch):

unsigned int f1() { return *(int*)0x7ffeb7162010ULL; }

I am facing the following issues:
- in the CValue struct, address field is declared as "unsigned int", therefore the address was cut.
- in load(ref, value) function (x86_64-gen.c) "fc" (should denote constant address) is also "int".
- even if my pointer fits in 32 bits the following wrong code is generated:

   0xaaa7bb: mov    0xaaafdc(%rip),%eax        # 0x155579d

This code was generated when my pointer was (0xaaafdc+4).
In general, PC relative indirection looks inappropriate in case of arbitrary const pointer indirection.

Another question - when a next stable version is going to be released? "mob" branch has a lots of good fixes we wanted to use.


<div><div dir="ltr">
<div>Hello TCC maintainers,<br>
</div>
<div><br></div>
<div>I am compiling the following code (using libtcc, I checked also mob branch):</div>
<div><br></div>
<div>unsigned int f1() { return *(int*)0x7ffeb7162010ULL; }</div>
<div><br></div>
<div>I am facing the following issues:</div>
<div>- in the CValue struct, address field is declared as "unsigned int", therefore the address was cut.</div>
<div>- in load(ref, value) function (x86_64-gen.c) "fc" (should denote constant address) is also "int".</div>
<div>- even if my pointer fits in 32 bits the following wrong code is generated:</div>
<div><br></div>
<div>&nbsp; &nbsp;0xaaa7bb:<span class="Apple-tab-span">	</span>mov &nbsp; &nbsp;0xaaafdc(%rip),%eax &nbsp; &nbsp; &nbsp; &nbsp;# 0x155579d</div>
<div><br></div>
<div>This code was generated when my pointer was (0xaaafdc+4).</div>
<div>In general, PC relative indirection looks inappropriate in case of arbitrary const pointer indirection.</div>
<div><br></div>
<div>Another question - when a next stable version is going to be released? "mob" branch has a lots of good fixes we wanted to use.</div>
<div><br></div>
<div class="gmail_signature">Best regards,<br>Alex Rozenman (<a href="mailto:rozenman@..." target="_blank">rozenman@...</a>).<br>
</div>
<div class="gmail_signature"><br></div>
</div></div>
Christian JULLIEN | 30 Jul 14:21 2015
Picon

RE : CYGWIN support, Is __cdecl supported, esp. on linux?

With this diff I'm able to compile tcc and libttc.a ROOTB on Cygwin.
Using tcc fails because it is not able to find crt*.o
Invsetigating why:


diff --git a/lib/bcheck.c b/lib/bcheck.c
index 829e33d..542a9b6 100644
--- a/lib/bcheck.c
+++ b/lib/bcheck.c
<at> <at> -17,6 +17,11 <at> <at>
  * License along with this library; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#if defined(__CYGWIN__)
+#undef __CYGWIN__
+#define __CYGWIN__TCC__
+#endif
+
 #include <stdlib.h>
 #include <stdio.h>
 #include <stdarg.h>
<at> <at> -48,7 +53,8 <at> <at>
 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \
     || defined(__DragonFly__) || defined(__dietlibc__) \
     || defined(__UCLIBC__) || defined(__OpenBSD__) || defined(__NetBSD__) \
-    || defined(_WIN32) || defined(TCC_UCLIBC)
+    || defined(_WIN32) || defined(TCC_UCLIBC) \
+    || defined(__CYGWIN__TCC__)
 #warning Bound checking does not support malloc (etc.) in this environment.
 #undef CONFIG_TCC_MALLOC_HOOKS
 #undef HAVE_MEMALIGN
diff --git a/libtcc.c b/libtcc.c
index df98bb0..4568aa3 100644
--- a/libtcc.c
+++ b/libtcc.c
<at> <at> -1129,6 +1129,9 <at> <at> LIBTCCAPI TCCState *tcc_new(void)
     tcc_define_symbol(s, "__linux__", NULL);
     tcc_define_symbol(s, "__linux", NULL);
 # endif
+# if defined(__CYGWIN__)
+    tcc_define_symbol(s, "__CYGWIN__", NULL);
+# endif
 # if defined(__FreeBSD__)
 #  define str(s) #s
     tcc_define_symbol(s, "__FreeBSD__", str( __FreeBSD__));
diff --git a/tccrun.c b/tccrun.c
index 55db310..0b7ebd1 100644
--- a/tccrun.c
+++ b/tccrun.c
<at> <at> -540,6 +540,8 <at> <at> static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         *paddr = uc->uc_mcontext.mc_rip;
 #elif defined(__NetBSD__)
         *paddr = uc->uc_mcontext.__gregs[_REG_RIP];
+#elif defined(__CYGWIN__)
+        *paddr = uc->uc_mcontext.rip;
 #else
         *paddr = uc->uc_mcontext.gregs[REG_RIP];
 #endif
<at> <at> -551,6 +553,8 <at> <at> static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         fp = uc->uc_mcontext.mc_rbp;
 #elif defined(__NetBSD__)
         fp = uc->uc_mcontext.__gregs[_REG_RBP];
+#elif defined(__CYGWIN__)
+        fp = uc->uc_mcontext.rbp;
 #else
         fp = uc->uc_mcontext.gregs[REG_RBP];
 #endif


----- message d'origine -----
De : "Christian JULLIEN" <eligis-1tsiiZ//OF9QFI55V6+gNQ@public.gmane.org>
date jeu. 30/07/2015 10:22 (GMT +02:00)
À : "tinycc-devel" <tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>
Objet : [Tinycc-devel] CYGWIN support, Is __cdecl supported, esp. on linux?

Hi All,

I'm trying to make tcc compile ROOTB on Cygwin and I already have tcc.exe running with very few patches (see below).
The problem I'm facing is a parse error with __cdecl declarations from cygwin includes.

Even on a standard Linux machine running mod tcc, the following code:
void __cdecl foo(void)
{
}

fails with
jullien <at> sims ~/tinycc $ ./tcc -c foo.c
foo.c:1: error: ';' expected (got "foo")
Am I missing something?

Here is my first diff to support Cygwin, at least on x64.

diff --git a/libtcc.c b/libtcc.c
index df98bb0..4568aa3 100644
--- a/libtcc.c
+++ b/libtcc.c
<at> <at> -1129,6 +1129,9 <at> <at> LIBTCCAPI TCCState *tcc_new(void)
     tcc_define_symbol(s, "__linux__", NULL);
     tcc_define_symbol(s, "__linux", NULL);
 # endif
+# if defined(__CYGWIN__)
+    tcc_define_symbol(s, "__CYGWIN__", NULL);
+# endif
 # if defined(__FreeBSD__)
 #  define str(s) #s
     tcc_define_symbol(s, "__FreeBSD__", str( __FreeBSD__));
diff --git a/tccrun.c b/tccrun.c
index 55db310..0b7ebd1 100644
--- a/tccrun.c
+++ b/tccrun.c
<at> <at> -540,6 +540,8 <at> <at> static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         *paddr = uc->uc_mcontext.mc_rip;
 #elif defined(__NetBSD__)
         *paddr = uc->uc_mcontext.__gregs[_REG_RIP];
+#elif defined(__CYGWIN__)
+        *paddr = uc->uc_mcontext.rip;
 #else
         *paddr = uc->uc_mcontext.gregs[REG_RIP];
 #endif
<at> <at> -551,6 +553,8 <at> <at> static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         fp = uc->uc_mcontext.mc_rbp;
 #elif defined(__NetBSD__)
         fp = uc->uc_mcontext.__gregs[_REG_RBP];
+#elif defined(__CYGWIN__)
+        fp = uc->uc_mcontext.rbp;
 #else
         fp = uc->uc_mcontext.gregs[REG_RBP];
 #endif




_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

<div>
<div>With this diff I'm able to compile tcc and libttc.a ROOTB on Cygwin.</div>
<div>Using tcc fails because it is not able to find crt*.o</div>
<div>Invsetigating why:</div>
<div><br></div>
<div><br></div>
<div>diff --git a/lib/bcheck.c b/lib/bcheck.c<br>index 829e33d..542a9b6 100644<br>--- a/lib/bcheck.c<br>+++ b/lib/bcheck.c<br> <at>  <at>  -17,6 +17,11  <at>  <at> <br>&nbsp; * License along with this library; if not, write to the Free Software<br>&nbsp; * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA&nbsp; 02111-1307&nbsp; USA<br>&nbsp; */<br>+#if defined(__CYGWIN__)<br>+#undef __CYGWIN__<br>+#define __CYGWIN__TCC__<br>+#endif<br>+<br>&nbsp;#include &lt;stdlib.h&gt;<br>&nbsp;#include &lt;stdio.h&gt;<br>&nbsp;#include &lt;stdarg.h&gt;<br> <at>  <at>  -48,7 +53,8  <at>  <at> <br>&nbsp;#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \<br>&nbsp;&nbsp;&nbsp;&nbsp; || defined(__DragonFly__) || defined(__dietlibc__) \<br>&nbsp;&nbsp;&nbsp;&nbsp; || defined(__UCLIBC__) || defined(__OpenBSD__) || defined(__NetBSD__) \<br>-&nbsp;&nbsp;&nbsp; || defined(_WIN32) || defined(TCC_UCLIBC)<br>+&nbsp;&nbsp;&nbsp; || defined(_WIN32) || defined(TCC_UCLIBC) \<br>+&nbsp;&nbsp;&nbsp; || defined(__CYGWIN__TCC__)<br>&nbsp;#warning Bound checking does not support malloc (etc.) in this environment.<br>&nbsp;#undef CONFIG_TCC_MALLOC_HOOKS<br>&nbsp;#undef HAVE_MEMALIGN<br>diff --git a/libtcc.c b/libtcc.c<br>index df98bb0..4568aa3 100644<br>--- a/libtcc.c<br>+++ b/libtcc.c<br> <at>  <at>  -1129,6 +1129,9  <at>  <at>  LIBTCCAPI TCCState *tcc_new(void)<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__linux__", NULL);<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__linux", NULL);<br>&nbsp;# endif<br>+# if defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__CYGWIN__", NULL);<br>+# endif<br>&nbsp;# if defined(__FreeBSD__)<br>&nbsp;#&nbsp; define str(s) #s<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__FreeBSD__", str( __FreeBSD__));<br>diff --git a/tccrun.c b/tccrun.c<br>index 55db310..0b7ebd1 100644<br>--- a/tccrun.c<br>+++ b/tccrun.c<br> <at>  <at>  -540,6 +540,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.mc_rip;<br>&nbsp;#elif defined(__NetBSD__)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.__gregs[_REG_RIP];<br>+#elif defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.rip;<br>&nbsp;#else<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.gregs[REG_RIP];<br>&nbsp;#endif<br> <at>  <at>  -551,6 +553,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.mc_rbp;<br>&nbsp;#elif defined(__NetBSD__)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.__gregs[_REG_RBP];<br>+#elif defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.rbp;<br>&nbsp;#else<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.gregs[REG_RBP];<br>&nbsp;#endif<br><br><br>
</div>
<blockquote>----- message d'origine -----<br>De : <span dir="ltr">"Christian JULLIEN"</span> <span dir="lrt">&lt;eligis@...&gt;</span><br>date jeu. 30/07/2015 10:22 (GMT +02:00)<br>&Agrave; : <span dir="ltr">"tinycc-devel"</span> <span dir="lrt">&lt;tinycc-devel@...&gt;</span><br>Objet : [Tinycc-devel] CYGWIN support, Is __cdecl supported, esp. on linux?<br><br><div>Hi All,</div>
<div><br></div>
<div>I'm trying to make tcc compile ROOTB on Cygwin and I already have tcc.exe running with very few patches (see below).</div>
<div>The problem I'm facing is a parse error with __cdecl declarations from cygwin includes.</div>
<div><br></div>
<div>Even on a standard Linux machine running mod tcc, the following code:</div>
<div>void __cdecl foo(void)<br>{<br>}</div>
<div><br></div>
<div>fails with <br>
</div>
<div>jullien <at> sims ~/tinycc $ ./tcc -c foo.c<br>foo.c:1: error: ';' expected (got "foo")<br>
</div>
<div>Am I missing something?</div>
<div><br></div>
<div>Here is my first diff to support Cygwin, at least on x64.</div>
<div><br></div>
<div>diff --git a/libtcc.c b/libtcc.c<br>index df98bb0..4568aa3 100644<br>--- a/libtcc.c<br>+++ b/libtcc.c<br> <at>  <at>  -1129,6 +1129,9  <at>  <at>  LIBTCCAPI TCCState *tcc_new(void)<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__linux__", NULL);<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__linux", NULL);<br>&nbsp;# endif<br>+# if defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__CYGWIN__", NULL);<br>+# endif<br>&nbsp;# if defined(__FreeBSD__)<br>&nbsp;#&nbsp; define str(s) #s<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__FreeBSD__", str( __FreeBSD__));<br>diff --git a/tccrun.c b/tccrun.c<br>index 55db310..0b7ebd1 100644<br>--- a/tccrun.c<br>+++ b/tccrun.c<br> <at>  <at>  -540,6 +540,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.mc_rip;<br>&nbsp;#elif defined(__NetBSD__)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.__gregs[_REG_RIP];<br>+#elif defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.rip;<br>&nbsp;#else<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.gregs[REG_RIP];<br>&nbsp;#endif<br> <at>  <at>  -551,6 +553,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.mc_rbp;<br>&nbsp;#elif defined(__NetBSD__)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.__gregs[_REG_RBP];<br>+#elif defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.rbp;<br>&nbsp;#else<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.gregs[REG_RBP];<br>&nbsp;#endif</div>
<div><br></div>
<br><br><br>_______________________________________________<br>Tinycc-devel mailing list<br>Tinycc-devel@...<br>https://lists.nongnu.org/mailman/listinfo/tinycc-devel<br><br>
</blockquote>
</div>
Christian JULLIEN | 30 Jul 10:22 2015
Picon

CYGWIN support, Is __cdecl supported, esp. on linux?

Hi All,

I'm trying to make tcc compile ROOTB on Cygwin and I already have tcc.exe running with very few patches (see below).
The problem I'm facing is a parse error with __cdecl declarations from cygwin includes.

Even on a standard Linux machine running mod tcc, the following code:
void __cdecl foo(void)
{
}

fails with
jullien <at> sims ~/tinycc $ ./tcc -c foo.c
foo.c:1: error: ';' expected (got "foo")
Am I missing something?

Here is my first diff to support Cygwin, at least on x64.

diff --git a/libtcc.c b/libtcc.c
index df98bb0..4568aa3 100644
--- a/libtcc.c
+++ b/libtcc.c
<at> <at> -1129,6 +1129,9 <at> <at> LIBTCCAPI TCCState *tcc_new(void)
     tcc_define_symbol(s, "__linux__", NULL);
     tcc_define_symbol(s, "__linux", NULL);
 # endif
+# if defined(__CYGWIN__)
+    tcc_define_symbol(s, "__CYGWIN__", NULL);
+# endif
 # if defined(__FreeBSD__)
 #  define str(s) #s
     tcc_define_symbol(s, "__FreeBSD__", str( __FreeBSD__));
diff --git a/tccrun.c b/tccrun.c
index 55db310..0b7ebd1 100644
--- a/tccrun.c
+++ b/tccrun.c
<at> <at> -540,6 +540,8 <at> <at> static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         *paddr = uc->uc_mcontext.mc_rip;
 #elif defined(__NetBSD__)
         *paddr = uc->uc_mcontext.__gregs[_REG_RIP];
+#elif defined(__CYGWIN__)
+        *paddr = uc->uc_mcontext.rip;
 #else
         *paddr = uc->uc_mcontext.gregs[REG_RIP];
 #endif
<at> <at> -551,6 +553,8 <at> <at> static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         fp = uc->uc_mcontext.mc_rbp;
 #elif defined(__NetBSD__)
         fp = uc->uc_mcontext.__gregs[_REG_RBP];
+#elif defined(__CYGWIN__)
+        fp = uc->uc_mcontext.rbp;
 #else
         fp = uc->uc_mcontext.gregs[REG_RBP];
 #endif

<div>
<div>Hi All,</div>
<div><br></div>
<div>I'm trying to make tcc compile ROOTB on Cygwin and I already have tcc.exe running with very few patches (see below).</div>
<div>The problem I'm facing is a parse error with __cdecl declarations from cygwin includes.</div>
<div><br></div>
<div>Even on a standard Linux machine running mod tcc, the following code:</div>
<div>void __cdecl foo(void)<br>{<br>}</div>
<div><br></div>
<div>fails with <br>
</div>
<div>jullien <at> sims ~/tinycc $ ./tcc -c foo.c<br>foo.c:1: error: ';' expected (got "foo")<br>
</div>
<div>Am I missing something?</div>
<div><br></div>
<div>Here is my first diff to support Cygwin, at least on x64.</div>
<div><br></div>
<div>diff --git a/libtcc.c b/libtcc.c<br>index df98bb0..4568aa3 100644<br>--- a/libtcc.c<br>+++ b/libtcc.c<br> <at>  <at>  -1129,6 +1129,9  <at>  <at>  LIBTCCAPI TCCState *tcc_new(void)<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__linux__", NULL);<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__linux", NULL);<br>&nbsp;# endif<br>+# if defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__CYGWIN__", NULL);<br>+# endif<br>&nbsp;# if defined(__FreeBSD__)<br>&nbsp;#&nbsp; define str(s) #s<br>&nbsp;&nbsp;&nbsp;&nbsp; tcc_define_symbol(s, "__FreeBSD__", str( __FreeBSD__));<br>diff --git a/tccrun.c b/tccrun.c<br>index 55db310..0b7ebd1 100644<br>--- a/tccrun.c<br>+++ b/tccrun.c<br> <at>  <at>  -540,6 +540,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.mc_rip;<br>&nbsp;#elif defined(__NetBSD__)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.__gregs[_REG_RIP];<br>+#elif defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.rip;<br>&nbsp;#else<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *paddr = uc-&gt;uc_mcontext.gregs[REG_RIP];<br>&nbsp;#endif<br> <at>  <at>  -551,6 +553,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.mc_rbp;<br>&nbsp;#elif defined(__NetBSD__)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.__gregs[_REG_RBP];<br>+#elif defined(__CYGWIN__)<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.rbp;<br>&nbsp;#else<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fp = uc-&gt;uc_mcontext.gregs[REG_RBP];<br>&nbsp;#endif</div>
<div><br></div>
</div>
Michael Matz | 29 Jul 14:50 2015
Picon

Source vandalism

Hello gus or Augustin,

while I appreciate more people working on tinycc, why do you think the 
best thing to do as the very first commits would be source code 
reformattings and reorganizations?  Look at what damage you've done:

 <at>  <at>  -204,7 +204,7  <at>  <at>  void C67_g(int c)
 #endif
     ind1 = ind + 4;
     if (ind1 > (int) cur_text_section->data_allocated)
-       section_realloc(cur_text_section, ind1);
+    section_realloc(cur_text_section, ind1);

Grand, so now the conditioned statement isn't indended anymore.  Or:

     while (t) {
-       ptr = (int *) (cur_text_section->data + t);
-       {
-           Sym *sym;
+    ptr = (int *) (cur_text_section->data + t);
+    {
+        Sym *sym;

The 'ptr =' assignment has to be indended.  Or:

                 } else {
-                   qrel->r_info = ELFW(R_INFO)(0, R_X86_64_RELATIVE);
-                   qrel->r_addend = *(long long *)ptr + val;
+            qrel->r_info = ELFW(R_INFO)(0, R_X86_64_RELATIVE);
+            qrel->r_addend = *(long long *)ptr + val;
                     qrel++;
                 }

What the hell?  Parts of the conditional block are now indended completely 
wrong.  Or such changes:

-#define RC_INT     0x0001 /* generic integer register */
-#define RC_FLOAT   0x0002 /* generic float register */
-#define RC_R0      0x0004
-#define RC_R1      0x0008
-#define RC_R2      0x0010
-#define RC_R3      0x0020
-#define RC_R12     0x0040
-#define RC_F0      0x0080
-#define RC_F1      0x0100
-#define RC_F2      0x0200
-#define RC_F3      0x0400
+#define RC_INT 0x0001   /* generic integer register */
+#define RC_FLOAT 0x0002 /* generic float register */
+#define RC_R0 0x0004
+#define RC_R1 0x0008
+#define RC_R2 0x0010
+#define RC_R3 0x0020
+#define RC_R12 0x0040
+#define RC_F0 0x0080
+#define RC_F1 0x0100
+#define RC_F2 0x0200
+#define RC_F3 0x0400

Well, obviously the author of this wanted to align the numbers like in a 
table, now it looks ugly.  Or this:

 static unsigned long put_got_entry(TCCState *s1,
-                                  int reloc_type, unsigned long size, int info,
-                                  int sym_index)
+                   int reloc_type, unsigned long size, int info,
+                   int sym_index)
 {

The arguments on second and third line were meant to align with the first 
argument.  Or just a few lines down:

     if (need_plt_entry && !s1->plt) {
-       /* add PLT */
-       s1->plt = new_section(s1, ".plt", SHT_PROGBITS,
-                             SHF_ALLOC | SHF_EXECINSTR);
-       s1->plt->sh_entsize = 4;
+    /* add PLT */
+    s1->plt = new_section(s1, ".plt", SHT_PROGBITS,
+                  SHF_ALLOC | SHF_EXECINSTR);
+    s1->plt->sh_entsize = 4;
     }

Gnah!  First the whole conditional statements aren't indended anymore, and 
second the arguments to the new_section call aren't aligned.

This is all quite obvious and terrible, and I could go on and on just 
citing from the diffs.  Have you even _looked_ at your patches before 
committing them?  Fix all of this right away, otherwise we have to revert 
the whole series.

Also there's another argument against generally doing such code 
reformattings: git blame is disturbed now, all lines that you've 
reindended now show your commit as the one to blame, which is useless 
information.  Unfortunately that's a damage that can't be undone now 
anymore.

Next time you want to do whole-sale code changes please discuss on the 
mailing list before doing so, there might be reasons for the status quo 
that you're unaware of, like in this case.

Sigh.

Ciao,
Michael.
P.S: some of the reindendation changes look like as if you've replaced 
leading tabs with four spaces.  That would have been wrong, tabs are eight 
spaces.  If this is the case, fix your editor settings.

Christian JULLIEN | 28 Jul 06:58 2015
Picon

RE :Re: RE : [RFC] Moving source code to "src"

Ouch!
You're fast, maybe too fast.
I've no responsibility on tcc project. If I think moving code to src is a good idea, it is my personal opinion. Official maintainers may have a different opinion or want to choose different code organization.

Anyway, here is what I can already say (from my RPi)
- it compiles well if you run make from src directory. I prefer a toplevel Makefile having different tagets calling make on different subdirectories.
- related to previous point, you can't run 'make test' which fails
- have you modified build-tcc.bat for Windows ?

C.

----- message d'origine -----
De : "gus knight" <waddlesplash-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
date lun. 27/07/2015 22:11 (GMT +02:00)
À : "tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org" <tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>
Objet : Re: [Tinycc-devel] RE : [RFC] Moving source code to "src"

On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN <eligis-1tsiiZ//OF9QFI55V6+gNQ@public.gmane.org> wrote:
> Hi Gus,
>
> This is a good idea. If you do so, I also suggest an arch directory that
> contains subdirectories for all supported archives

I wound up going with one dir per arch rather than an "arch"
directory. Let me know if there are any regressions.

-gus

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
<div>
<div>Ouch!</div>
<div>You're fast, maybe too fast.</div>
<div>I've no responsibility on tcc project. If I think moving code to src is a good idea, it is my personal opinion. Official maintainers may have a different opinion or want to choose different code organization.</div>
<div><br></div>
<div>Anyway, here is what I can already say (from my RPi)</div>
<div>- it compiles well if you run make from src directory. I prefer a toplevel Makefile having different tagets calling make on different subdirectories.</div>
<div>- related to previous point, you can't run 'make test' which fails<br>- have you modified build-tcc.bat for Windows ?</div>
<div><br></div>
<div>C.<br><br>
</div>
<blockquote>----- message d'origine -----<br>De : <span dir="ltr">"gus knight"</span> <span dir="lrt">&lt;waddlesplash@...&gt;</span><br>date lun. 27/07/2015 22:11 (GMT +02:00)<br>&Agrave; : <span dir="ltr">"tinycc-devel@..."</span> <span dir="lrt">&lt;tinycc-devel@...&gt;</span><br>Objet : Re: [Tinycc-devel] RE : [RFC] Moving source code to "src"<br><br>On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN &lt;eligis@...&gt; wrote:<br>&gt; Hi Gus,<br>&gt;<br>&gt; This is a good idea. If you do so, I also suggest an arch directory that<br>&gt; contains subdirectories for all supported archives<br><br>I wound up going with one dir per arch rather than an "arch"<br>directory. Let me know if there are any regressions.<br><br>-gus<br><br>_______________________________________________<br>Tinycc-devel mailing list<br>Tinycc-devel@...<br>https://lists.nongnu.org/mailman/listinfo/tinycc-devel<br>
</blockquote>
</div>
Christian JULLIEN | 27 Jul 18:48 2015
Picon

RE : [RFC] Moving source code to "src"

Hi Gus,

This is a good idea. If you do so, I also suggest an arch directory that contains subdirectories for all supported archives

arch/arm
arch/arm64
arch/i386
...

I'm afraid this code refactory will take long until it works on all platforms (including Windows).

Talking about Windows, who has a good Makefile producing standalone tcc for x86/x64 using recent Cygwin toolchain (and no more using Cygwin after it has been compiled).
My dream would be a unique tcc.exe having -m32/-m64 option.

----- message d'origine -----
De : "gus knight" <waddlesplash-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
date lun. 27/07/2015 18:25 (GMT +02:00)
À : "TinyCC ML" <tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>
Objet : [Tinycc-devel] [RFC] Moving source code to "src"

Hi,

ATM the root directory of TinyCC is a bit cluttered, mostly because
the core of TinyCC's code is there. I propose moving it to a "src"
subdirectory.

-gus

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
<div>
<div>Hi Gus,</div>
<div><br></div>
<div>This is a good idea. If you do so, I also suggest an arch directory that contains subdirectories for all supported archives</div>
<div><br></div>
<div>arch/arm</div>
<div>arch/arm64</div>
<div>arch/i386</div>
<div>...</div>
<div><br></div>
<div>I'm afraid this code refactory will take long until it works on all platforms (including Windows).</div>
<div><br></div>
<div>Talking about Windows, who has a good Makefile producing standalone tcc for x86/x64 using recent Cygwin toolchain (and no more using Cygwin after it has been compiled).</div>
<div>My dream would be a unique tcc.exe having -m32/-m64 option.<br><br>
</div>
<blockquote>----- message d'origine -----<br>De : <span dir="ltr">"gus knight"</span> <span dir="lrt">&lt;waddlesplash@...&gt;</span><br>date lun. 27/07/2015 18:25 (GMT +02:00)<br>&Agrave; : <span dir="ltr">"TinyCC ML"</span> <span dir="lrt">&lt;tinycc-devel@...&gt;</span><br>Objet : [Tinycc-devel] [RFC] Moving source code to "src"<br><br>Hi,<br><br>ATM the root directory of TinyCC is a bit cluttered, mostly because<br>the core of TinyCC's code is there. I propose moving it to a "src"<br>subdirectory.<br><br>-gus<br><br>_______________________________________________<br>Tinycc-devel mailing list<br>Tinycc-devel@...<br>https://lists.nongnu.org/mailman/listinfo/tinycc-devel<br>
</blockquote>
</div>
gus knight | 27 Jul 18:24 2015
Picon

[RFC] Moving source code to "src"

Hi,

ATM the root directory of TinyCC is a bit cluttered, mostly because
the core of TinyCC's code is there. I propose moving it to a "src"
subdirectory.

-gus

David Mertens | 27 Jul 17:37 2015
Picon

When does a CType's ref contain a valid pointer?

Hello everyone,

While working on symbol table copying, I have run into trouble copying type.ref pointers that point to garbage. Suppose we have a type struct called "type_to_check". Then I thought the following check would ensure that the .ref field was valid:

int btype = type_to_check->type.t & VT_BTYPE;
if (btype == VT_PTR || btype == VT_STRUCT || btype == VT_FUNC) {
  /* type_to_check.ref is a valid pointer */
}

Yet I seem to run into trouble. Does this look correct?

David

--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
<div><div dir="ltr">
<div>
<div>
<div>Hello everyone,<br><br>
</div>While working on symbol table copying, I have run into trouble copying type.ref pointers that point to garbage. Suppose we have a type struct called "type_to_check". Then I thought the following check would ensure that the .ref field was valid:<br>
</div>
<br>int btype = type_to_check-&gt;type.t &amp; VT_BTYPE;<br>if (btype == VT_PTR || btype == VT_STRUCT || btype == VT_FUNC) {<br>
</div>&nbsp; /* type_to_check.ref is a valid pointer */<br><div>}<br><br>
</div>
<div>Yet I seem to run into trouble. Does this look correct?<br><br>
</div>
<div>David<br clear="all">
</div>
<div><div><div><div>
<br>-- <br><div class="gmail_signature">&nbsp;"Debugging is twice as hard as writing the code in the first place.<br>
 &nbsp; Therefore, if you write the code as cleverly as possible, you are,<br>
 &nbsp; by definition, not smart enough to debug it." -- Brian Kernighan<br>
</div>
</div></div></div></div>
</div></div>

Gmane