Hi,

if you let the IDE create debug and release build modes for you the resulting debug mode sets the -Xg flag (GDB external debug symbols file). The internal debugger does not work with this set and complains about not finding debug symbols. Perhaps the default debug mode should not set this flag so that both debuggers get at least the chance to work.

R.

Or add a capability flag to the debugger class for external debug symbols. If the current debugger does not support it, the IDE does not pass the flag.

Mattias

It would be useful if someone could post a fix as I am getting this problem all the time with 1.2.6.

It would be useful if someone could post a fix as I am getting this problem all the time with 1.2.6.

1.2.6 does not have components/lazdebugger.
What debugger do you mean?

Mattias

GDB on Ubuntu 14.04

A typical problem is when evaluating a symbol that belongs to the current class (e.g. FMyVariable), then inspecting FMyVariable gives "symbol unknown" while "self.FMyVariable" works. When I saw the post, I assumed it was the same problem.

Sounds unrelated.

Can you check if this bug still exists in trunk (1.3)?

Mattias

Or add a capability flag to the debugger class for external debug symbols. If the current debugger does not support it, the IDE does not pass the flag.

Sounds better, do this. :)

R.

Done.

Mattias

Mattias,

I did the following on an up-to-date Ubuntu 14.04/Linux Mint MATE edition with fpc 2.6.4, gdb 7.7.1

1. download trunk from svn (svn co
http://svn.freepascal.org/svn/lazarus/trunk)

2. Ran "'make"

3. After successful compile ran "./startlazarus --pcp=~/lazarus-devel"

4. Opened the "Image Viewer" example (examples/imgviewer)

5. Complied and ran successfully.

6. Changed build options to generate debugging info and rebuilt.

7. Set breakpoint on line 142 of the main form.

8. Right mouse click and select Debug->Evaluate/Modify on the public property ODImage and the result is shown as "<Error>". See attached screenshot.

9. Same on local variable "I" and the value is correctly shown. Similarly "self.ODImage" works.

So in answer to your question

Can you check if this bug still exists in trunk (1.3)

The answer "yes" and easily demonstrated.

Tony Whyman
MWA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lazide-dgberror.png
Type: image/png
Size: 161499 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141205/41d9c843/attachment-0001.png>

[...] > Can you check if this bug still exists in trunk (1.3) The answer "yes" and easily demonstrated.

Thanks for the bug report.

Mattias

Just to be sure, you refer to 3 different things throughout this mail threat.

Tony Whyman wrote

8. Right mouse click and select Debug->Evaluate/Modify on the public property ODImage and the result is shown as "<Error>". See attached screenshot.

1) property
....

2) Variable

http://bugs.freepascal.org/view.php?id=27136

Cannot inspect class properties in Debugger

3) class property

Which one is it?

I hope that "mail threat" was a typo ;)

I have now written up what I found as

http://bugs.freepascal.org/view.php?id=27136

Hopefully this is clear on the problem.

Martin Frb wrote

Just to be sure, you refer to 3 different things throughout this mail threat.

...

Same holds for stabs-debug info. And yes, a capability flag would be nice.

Regards,
Joost.

It would also be good if packages could be set, to follow the dwarf/stabs selection of the project. (though that means more re-compiling).
(I suspect some gdb deal badly with mixed info.)

What happens if the RTL is compiled with debug info and the project is compiled with another type?

Mattias

What infos are supported by which debugger class?

Mattias

Mattias Gaertner wrote

What happens if the RTL is compiled with debug info and the project is compiled with another type?

I dont know.

Usualy it should work. Afaik it is allowed to mix them.

Old gdb (7.2 7.3) seem to be ok. gdb 7.5.9 upwards has a lot of troubles. I am not perfectly sure if it is related. Just a suspicion.

Mattias Gaertner wrote

What infos are supported by which debugger class?

gdbmi (gdb) (and variants (ssh, remote) are the only ones that understand stabs.

All of them understand dwarf2 ( and dwarf2 + sets)

dwarf3 is beta to all of them. (gdb may actually crash on it), the others are only partly tested yet)

We can add a checkbox to package debugger options 'Use Project settings'.
What options should then be disabled?

Mattias

Well at first I thought that simply the choice of stabs/dwarf should follow.
Though of course it has nothing to follow, if the project has debug disabled, but the package has it on (that is possible)

We could make the main toggle "Generate debug info" to follow too. But that is not needed. It can always be on, generating ppu with info, and the project can use -Xs (strip).

Looking at it:
"-Xg" (external dbg info), that is a linker flag. That probably makes no sense in package options?
"-gh" afaik is also project only (the mem manager applies to the entire exe)

"-gl" makes some sense, as it adds some basic debug info (line info), not sure about the inclusion of the units (lineinfo, ...) that cerate the dump, are they project wide?
That is using -gl on a package, ifin is ont used in the project, will that work?

Actually a package can build a program. Although it is unusual and not needed anymore when we have project groups.
So, yes, I agree it should be disabled when following Project Settings.

No.
So -Xg, -gh, -gl.
What about -pg and -vg?

BTW, why is -gt under "Debugging info" instead of "Checks and assertion"? It increases the nitpicking.

Mattias

-gl still adds lineinfo (a subset debug info). SO useful, but different name.

If stabs/dwarf do follow, and the package has no debug info, but it has -gl, then there is some trick to set the line info to the wanted format. But I do not remember ...

What about -pg and -vg?

Not sure if should follow.

maybe -vg (IIRC -vg is an extension to either stabs or dwarf, it changes the debug info generated (it drops some stuff, that older valgrind did not understand)

but -pg, I do not think. You do not necessaries want to profile packages.

BTW, why is -gt under "Debugging info" instead of "Checks and assertion"? It increases the nitpicking.

good question

Martin Frb hat am 7. Dezember 2014 um 22:57 geschrieben: [...] but -pg, I do not think. You do not necessaries want to profile packages.

IMHO the gprof output is far less readable if only the project units are compiled with -vg. But if you see an use for compiling only parts with -pg, ok with me.

Mattias

I never used it, so if you have experience with it, then decide.

I was just thinking, that if I profile my code, I might not need to see all the LCL stuff. But of course it depends, on the time actually being spent in my code, or in doing many calls to the LCL.