[Lazarus] Single-stepping assembler

[Martin]

On 11/09/2011 08:30, Mark Morgan Lloyd wrote:
> Martin wrote:
>> On 10/09/2011 21:16, Martin wrote:
>>> On 10/09/2011 20:50, Mark Morgan Lloyd wrote:
>>>>
>>>> << TCmdLineDebugger.ReadLn "(gdb) "
>>>> >> TCmdLineDebugger.SendCmdLn "set inferior-tty /dev/pts/2"
>>>
>>> Ok, so we may have 2 issues at and.
>>>
>>> the debugger never returns on
>>>   set inferior-tty /dev/pts/2
>>> which should have been created by the IDE.
>>>
>>> or the IDE never gets the result, because something went wrong with 
>>> creating it => but then it should not have gotten as far as sending 
>>> the above...
>>>
>>> So still the below stacktrace,. shows the IDE waiting for gdb to 
>>> return output. yet it should do processMessages, so the ide should 
>>> be responsive.
>>> Strange
>>>
>>>
>>> anyway:
>>> in options, on the debugger tab (where you select /usr/bin/gdb), is 
>>> a list of setting (in an object inspector like grid)
>>> One of the settings is
>>>    ConsoleTty
>>> it is empty by default.
>>> Put /dev/null in there  and see if it helps.
>>>
>>> Or if you need to see the debugged apps terminal output, then open a 
>>> terminal (xterm, or any other) yourself, type "pty", and it will 
>>> give you something like /dev/pts/<n>  which you can put into that 
>>> setting (so long as you leave that terminal open.
>>>
>>> I wonder why that hangs. Nothing there should have changed...
>>> unless some file/handle stuff in fpc changed? getpt() fcntl() 
>>> tcsetattr() __write()  ....
>>>
>>>
>>>> ^C
>>>> Program received signal SIGINT, Interrupt.
>>>> [Switching to Thread 0xf7f6daa0 (LWP 13397)]
>>>> 0xf7f0f25c in __read_nocancel () from /lib/libpthread.so.0
>>>> (gdb) bt
>>>> #0  0xf7f0f25c in __read_nocancel () from /lib/libpthread.so.0
>>>> #1  0x00ae7450 in TPSEUDOTERMINAL__READ (this=0xf61fe580, result=0x0)
>>>>     at /usr/local/share/lazarus-trunk/debugger/gdbmimiscclasses.pp:539
>>>> #2  0x00ae7570 in TPSEUDOTERMINAL__CHECKCANREAD (this=0xf61fe580)
>>>>     at /usr/local/share/lazarus-trunk/debugger/gdbmimiscclasses.pp:546
>>
>> Argh, no => I overlooked the top 2 frames...
>>
>> I do NOT like them (I do not know yet why not ..)
>>
>> try the /dev/null
>> It should work around
>>
>> At this point there should not be any data to be read.
>> So the question is why on your system is read triggered.
>
> Still locks up I'm afraid.

You are right, sorry, there is a bunch of nested {$IFDEF}... (I must 
have had a bad day when I put that in)

the pseudo console is still accessed, even if you specify another one => 
I am fixing that now.... (next hour)

Still interested to know if the current trunk (error checking) helps.