Disassembly

[wordweb]

I've converted some delphi code, and am now fairly sure that FPC is producing strange results for some included asm statements. However to track down exactly what I need to be able to see what Lazarus is producing.

 * What has happened to the IDE disassembly view - e.g. this message implies it exists but it doesn't show up in the latest download?

 * The IDE debugger does not seem to evaluate register names  (eax, etc)

Thanks.

[Leledumbo]

Use -alnrt compiler option for detailed generated assembly file (in AT&T, hope you can read it).

[wordweb]

Yes, thanks - I was using that. But what happened to the disassembly debug window? Should I submit non-support for "eax" etc in the debugger to the bug tracker?

(also see bug http://mantis.freepascal.org/view.php?id=11786 - my code works when compiled with -al but not without that option, so these options don't help much with this particular problem!)

[Marc]

making a asm window is on the roadmap. No need to create an issue for it.

[bobo]

Is there any ETA on this yet?

It is virtually impossible to debug programs with Lazarus at the moment, especially if it contains some asm code. To have a proper watch window (to see object properties, etc.) as well as CPU window is really necessary.

[Marc]

Don't know what needs to be done to step through inlined asm. In theory line info could be generated for it so you could see the asm in your source. To watch registers, prefix the names with $ like $eax

To see class properties a different debugger is needed, since gdb doesn't support them.

[bobo]

How do C++ people debug their OO programs?  I mean what do they use if gdb cannot do class properties?

I know Delphi had all these features above over 10 years ago, so it is definitely doable, at least on Windows (which could cover the majority of the people using Lazarus).

This is really missing from fpc/lazarus at the moment.

[Marc]

Delphi has its own debug format and its own debugger, so you might expect that they understand each other.
gdb is primarely developped by C ppl, knowing only C. C and C++ don't know the concept of properties, so gdb has no knowledge on how to handle them. And C++ OO ppl don't have to debug them.
Even worse the debug format gdb uses (Stabs) doesn't know the concept of properties either. So even in the case someone adds supports for properties to gdb, it cannot evaluate them since the debug info doesn't provide the information that a certain symbol is a property.

[bobo]

I guess developing a debugger like that would be a huge undertaking (even if it is only for Windows) and currently out of the scope of the developers?

Still, it is one thing that is majorly missing to do RAD.

[Marc]

A pascal native debugger is being (slowly) developed. I hope to get into a bit more speed

[bobo]

That is good news.

Is there any roadmap or additional information available about this?
Like what is under development at the moment, what is planned, maybe when?