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 <[email protected]> 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
> [email protected]
> https://lists.nongnu.org/**mailman/listinfo/tinycc-devel<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
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
