[Lazarus] Single-stepping assembler

Mark Morgan Lloyd markMLl.lazarus at telemetry.co.uk
Sat Sep 3 16:25:03 CEST 2011


Martin wrote:
> On 03/09/2011 14:26, Mark Morgan Lloyd wrote:
>> Martin wrote:
>>> If it does not work for you, please open the "Debug output" window 
>>> from "view" / "debug windows" and check what command is sent to gdb.
>>
>> I've been looking at this on various platforms. I can't easily test 
>> Windows due to an apparent build problem, but on Linux and Solaris:
> ...
>> ARM (gtk2, emulated by Qemu, not susceptible to alignment errors): 
>> Debugger access is erratic, works best if debug windows displayed 
>> before program run. "Step into" (-> -exec-step-instruction) OK. "Step 
>> Over" (-> -exec-next-instruction") OK. Assembler window shows tabs as \t.
> Can you send a sample (from the debug output window) of what 
> data-disassemble returns? So I can see some data with \t
> 
>> SPARC (gtk2): "Step into" (-> -exec-step-instruction) appears to step 
>> over the next instruction if it's a call, however this appears to be 
>> an artifact of the way calls work (i.e. with a mandatory nop 
>> appended). "Step Over" (-> -exec-next-instruction") OK provided that 
>> the above is taken into consideration. Assembler window shows tabs as \t.
> Or send the output from this. Whichever , on e is enough.

This is from SPARC since I can run it natively- emulated ARM is a bit slow:

moonphase.pas:1345                Assert(test_jYear);
000825F4 7ffffcf1                 call  0x819b8 <TEST_JYEAR>
000825F8 01000000                 nop
000825FC 80a20000                 cmp  %o0, %g0
00082600 1280000d                 bne  0x82634 <MOONPHASE_init+472>
00082604 01000000                 nop
00082608 01000000                 nop
0008260C 9610001e                 mov  %fp, %o3
00082610 94102541                 mov  0x541, %o2
00082614 11000d2b                 sethi  %hi(0x34ac00), %o0
00082618 90122118                 or  %o0, 0x118, %o0\t! 0x34ad18 
<_$MOONPHASE$_Ld121>
0008261C 92100008                 mov  %o0, %o1
00082620 19000d2b                 sethi  %hi(0x34ac00), %o4
00082624 98132128                 or  %o4, 0x128, %o4\t! 0x34ad28 
<_$MOONPHASE$_Ld122>
00082628 9010000c                 mov  %o4, %o0

First line is emboldened. Same code compiled with fpc -al -Sa

.Lj1041:
         mov     %i6,%o3
         mov     1346,%o2
         sethi   %hi(_$MOONPHASE$_Ld121),%o0
         or      %o0,%lo(_$MOONPHASE$_Ld121),%o0
         mov     %o0,%o1
         sethi   %hi(_$MOONPHASE$_Ld122),%o4
         or      %o4,%lo(_$MOONPHASE$_Ld122),%o4
         mov     %o4,%o0
         call    FPC_ASSERT
         nop

> If "-exec-step-instruction" is sent, then it is a gdb issue. (Could be 
> debug-info encoding from fpc, if there is debug info for that. I don't 
> know if gdb would use that for single-instruction steps
> 
>> Reliability in some cases might be improved by restarting Lazarus 
>> after a debugging session, particularly if the target program hasn't 
>> run to completion.
> Try "Reset debugger" from menu "run". (Afaik, ctrl-F1)
> 
> Lazarus keeps gdb running. So if gdb is unstable, that may be an issue

Test case: ran to a breakpoint on the Assert() above, stepped one 
assembler op, reset debugger. Ran to breakpoint again, assembler window 
step buttons were greyed. Closed assembler window, reopened, buttons now 
OK :-)

-- 
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