[Lazarus] debug hints in lazarus [Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]

[Martin]

On 13/09/2011 13:07, Graeme Geldenhuys wrote:
> On 13/09/2011 00:12, Martin wrote:
>> I do not recall having ever had an issue with globals, nor local vars.
>
> Nope, the problem is still there... just as when I tested it back in
> 2008-2009.
>
>
>    http://opensoft.homeip.net:8080/~graemeg/gdb_issues_with_fpc.png

ShortDateFormat is declared in the RTL
So you need an rtl with debug info.

On my system, I can inspect it (including hint). But my rtl has debug info.

I understand this is annoying. And I understand from a users point of 
view, it makes no difference.
But, if we wish to look at solving it (or determining if/how it can be 
solved), then we need to differ between failurses by the debugger, and 
things the compiler does not make available.
So as far as the recent "naitve debugger" discussion goes => a native 
debugger will not fix this, IF it is indeed caused by the complete 
absence of debug info for the symbol.

Maybe FPC can include info of certain symbols (if they are used) from 
other units, even if those units are without debug info...

I believe that happens for class structures in a partial way.


> This exact same code works perfectly in Delphi 7 and Kylix 3. Above is
> an old screenshot, but I just tested with latest Lazarus Trunk and GDB
> 7.3 - nothing has changed.
>
> And yes, I know in FPC it is an absolute variable, but it is a global
> variable to the developer none the less.
See note about debug info


> I agree with Dodi, 95% of the things I try and debug I simply get 'No
> symble in current context". Thus making GDB rather useless for my code.
Well maybe if you debug alot of RTL symbols, and have an debug info free 
rtl => then this is true.

But then the "what debugger to use" discussion will not help.


> Oh, and ALL my code is done via OOP, so inspecting properties of a class
> is vital.
So is much of the code I use. If properties do not modify the state of 
that app, or objects (and that is kind of vital to allow running getter 
functions) then all relevant info can be gotten by expecting fields.
I assume debugging ones one classes, one would be familiar where a 
property gets a value from?

I do not argue that there is a serious impact on COMFORT. there is an 
impact. no doubt.

But yes, I take your word for it, that for you, your classes are 
designed in a way, that there is absolutely no way around inspecting the 
property instead of a field.

Given that there seems no alternative to gdb yet, and given that your 
code can under no circumstances be debugged using gdb => I must say, I 
have a huge amount of respect for your archivment of implementing fpgui 
without using any debugging at all. WOW.  (scnr :)  )


> And yes the "inspecting properties could change data" is a moot point.
> Delphi allows it, and NOBODY complains about the possible data change
> issue. The pros far outweigh the cons. We are programmers, we should
> know what is "dangerous" or not - but it should be our choice to use
> such "dangerous" features.
I am not avoiding the feature because of it;'s potential dangers.
If the feature was do-able => fine.

I just say from my personal experience,  I can live without it, but that 
may just be me.
And I am saying, if properties are the only problem => then the 
situation certainly is not as bad as some people say.

But I begin to see, that on some installations further problems exist, 
that add to it. Those problems should not exist => as they are working 
already on other systems (like mine)

> I also agree, that being able to read the field variable value via the
> property name would already be a huge improvement. NOTE: I mentioned
> here "via property name", not field name, because often I don't know
> what the field name is, especially if you have a large hierarchy of objects.
Well again => that works perfectly fine on my installation

maybe again that you have units without debug info (or you mix dwarf and 
stabs)?


Martin