cced to lazarus list. please switch list.

If that is the case, then your problem lays elsewhere, and maybe it can be remedied by config....
I do not recall having ever had an issue with globals, nor local vars. Maybe you have some units, that are not compiled with debug info, like in packages?

About hints:
- yes they can overflow. A selectable/scrollable hint window is planned
- yes they are badly formatted. But the info is there.

I latest trunks, hint display the data according to the class of the instance, not the declaration

Sender: TObject
if it contains a TForm, you see all the data (except what gets cut off)

UPS:
hints in trunk have a few other bugs => not debug related

- without TurbuPowerIProDSgn (mo html hint) they do close, triggered by their own opening action, if they have large content => this is a hint issue, that happens outside debugging too
- with TurbuPowerIProDSgn they just keep crashing....

So testing the debugger for hints is a bit limited due to other bugs;
sorry about that

make sure you use dwarf

-gw

also make sure under "extra options" you add -godwarfsets otherwise set types may not work .
(ok, the ide should probably make that more automated...)

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

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.

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. Oh, and ALL my code is done via OOP, so inspecting properties of a class is vital.

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

Regards,
- Graeme -

Ah. That problem. Luckily (?) this has nothing to do with gdb. Also any Pascal debugger won't fix this.

This problem exists because there is no debug-information generated for the unit containing that global variable.

Adding a compiler option to add type and global-variables debug-information to units, without lineinfo is on my todo list for a long time now. That way the rtl and part of the fcl can be compiled with this debug-info. Maybe I should spend some time on it.

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.

The reason that this doesn't improve is that those who can fix it don't have such problems. If you want them fixed, it's better to report when the debug-info doesn't work for you, so it can be fixed. Rather then assuming that it will be a
'gdb-messy-problem-which-can't-be-fixed-easily'. As it often isn't.

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.

This is already possible.

Joost

I once wrote to Graeme:
"
I absolutely can't imagine how you can productively develop fpGUI without excessive use of the integrated debug facilities of your IDE.
" :-)
http://thread.gmane.org/gmane.comp.ide.mseide.user/18768/focus=18780

Me too. Anybody seems to use the "f" field naming convention so most simple properties can be watched by prepending the property name by "f". If there are complex getters i need to see into the getter function to check what's going on anyway.

And I am saying, if properties are the only problem => then the situation certainly is not as bad as some people say.

Agreed.

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)

And mine.

Martin

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.

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 . (scnr :) )

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

BTW: is it correct that some info about classes from units without debug info, does get into the app?
At least if you have an inherited class, in a unit with debug info.

e.g If TForm1 in unit1 has debug info, then TComponent (which is a base class) appears to be included too?

I think so. If you want to know this, do a 'objdump -W programexecutable'. I don't remember it's Windows counterpart, but you could ask google. It will show you the Dwarf-data. This is imho also the first step if you want to learn more about the Dwarf-debug information format.

Joost

An rtl with debug info has advantages such as visibility of global variables.

The disadvantage is that step into also steps into compiler helpers, like increasing the reference count of an ansistring or setting up an exception frame. That is the reason, I distribute the RTL for win32 now without debug info,

Is it possible to include debug info for the variables, but not debug info for stepping into these compiler helpers?

Vincent

Thanks for the tip, should hopefully be very valuable in future.

I think fpc distributes a windows copy of objdmp

As for the original question, I just did the test => compiled an app with a debug free lcl => fields from parent classes are present

See my mail from 15:01. Yes, that's possible. I once wrote a patch that made it possible to force debug-info on a type or global variable, with some extra keyword. So that we could mark some variables or types in the RTL with it. But then Jonas said (wrote) that adding a compiler switch that appends debug-info without lineinfo would be better. And I have to agree to that. So the original patch never made it. But I never made a new one to implement such a switch.

Joost.

Martin wrote

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

I realized that as soon as I read Vincents reply. :-) But then, why does it work in Delphi? I am using Delphi 7, and there is a separate "DEBUG RTL" directory, which I am not using as far as I know. I'm not in front of my work PC now, so I can't check the exact Environment settings of Delphi, or the Delphi directory layout where the debug RTL files are located.

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

I'll recompile my RTL tomorrow, and see how that goes.

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

I guess my other problem is that I often have an application singleton function that returns the application instance. It's a function that returns a object instance - thus no debugging is supported by default.

Though experimenting with this a bit further, I noticed that I could use the private application instance variable that the singleton function uses, and that seems accessible to the debugger and allows improved debugging. :-)

eg: I need to change my debug expression from:

gMyApplication.CurrentUser.Name

to

uMyApplication.CurrentUser.Name

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

Yes, field variable are hard to track down when you have 10+ hierarchy levels, and sometimes there are no field variables at all, just a getter function which are virtual or virtual abstact, and overridden somewhere in the class hierarchy.

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 . ?(scnr :) ?)

I use tiOPF's tiLog unit for 95% of my debugging needs. I basically limit GDB usage to breakpoints and single stepping. But I keep monitoring the log output. tiOPF's log framework can log to file, console, gui window (separate popup window, but built into the app) or debug server (a separate gui app in fpGUI), so debugging works quite well, contrary to what you might think. AND the output is always readable, unlike the current state of Lazarus trunk. ;-)

I just say from my personal experience, ?I can live without it, but that may just be me.

And I'm just saying that debugging is Delphi is so much less effort than with FPC. In Delphi I can get on with my work, in Lazarus I have to fight a debugger. But please don't take this the wrong way, I am really glad to see all your hard work and efforts in trying to improve debugging under Lazarus. It is definitely improving.

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

I use only DWARF debug info. I believe this is the standard under 64-bit FPC anyway.

Becuase the delphi compiler (not debugger) does add infor for the those global vars (but skips any debug info for funtionx)...

> 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 I guess my other problem is that I often have an application singleton function that returns the application instance.

If it is a plain function (not a method), and if it takes no param => try (without the quotes)
"gMyApplication()"
"gMyApplication().CurrentUser"

I can't gurantee it will work. but if you get real lucky...

...

so debugging works quite well, contrary to what you might think.

You did read the "scnr" followed by a common emoticon?

AND the output is always readable, unlike the current state of Lazarus trunk. ;-)

And you do output entire classes, or just individual fields?

Because I use the watch window. I display:
- fields
- properties that map to fields
- parameters , local and global vars of simple type, or their fields And the output looks quite good as well

Further more I have like you a history of output => only if I select any of the previous values of my watches, I also get the callstack, that was at the time, and I can click the callstack.
I can even save the entire recorded debug session to a file. And import it. (and soon / fixing right now) import will also work on some-one elses installation, allowing to send the content to coworkers (providing the comfort of a click-able callstack for each entry in history)

That is what I meant by "missing comfort", quite different from totally unusable (though I can see the issue with global vars from rtl doesn't help)

But please don't take this the wrong way, I am really glad to see all your hard work and efforts in trying to improve debugging under Lazarus. It is definitely improving.

No worries, I am not taking it personal.

And i am not defending it just because I happen to be involved.

But of course as it turned out, some of the differences in the judgment were because we had different results, but didn't know that was the case.

I never knew some people did not see variables from rtl. It never occurred to me, as it always worked for me...
Now take that into account: Of course I couldn't understand "95% of identifiers just say 'unknown'".

Hm that is stranhe. i tested here. Fields (as long as they map to properties work. they work even if they are in a unit without debug info (TComponent) => as long as you have a class that inherited from it, and that class is in a unit with dwarf.

Though I only tested under 32 bit (and win).

I am not sure what the minimum fpc version for this is.

Just as a sidenote: If I remember correctly Delphi doesn't allow you to inspect all getters. Once they are too complex it will display that the value can't be displayed.
When I've done my bachelor thesis (this Thursday) I'll play around in my Delphi XE a bit to see whether I can pinpoint such situations. Perhaps Delphi is marking the getters as "pure" if there are no sideeffects (e.g. assignments besides Result, calls of non pure functions/methods etc.)

Regards,
Sven

Martin wrote

Becuase the delphi compiler (not debugger) ?does add infor for the those global vars (but skips any debug info for funtionx)...

Ah, sneaky.

If it is a plain function (not a method), and if it takes no param => try (without the quotes) "gMyApplication()"

Cool, I'll give that a try. Thanks for the tip.

Yes, but I have no idea what "World of Warcraft" or "Somatic Cell Nuclear Replacement" has to do with the current topic. ;-)

And you do output entire classes, or just individual fields?

Both. tiOPF has a debug visitor class that generates whole class output, and for everything else, I can use the various Log() or LogXXX() calls. Code Templates come in handy here, and auto-wraps such code in IFDEF's so they don't accidentally get left in the code or compiled in release builds.

Because I use the watch window. I display: ..... And the output looks quite good as well

The "Watch List" window is rather broken as far as I'm concerned.

http://bugs.freepascal.org/view.php?id=20230
http://bugs.freepascal.org/view.php?id=18380
http://bugs.freepascal.org/view.php?id=18379
http://bugs.freepascal.org/view.php?id=18035
http://bugs.freepascal.org/view.php?id=17619

I can even save the entire recorded debug session to a file. And import it.

That's pretty neat.

I am not sure what the minimum fpc version for this is.

I'll get a fpc trunk update tomorrow and retest.

As far as I can make out:

If it is a field, then it will display the value at once in the debug inspector. If it is not a field (and so a procedure), then the '?' button appears, and you must click it to get a value, regardless of the 'complexity'.

If you put an entry in the watch window, it is always evaluated.

Michael.

First 3 are gtk issues. Maybe even related to the grid => they will get better attention, if described as issue of the relevant component.

If I remember them, next time when I boot linux, I may check that, and change them. But I don't boot linux that oftne, and I can't gurantee I remember.
Problem is anyone maintaining gtk2, is unlikely to spot a bug labbeled "WATCH / Debugger"

4th : not storing sizes of columns => yep that is true... problem is, it currently doesn't bother me to much (probably because on windows I get a resize-mouse pointer, and it is easy and quick to change) => So it currently gets pushed behind plenty of other issues.

5th: string 0 vs 1 base: that applies to hints too => it's nothing to do with the watch window. (But yes, point taken, your logging does it correct) need to check dwarf3, (though the ide needs a couple of other fixes fordwarf3 first)

> I can even save the entire recorded debug session to a file. And import it. That's pretty neat.

Debug Windows => history (or lazarus developer blog)

> I am not sure what the minimum fpc version for this is. I'll get a fpc trunk update tomorrow and retest.

I definitely used it before 2.6 was branched => so it was in 2.5.1 I do not know about 2.4.x

<...snip...>

<...snip...>

Or as far back in time as
http://bugs.freepascal.org/view.php?id=12111

Funny how experiences can differ. For me, debugging on Lazarus works better than with Delphi. That's because when you're debugging on Delphi, the IDE is scaled down to the feature-level of Notepad. Code-completion and code-lookup do not work anymore (and they are already not as good as Lazarus' codetools)

Joost

Joost van der Sluis wrote

Funny how experiences can differ.

I honestly can't think how anybody can say Lazarus debugging is better than Delphi (or even Kylix 3 from years ago). But as you said, each persons mileage my vary. :-)

better than with Delphi. That's because when you're debugging on Delphi, the IDE is scaled down to the feature-level of Notepad.

Normal code navigation (Ctrl+Click) in Delphi 7 [only Delphi I currently have available] is indeed disabled while debugging, but that was substituted for another debug function. Ctrl+Click while in debugging mode allows you to quickly view the debug data, data type etc., and _allow you to modify_ the value if needed. Something which is quite handy while debugging - so I can understand why they altered the IDE behaviour while debugging.

Can one change values of items while debugging in Lazarus? I can't seem to find any such functionality in Lazarus 0.9.30.1 (I'll check trunk tomorrow at work). I know GDB (command line) and MSEide allows this, so it should be possible in Lazarus IDE.

And there was no other key shortcut they could have used?

Ctrl-F7
or context menu: Debug => evaluate

look at the bottom of the window, for giving it a new value.

And for another way to see an entire object (only trunk) alt-f5 (or inspect)

Martin wrote

And there was no other key shortcut they could have used?

I guess not. ;-)

Ctrl-F7 or context menu: Debug => evaluate look at the bottom of the window, for giving it a new value.

Cool, thanks for the info.

And for another way to see an entire object (only trunk) alt-f5 (or inspect)

Another IDE bug:
http://bugs.freepascal.org/view.php?id=20237

Regards,
- Graeme -

Ah, that's probably also why they disabled code-completion during debugging. Not being able to write code while debugging is a feature! (Btw: that modify variable function is also available in Lazarus, as Martin already stated)

Joost.

That means the way they implemented their feature is extremely inconsistent:

1) in Delphi you are not supposed to edit source wile debugging
2) If inserting lines, in source while debugging (like in Lazarus) Delphi keeps track of line positions, so the execution mark is still shown at the correct code (despite the new line number) I must wonder why a company creating a commercial product, wastes time and money on the 2nd point, if no one will eve benefit from it?

I'm not sure I believe your #1. You just have to be careful how you do it.

I do #2 all the time, so I sure benefit from having it! Has worked reliably and consistently for many, many versions.

Rich

Martin wrote

1) in Delphi you are not supposed to edit source wile debugging

I believe that is their theory, because even in Delphi 7 there is a option to make all edit buffers read-only when debugging is started.