Ben Hutchinson | 29 Jun 08:52 2016
Picon

Here's a bug that needs to be fixed

Not sure if this is fixed yet in the latest version of TCC (I haven't used TCC since I discovered the bug), but the last version of TCC that I used had this bug. When it writes an EXE file, it leaves 3 of the PE header fields blank. While the resulting EXE file does seem to run properly, the EXE file itself does not meet the official specifications, and therefore is technically an invalid EXE file. The PE header of the EXE file has these 3 fields left being set at 0
SizeOfCode
SizeOfInitializedData
SizeOfUninitializedData

So here's how those 3 header fields are supposed to be filled out:

SizeOfCode should equal the number of bytes of compiled machine code in the EXE file. This should be the size of the .text section of the EXE file. This should never be 0.

SizeOfInitialized data should (if there is a .data section in the EXE file) should equal the number of
bytes of initialized data. This should only be 0 if there is no .data section.

SizeOfUninitializedData data should (if there is a .bss section in the EXE file) should equal the number of bytes of uninitialized data. This should only be 0 if there is no .bss section.


<div><div dir="ltr">
<div>
<div>Not sure if this is fixed yet in the latest version of TCC (I haven't used TCC since I discovered the bug), but the last version of TCC that I used had this bug. When it writes an EXE file, it leaves 3 of the PE header fields blank. While the resulting EXE file does seem to run properly, the EXE file itself does not meet the official specifications, and therefore is technically an invalid EXE file. The PE header of the EXE file has these 3 fields left being set at 0<br>SizeOfCode<br>SizeOfInitializedData<br>SizeOfUninitializedData<br><br>
</div>
<div>So here's how those 3 header fields are supposed to be filled out:<br><br>
</div>SizeOfCode should equal the number of bytes of compiled machine code in the EXE file. This should be the size of the .text section of the EXE file. This should never be 0.<br><br>
</div>SizeOfInitialized data should (if there is a .data section in the EXE file) should equal the number of <br>bytes of initialized data. This should only be 0 if there is no .data section.<br><br>SizeOfUninitializedData data should (if there is a .bss section in the EXE 
file) should equal the number of bytes of uninitialized data. This should only be 0 if there is no .bss section.<br><br><br><div><div>  </div></div>
</div></div>
Brad Elliott | 28 Jun 18:18 2016

TCC and round()

Hi everyone,

 

Has anyone had success getting round() to work in TCC without implementing my own? Version 0.9.26 looks like it added support for C99 and I can see the prototype in math.h but I can’t compile it:

 

     tcc: error: undefined symbol 'round'

 

This is the simple example I was using:

 

    #include <stdio.h>

    #include <math.h>

    #include <stdlib.h>

 

    int main(void)

    {

        printf("%f\n", round(0.1));

        return EXIT_SUCCESS;

    }

 

I don’t see any options to specifically enable C99 like the --std=c99 in GCC.

 

Any ideas?


Thanks,

 

Brad Elliott

<div>
<div class="WordSection1">
<p class="MsoNormal">Hi everyone,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Has anyone had success getting round() to work in TCC without implementing my own? Version 0.9.26 looks like it added support for C99 and I can see the prototype in math.h but I can&rsquo;t compile it:<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp; tcc: error: undefined symbol 'round'<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">This is the simple example I was using:<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; #include &lt;stdio.h&gt;<p></p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; #include &lt;math.h&gt;<p></p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; #include &lt;stdlib.h&gt;<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; int main(void)<p></p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; {<p></p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;printf("%f\n", round(0.1));<p></p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;return EXIT_SUCCESS;<p></p></p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; }<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">I don&rsquo;t see any options to specifically enable C99 like the --std=c99 in GCC.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Any ideas?<p></p></p>
<p class="MsoNormal"><br>
Thanks,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Brad Elliott<p></p></p>
</div>
</div>
Jin Qian | 25 Jun 19:06 2016
Picon

Question on creating a object file from a program in string format


New to TCC but very interested in its small footprint and fast COMPILE speed.  Tried to create a  object file from a short program in string format,  the resulted "dummy.o"  doesn't have any symbols.  Any idea why?

Here is the modified example.   http://pastebin.com/raw/ntx28sgk
I experimented with removing or adding the call "tcc_relocate" but there is no difference.

C:\temp> gcc -I libtcc  -Llib -ltcc1 examples\libtcc_test.c -L. -llibtcc
it produced a program "a.exe".
C:\temp> a
C:\temp> nm dummy.o
nm: dummy.o: no symbols


Thanks!
<div><div>
<div><br></div>
<div>New to TCC but very interested in its small footprint and fast COMPILE speed. &nbsp;Tried to create a &nbsp;object file from a short program in string format, &nbsp;the resulted "dummy.o" &nbsp;doesn't have any symbols. &nbsp;Any idea why?</div>
<div dir="ltr"><br></div>
<div>Here is the modified example. &nbsp;&nbsp;<a href="http://pastebin.com/raw/ntx28sgk">http://pastebin.com/raw/ntx28sgk</a>
</div>
<div dir="ltr">I experimented with removing or adding the call "tcc_relocate" but there is no difference.</div>
<div dir="ltr"><br></div>
<div dir="ltr">C:\temp&gt; gcc -I libtcc &nbsp;-Llib -ltcc1 examples\libtcc_test.c -L. -llibtcc<br>
</div>
<div dir="ltr">it produced a program "a.exe".</div>
<div dir="ltr">C:\temp&gt; a</div>
<div dir="ltr">C:\temp&gt; nm dummy.o</div>
<div dir="ltr">nm: dummy.o: no symbols</div>
<div dir="ltr"><br></div>
<div dir="ltr"><br></div>
<div dir="ltr">Thanks!</div>
</div></div>
Vincent Lefevre | 7 Jun 02:35 2016
Picon

incorrect bit-field behavior

tcc does not follow the integer promotion rules on bit-fields.
For instance, consider the following code:

#include <stdio.h>

union ui
{
  struct
    {
      unsigned int manl:32;
      unsigned int manh:20;
      unsigned int exp:11;
      unsigned int sig:1;
    } s;
  double d;
};

union ul
{
  struct
    {
      unsigned long manl:32;
      unsigned long manh:20;
      unsigned long exp:11;
      unsigned long sig:1;
    } s;
  double d;
};

int main (void)
{
  union ui xi;
  union ul xl;

  xi.d = 0.5;
  xl.d = 0.5;

  printf ("%d %lx\n", xi.s.exp - 1023 < 0, (unsigned long) (xi.s.exp - 1023));
  printf ("%d %lx\n", xl.s.exp - 1023 < 0, (unsigned long) (xl.s.exp - 1023));
  return 0;
}

With GCC and ICC, I get:

1 ffffffffffffffff
1 ffffffffffffffff

But with tcc, I get:

0 ffffffff
0 ffffffffffffffff

Since all the values of xi.s.exp and xl.s.exp are representable
in an int, the bit-field type should be converted to int for the
subtraction, so that the < 0 should be true in both cases.

--

-- 
Vincent Lefèvre <vincent@...> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Steffen Nurpmeso | 2 Jun 20:53 2016
Picon
Gravatar

realpath(x, NULL) doesn't work with tcc(1)

Hi!

Well, have i yet asked this?  I think no...
It's like that for a long time, ever since i use tcc(1) (autumn
last year):

  ?0[steffen <at> wales tmp]$ cat t.c
  #include <stdlib.h>
  int main(void){
     char *x = realpath(".", NULL);

     return (x != NULL) ? 0 : 1;
  }
  ?0[steffen <at> wales tmp]$ for i in clang gcc tcc; do \
    $i -o zt t.c && ./zt; echo $i: $?;\
  done
  clang: 0
  gcc: 0
  tcc: 1

tcc(1) only gets realpath(3) with buffer argument right, i wonder
what that can be?
Ciao!

--steffen

Steffen Nurpmeso | 2 Jun 16:05 2016
Picon
Gravatar

-Wl,-rpath not passed through?

Hello again!

I have just recognized that i need to use -Wl,-rpath now (new
layout for/with optional (hidden) packages in my ~/usr/opt/), so
great that tcc(1) does support this!  (I always wondered why -L
isn't automatically taken over for this purpose, however, since it
is standardized and why should i include something in -L but not
want it to end up as a runtime path?  Especially if something
actually had been found during the link process.  But, well...)

So then, here we go:

  Building..
    $ tcc -Wl,-rpath=/home/steffen/usr/opt/.ssl-1.1.0/lib -Wl,-rpath=/home/steffen/usr/lib
-Wl,-rpath=/home/steffen/usr/opt/tcc-mob/lib -Wl,-rpath=/home/steffen/usr/opt/pcc/lib
-Wl,-rpath=/lib -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/lib   -o s-nail accmacvar.o
attachments.o auxlily.o cmd1.o cmd2.o cmd3.o cmd_cnd.o collect.o colour.o dotlock.o edit.o filter.o
fio.o folder.o head.o imap_search.o lex_input.o list.o mailcap.o maildir.o main.o memory.o
message.o mime.o mime_enc.o mime_param.o mime_parse.o mime_types.o nam_a_grp.o openpgp.o
openssl.o path.o pop3.o popen.o privacy.o quit.o send.o sendout.o signal.o smtp.o socket.o spam.o
ssl.o strings.o termcap.o thread.o tty.o ui_str.o urlcrecry.o wordexp.o
-L/home/steffen/usr/opt/.ssl-1.1.0/lib -L/home/steffen/usr/lib -L/home/steffen/usr/opt/
 tcc-mob/lib -L/home/steffen/usr/opt/pcc/lib -L/lib -L/usr/local/lib -L/usr/lib -lssl -lcrypto
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lcurses
     text    data     bss     dec     hex filename
   882664  136640  112760 1132064  114620 s-nail
  make[1]: Leaving directory '/home/steffen/src/nail.git'
  ?0[steffen <at> wales nail.git]$ l /home/steffen/usr/opt/.ssl-1.1.0/lib
  pkgconfig/  ../  libcrypto.a  libssl.a  libcrypto.so.1.1  libcrypto.so <at>   libssl.so.1.1  libssl.so <at>   ./  engines/
  ?0[steffen <at> wales nail.git]$ readelf -d s-nail                                                                                                          

  Dynamic section at offset 0xf66f8 contains 19 entries:
    Tag        Type                         Name/Value
   0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.1]
   0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.1.1]
Yes!
   [.]
   0x000000000000000f (RPATH)              Library rpath: [/usr/lib]
No!

For gcc(1) we end up as desired:

   0x000000000000000f (RPATH)              Library rpath: [/home/steffen/usr/opt/.ssl-1.1.0/lib:/home/steffen/usr/lib:/home/steffen/usr/opt/tcc-mob/lib:/home/steffen/usr/opt/pcc/lib:/lib:/usr/local/lib:/usr/lib]

This is still true for [mob:1ca685f], but which no longer needs
a cherry-picked commit to do it.  Cool!  :-)
Ciao!

--steffen

Rhagdamaziel | 25 May 16:13 2016

Segfault with struct return value.

Hi, I am a user of the Nim programming language which compile to C, among others.

I use TinyCC for compiling Nim programs in debug mode for its especially fast compilation time.

I recently encountered an issue where I was getting a segfault at some point after I called a function which returned a struct as value.
Note that this issue only appear with TCC, and not with gcc or clang.

I managed to reproduce the issue with this test file. The Nimframe function inside are there to mimic the Nim stackframes.


<div>
    Hi, I am a user of the Nim programming language which compile to C,
    among others.<br><br>
    I use TinyCC for compiling Nim programs in debug mode for its
    especially fast compilation time.<br><br>
    I recently encountered an issue where I was getting a segfault at
    some point after I called a function which returned a struct as
    value. <br>
    Note that this issue only appear with TCC, and not with gcc or
    clang.<br><br>
    I managed to reproduce the issue with this <a href="https://gist.github.com/Parashurama/faac3c179b2efc4733d0583d32a5d026">test
      file</a>. The Nimframe function inside are there to mimic the Nim
    stackframes.<br><br><br>
</div>
Eric Biggers | 22 May 22:09 2016
Picon

[BUG] assertion failure when compiling initialization of array of structs on x86_64

Hello,

When I tried compiling some of my code with tcc, I encountered an assertion
failure, which I have reduced to the following minimal example:

struct S {
        long a;
};

void f(struct S *x)
{
        struct S y[1] = { *x };
}

$ tcc -c bug.c
tcc: x86_64-gen.c:418: load: Assertion `((ft & VT_BTYPE) == VT_INT) || ((ft & VT_BTYPE) == VT_LLONG) ||
((ft & VT_BTYPE) == VT_PTR) || ((ft & VT_BTYPE) == VT_ENUM) || ((ft & VT_BTYPE) == VT_FUNC)' failed.
Aborted (core dumped)

Paul Kienzle | 21 May 07:02 2016
Picon

using tinycc to compile python plugins

Hi,

In order to allow users to compile plugins for our python program, I put together a python package with the compiler and enough logic to tell my program where the compiler lives on disk:


Since this could be useful for other Windows python applications, I would like to upload this to pypi package distribution site.

Is it okay to use the name tinycc for the package?

Suggestions what I might call it instead?

Thanks in advance,

    - Paul

<div><div dir="ltr">Hi,<div><br></div>
<div>In order to allow users to compile plugins for our python program, I put together a python package with the compiler and enough logic to tell my program where the compiler lives on disk:</div>
<div><br></div>
<div>&nbsp; &nbsp; <a href="https://github.com/SasView/tinycc">https://github.com/SasView/tinycc</a><br>
</div>
<div><br></div>
<div>Since this could be useful for other Windows python applications, I would like to upload this to pypi package distribution site.</div>
<div><br></div>
<div>Is it okay to use the name tinycc for the package?</div>
<div><br></div>
<div>Suggestions what I might call it instead?</div>
<div><br></div>
<div>Thanks in advance,</div>
<div><br></div>
<div>&nbsp; &nbsp; - Paul</div>
<div><br></div>
<div><a href="mailto:pkienzle@...">pkienzle@...</a></div>
</div></div>
Chris Marshall | 20 May 14:24 2016
Picon

tcc port to cygwin

Atttached is a first cut port of the TinyCC build to the cygwin platform.

The mains problems seem to be from managing the different include files.
I hand added some defines to libtcc1.c for __INTPTR_TYPE__ and a few
others to get that to build.

However, it is now failing to build bcheck.c with:

 >  ../tcc -B.. -c bcheck.c -o x86_64/bcheck.o -I.. -Wall -g -O0 
-Wdeclaration-after-statement -Wno-deprecated-declarations 
-Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare 
-Wno-unused-result -Wno-uninitialized -fno-strict-aliasing -fPIC 
-DTCC_TARGET_X86_64
 >  In file included from bcheck.c:20:
 >  In file included from /usr/include/stdlib.h:18:
 >  /usr/include/sys/reent.h:196: error: ')' expected (got "*")
 >  Makefile:116: recipe for target 'x86_64/bcheck.o' failed
 >  make[1]: *** [x86_64/bcheck.o] Error 1

Looking at the origin of the error message in the skip() routine
in tccpp.c, I could not find any place that skip() was called with
an argument of ')'.  Is there some other place that message
could be coming from.  Seems like it might be a possible
problem in the preprocessing....

--Chris

From f1ee3de3a4c24157c9927cb3706f4e902ae88710 Mon Sep 17 00:00:00 2001
From: Chris Marshall <devel.chm.01 <at> gmail.com>
Date: Fri, 20 May 2016 08:02:03 -0400
Subject: [PATCH] Basic port to cygwin of mob tcc

The remaining issues appear to be ones relating to include file
problems.  Specifically, the local include/stddef.h and others
seem to be inconsistent with those from the native gcc (as in
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include/stddef.h or others.
---
 conftest.c    | 2 ++
 lib/libtcc1.c | 5 +++++
 libtcc.c      | 3 +++
 tccrun.c      | 8 ++++++++
 4 files changed, 18 insertions(+)

diff --git a/conftest.c b/conftest.c
index fa07a1b..8fe2e01 100644
--- a/conftest.c
+++ b/conftest.c
 <at>  <at>  -18,6 +18,8  <at>  <at> 
 # define TRIPLET_OS "linux"
 #elif defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
 # define TRIPLET_OS "kfreebsd"
+#elif defined (__CYGWIN__)
+# define TRIPLET_OS "cygwin"
 #elif !defined (__GNU__)
 # define TRIPLET_OS "unknown"
 #endif
diff --git a/lib/libtcc1.c b/lib/libtcc1.c
index a5fee7b..05ec15b 100644
--- a/lib/libtcc1.c
+++ b/lib/libtcc1.c
 <at>  <at>  -28,6 +28,11  <at>  <at>  the Free Software Foundation, 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.  
 */

+#define __INTPTR_TYPE__ long int
+#define __INTPTR_MAX__ 9223372036854775807L
+#define __INT32_TYPE__ int
+#define __INT32_MAX__ 2147483647
+
 #include <stdint.h>

 #define W_TYPE_SIZE   32
diff --git a/libtcc.c b/libtcc.c
index b0fcdf9..44caf21 100644
--- a/libtcc.c
+++ b/libtcc.c
 <at>  <at>  -1131,6 +1131,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__)
     tcc_define_symbol(s, "__FreeBSD__", "__FreeBSD__");
 # endif
diff --git a/tccrun.c b/tccrun.c
index 9ee70e4..af539e3 100644
--- a/tccrun.c
+++ b/tccrun.c
 <at>  <at>  -496,6 +496,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         *paddr = uc->uc_mcontext->__ss.__eip;
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__)
         *paddr = uc->uc_mcontext.mc_eip;
+#elif defined(__CYGWIN__)
+        *paddr = uc->uc_mcontext.eip;
 #elif defined(__dietlibc__)
         *paddr = uc->uc_mcontext.eip;
 #elif defined(__NetBSD__)
 <at>  <at>  -509,6 +511,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         fp = uc->uc_mcontext->__ss.__ebp;
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__)
         fp = uc->uc_mcontext.mc_ebp;
+#elif defined(__CYGWIN__)
+        fp = uc->uc_mcontext.ebp;
 #elif defined(__dietlibc__)
         fp = uc->uc_mcontext.ebp;
 #elif defined(__NetBSD__)
 <at>  <at>  -544,6 +548,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>  -555,6 +561,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
-- 
2.5.3

From f1ee3de3a4c24157c9927cb3706f4e902ae88710 Mon Sep 17 00:00:00 2001
From: Chris Marshall <devel.chm.01 <at> gmail.com>
Date: Fri, 20 May 2016 08:02:03 -0400
Subject: [PATCH] Basic port to cygwin of mob tcc

The remaining issues appear to be ones relating to include file
problems.  Specifically, the local include/stddef.h and others
seem to be inconsistent with those from the native gcc (as in
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include/stddef.h or others.
---
 conftest.c    | 2 ++
 lib/libtcc1.c | 5 +++++
 libtcc.c      | 3 +++
 tccrun.c      | 8 ++++++++
 4 files changed, 18 insertions(+)

diff --git a/conftest.c b/conftest.c
index fa07a1b..8fe2e01 100644
--- a/conftest.c
+++ b/conftest.c
 <at>  <at>  -18,6 +18,8  <at>  <at> 
 # define TRIPLET_OS "linux"
 #elif defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
 # define TRIPLET_OS "kfreebsd"
+#elif defined (__CYGWIN__)
+# define TRIPLET_OS "cygwin"
 #elif !defined (__GNU__)
 # define TRIPLET_OS "unknown"
 #endif
diff --git a/lib/libtcc1.c b/lib/libtcc1.c
index a5fee7b..05ec15b 100644
--- a/lib/libtcc1.c
+++ b/lib/libtcc1.c
 <at>  <at>  -28,6 +28,11  <at>  <at>  the Free Software Foundation, 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.  
 */

+#define __INTPTR_TYPE__ long int
+#define __INTPTR_MAX__ 9223372036854775807L
+#define __INT32_TYPE__ int
+#define __INT32_MAX__ 2147483647
+
 #include <stdint.h>

 #define W_TYPE_SIZE   32
diff --git a/libtcc.c b/libtcc.c
index b0fcdf9..44caf21 100644
--- a/libtcc.c
+++ b/libtcc.c
 <at>  <at>  -1131,6 +1131,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__)
     tcc_define_symbol(s, "__FreeBSD__", "__FreeBSD__");
 # endif
diff --git a/tccrun.c b/tccrun.c
index 9ee70e4..af539e3 100644
--- a/tccrun.c
+++ b/tccrun.c
 <at>  <at>  -496,6 +496,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         *paddr = uc->uc_mcontext->__ss.__eip;
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__)
         *paddr = uc->uc_mcontext.mc_eip;
+#elif defined(__CYGWIN__)
+        *paddr = uc->uc_mcontext.eip;
 #elif defined(__dietlibc__)
         *paddr = uc->uc_mcontext.eip;
 #elif defined(__NetBSD__)
 <at>  <at>  -509,6 +511,8  <at>  <at>  static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, int level)
         fp = uc->uc_mcontext->__ss.__ebp;
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__)
         fp = uc->uc_mcontext.mc_ebp;
+#elif defined(__CYGWIN__)
+        fp = uc->uc_mcontext.ebp;
 #elif defined(__dietlibc__)
         fp = uc->uc_mcontext.ebp;
 #elif defined(__NetBSD__)
 <at>  <at>  -544,6 +548,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>  -555,6 +561,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
--

-- 
2.5.3

Chris Marshall | 19 May 16:48 2016
Picon

how to debug include problems with tcc?

I'm working to port the tcc build process to cygwin
and its native posix environment.  tcc.exe seems to
build fine but I'm having include problems with the
compilation of lib/bcheck.c.

Is there any way to see exactly what is generated
in the failing include files with command line switches
or other techniques?


--Chris
<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div></div>I'm working to port the tcc build process to cygwin <br>and its native posix environment.&nbsp; tcc.exe seems to <br>build fine but I'm having include problems with the <br>compilation of lib/bcheck.c.<br><br>
</div>Is there any way to see exactly what is generated <br>
</div>in the failing include files with command line switches <br>
</div>or other techniques?<br><br><br>
</div>
<div>--Chris</div>
</div></div>

Gmane