[Lazarus] Single-stepping assembler

Mark Morgan Lloyd markMLl.lazarus at telemetry.co.uk
Sun Sep 11 15:06:44 CEST 2011


Martin wrote:
> 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.

I was on r32275. OK on x86 and PPC (Linux), bad on SPARC. Currently 
compiling for ARM to see if it has the same effect, if so it implicates 
alignment.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]




More information about the Lazarus mailing list