[fpc-devel] Re: [Lazarusdev] gdb driving me nuts => it's starting a 2nd thread for no apparent reason....

Marc Weustink marc at dommelstein.net
Tue Nov 9 00:08:07 CET 2010


:)

On windows I create a remote thread to be able to pause execution to 
enable breakpoints and such while the program is running.
See initialisation part of the gdbmi debugger. There I use a few options 
to pause execution. On the NT platform the remote thread solution is the 
most reliable.

Marc



On 8-11-2010 23:59, Martin wrote:
> Ok, anyone with an idea..
>
> Attached is a simple program (appologies for the many commented lines,
> but all logs refer to the lines as in this source, and I didn't want to
> recreate the log yet another time)
> Tested with various versions of gdb dwarf debug info (and IIRc (it's
> been a lot of trying) also stabs). Mainly used todays triunk of fpc, but
> the same with 2.4.0 (again IIRC)
>
> In the log:
> - lines with ">>" written to the debugger
> - lines with "<<" read from the debugger
>
> debugger started with this options:
> gdb -silent -i mi -nx
>
> the app pasically is
> Program Foo;
> procedure Test; begin writeln(); end;
> begin
> Test;
> Test;
> Test;
> end;
>
> - the output of writeln has no significance, and can even be commented away
> - breakpoint is set on the first call to "Test"
>
> then hit F8 (step-over) twice
> - the first F8 stops (but for the wrong reason (should be
> "*stopped,reason="end-stepping-range"..."
> - the 2nd F8 cause a sigill
>
> they apparently stop half into an instruction, which may be part of the
> issue..
>
> The biggest riddle is, why gdb says it's starting a 2nd thread?
> (btw using gdb directly, same options, but piccking only the most
> relevant commands from the log => not reproducible)
>
> Below is the communication of the first "F8 step-over", before that the
> breakpoint was hit, and some info queried (stack, etc).
> All that is send is a single "-exec-next", yet a 2nd thread seems to get
> started.
> Strange too, the address at which it does hit the sig-trap...
>
>  >> TCmdLineDebugger.SendCmdLn "-exec-next"
> << TCmdLineDebugger.ReadLn "^running"
> << TCmdLineDebugger.ReadLn "*running,thread-id="1""
> << TCmdLineDebugger.ReadLn "(gdb) "
> << TCmdLineDebugger.ReadLn "=thread-created,id="2",group-id="1032""
> [Debugger] Notify output: =thread-created,id="2",group-id="1032"
> << TCmdLineDebugger.ReadLn "~"[New Thread 1032.0x1774]\n""
> [Debugger] Console output: ~"[New Thread 1032.0x1774]\n"
> << TCmdLineDebugger.ReadLn "*running,thread-id="all""
> [DBGTGT] *
> [DBGTGT] running,thread-id="all"
> << TCmdLineDebugger.ReadLn "~"[Switching to Thread 1032.0x1774]\n""
> [Debugger] Console output: ~"[Switching to Thread 1032.0x1774]\n"
> << TCmdLineDebugger.ReadLn
> "*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint
> trap",frame={addr="0x
> 771d8b2f",func="??",args=[]},thread-id="2",stopped-threads="all""
> << TCmdLineDebugger.ReadLn "=thread-selected,id="2""
> [Debugger] Notify output: =thread-selected,id="2"
> << TCmdLineDebugger.ReadLn "(gdb) "
>
>
>
> _______________________________________________
> Lazarusdev mailing list
> Lazarusdev at freepascal.org
> http://idefix.wisa.be/mailman/listinfo/lazarusdev




More information about the fpc-devel mailing list