Re: [Tinycc-devel] tcc 0.9.26 on win32 cannot compile Sqlite3 successfully

[Tiago Rodrigues]

Great news about the "mob" branch, I'll be sure to check it out.

For me, GDB 6.3 debugs software compiled using TCC 0.9.25 and shows the stack just fine, but the software compiled using 0.9.26 isn't able to load the symbols and shows this kind of backtrace.  I guess a debugger could crawl through the code following jumps to find all targets for CALL instructions, although I'm not sure if any one actually does that.  I do have access to a copy of Visual Studio with a very good debugger, but which unfortunately doesn't support STABS at all and which is thus useless to debug tcc-compiled executables.

Who knows, maybe I can start looking into how debugging works and eventually create a tdb companion to tcc...  I'm sure my current skills aren't up to the task, but it's a good hobby.

Thanks for the attention,

          -Tiago

On Wed, Aug 28, 2013 at 10:56 AM, grischka <address@hidden> wrote:

Tiago Rodrigues wrote:

Hello, all,

I'm having a small difficulty using tcc 0.9.26 to compile SQLite3 (both in Windows XP and 7), as the resulting executable crashes when I try to call the int sqlite3_initialize(void) function.

I am able to find the problem in a minute with a real debugger
(ollydbg here) but I have no idea how to do it with gdb.

What I get is:

(gdb) r
Starting program: C:\tcc\win32\test.exe
[New thread 3988.0x122c]

Program received signal SIGSEGV, Segmentation fault.
0x0049e88c in ?? ()
(gdb) bt
#0  0x0049e88c in ?? ()
#1  0x0049e250 in ?? ()
#2  0x0049e93c in ?? ()
#3  0x00000000 in ?? ()
(gdb)

Unfortunately that's not even close to enough info about the stack
contents in order to spot the offending function.  In the other
debugger I see:

0012FF38   0049E250  test.0049E250
0012FF3C   0049E93C  test.0049E93C
0012FF40   00000000
0012FF44  /0012FF58
0012FF48  |00497AB8  RETURN to test.00497AB8 from test.004058B0
0012FF4C  |002920E0  ASCII ""C:\tcc\win32\test.exe""
0012FF50  |0012FF58
0012FF54  |75F034F6  RETURN to msvcrt.75F034F6 from msvcrt.75F03526
0012FF58  ]0012FF60
0012FF5C  |0040100F  RETURN to test.0040100F from test.00497A91
0012FF60  ]0012FFA0
0012FF64  |0049CF8F  RETURN to test.0049CF8F from test.00401000
0012FF68  |00000001
...

so there is actually much more down the stack that gdb does not show,
specifically that the last known good address within the program is at
    00497AB8  RETURN to test.00497AB8 from test.004058B0
I can then single step through the function at 004058B0 to see what
happens.

But how do you find this in gdb?  Or is it that free software is
stuck with a tool that is not practically useful?

--- grischka

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--
In those days, in those distant days, in those nights, in those remote nights, in those years, in those distant years...
          - Gilgamesh, Enkidu and the Underworld