Hi,

http://mantis.freepascal.org/view.php?id=17619

I can reproduce this on two very different machines (32 bit laptop running Ubuntu 8.04.4, and a 64-bit desktop running Ubuntu 10.04.1). I'm using FPC 2.4.3 and latest SVN Lazarus.

Such basic features really should work in any IDE. If we can't trust the debugger, who can we trust?

Regards,
- Graeme -

2010/10/13 Graeme Geldenhuys :

Such basic features really should work in any IDE. If we can't trust the debugger, who can we trust?

But in fact they really don't work in complex cases as indexed string expression evaluation.

You can not trust a debugger. You can trust output to the console instead.

Vincent

Vincent Snijders wrote

But in fact they really don't work in complex cases as indexed string expression evaluation.

Huh? Are you saying that rather simple code example is actually "complex"?

You can not trust a debugger. You can trust output to the console instead.

Just in your world (or is that FPC and Lazarus's world) that it true. Everybody else in every other programming language uses the debugger output as correct - for debugging purposes none the less.

I guess yet another example of why a native Object Pascal based debugger is _required_ for FPC and Lazarus.

I attached a Kylix 3 screenshot for your viewing pleasure. Just to show that some debuggers can actually show the correct debug values with that "complex" code example of mine. Sometimes I wonder if moving to FPC and Lazarus was actually such a good choice. Lately I struggle to silence the laugher from other developers using other languages and toolset. :-(

What's the goal of blaming? The sources of FPC, Lazarus, gdb (or duby) are open. We just need someone who will work on debugger support at least 10-15 hours per week. Those parts of lazarus on which someone constantly invest time (like source editor or codetools) are good (even compared to commercial products).

After all it is known that lazarus and fpc needs more developers.

Best regards,
Paul Ishenin.

It is a complex structure for the debugger. It puts together at least 3 concepts.

Remember that the gdb debugger is extremely C oriented.

GDB is used by lack of something better, and by lack of someone willing to spend full-time work on maintaining a cross-platform debugger.

Comparing it to the Borland debugger which is in it's roots 25 years old, continuously maintained by a team that works on the Pascal language, and so is commercially backed up, is comparing apples with pears.

I think everyone would rather have a native FPC debugger, but as with all things: who is going to do the work ?

I dare say that work on fpGUI also doesn't advance as fast as you would like to. Why is this so ? Answer: Lack of manpower.

Taking into account the small community, FPC/Lazarus do an extremely good job.

Michael.

Graeme Geldenhuys wrote

--8<-- debugger, who can we trust?

Well, that depends on how well you deal with disappointment ;)

Op 2010-10-13 13:42, Paul Ishenin het geskryf:

are open. We just need someone who will work on debugger support at least 10-15 hours per week. Those parts of lazarus on which someone constantly invest time (like source editor or codetools) are good (even compared to commercial products).

It's just amazing that everybody known that the debugger support in Lazarus and FPC absolutely sucks! Even the crappy Kylix 3 has better debugger support. Yet those developers that have spare time will rather spend there time with more IDE eye-candy and other lovely little new IDE features, instead of getting the core functionality working and stable. With the Lazarus project, it is all about *adding more new features*, instead of fixing up what already exists. I guess that's the price you pay for using open source software. Like the saying goes: "you get what you pay for".

As for the Duby project. I have tested it frequently and tried to contribute some minor patches here and there. Unfortunately my understanding of debuggers and debugger formats are near zero - I'm an application developer after all. So it's rather hard to contribute to such a project, but I did try, and I do try with other open source projects too.. (while still trying to stay sane and have some form of a life).

So please don't try and imply that I am one of those "leachers" that just use software and don't contribute. I contribute plenty, to many open source projects. Lazarus and FPC are not the only open source projects I use and contribute to. Lets see the list: FPC, Lazarus, fpGUI, tiOPF, DCPCrypt, fpprofiler, Dunit2, FBLib, FPGInstall, Mozila Plugin Panel, Duby, OnGuard, ReportMan, EpikTimer, etc.... you get the point.

Anyway, my intension of this message thread was rather simple... something as basic as inspecting a character value in a string is broken in FPC+Lazarus+GDB. So how on earth is one expected to debug something that is actually complex?? Maybe everybody was too quick to judge Kylix (even me). It seems no matter how crap Kylix was, it was/is light years ahead of Lazarus.

Regards,
- Graeme -

Hello,

how about a fundraising campaign for a good debugger support (and maybe more features). I would like to give money for some features, some other users too? We would not raise enough to pay a full time job position, but maybe we providing an incentive.

greetings
Michael

Why do you say "it sucks" ?
It works, kind of. It depends on your expectations. I successfully debug applications. No, I don't expect useful info from the tooltips, so your particular problem doesn't bother me.

The Delphi debugger "sucks" as well:

I can debug my application exactly once.
After that, the IDE just hangs on the second run. Never fails, 100% reproducible. That bothers me more than the Lazarus tooltip failing in some cases.

I try to live with it, even though I payed many thousands of EUR for the Delphi 7 license.

Like the saying goes: "you get what you pay for".

This is always so. Open source works because developers have an itch, and they scratch it. You have a different itch from the other developers. Nobody will scratch your itch for you, unless they have the same itch.

So please don't try and imply that I am one of those "leachers" that just use software and don't contribute.

No-one implies this. But there is no escaping the observation that there is no-one who wants to maintain the debugger, and since the developers are volunteers, they do what they want to do. One cannot blame them for that.

Michael.

Op 2010-10-13 13:51, Michael Van Canneyt het geskryf:

Comparing it to the Borland debugger which is in it's roots 25 years old,

I explicitly compared it with Kylix, which was probably the crappiest product Borland released in its existence. Yet it still leaves the FPC+Lazarus solution in the dust.

Taking into account the small community, FPC/Lazarus do an extremely good job.

Unfortunately it seems neither of those projects can prioritize, or figure out what is actually important. I would have thought everybody working with a compiler (that's any type of software developer) would know that a compiler and debugger go hand-in-hand. So lets just place the blame of no debugger on the fact that its open-source software, then we can all sleep better.

PS:
I've just printed out a few articles and specs on DWARF 2 (...or should I rather be looking at DWARF 3?) Maybe I can contribute something more to duby, which seems the most far along native object pascal debugger around for FPC. If any of you have more tips, articles or other internet links on where/how I can learn about DWARF and debuggers, please let me know. Maybe I can get something going before I go totally insane.

Regards,
- Graeme -

The kylix debugger was exactly the same borland debugger as in Delphi, just recompiled for Linux.

> Taking into account the small community, FPC/Lazarus do an extremely good job. Unfortunately it seems neither of those projects can prioritize, or figure out what is actually important.

No, their idea of what is important simply differs from yours.

It's the same problem as some men preferring blondes, others preferring redheads: They will never agree on who is the most beautiful woman.

Michael.

Graeme Geldenhuys wrote

It's just amazing that everybody known that the debugger support in Lazarus and FPC absolutely sucks! Even the crappy Kylix 3 has better debugger support.

I think you are wrong. I recently had to debug an old project with Delphi 7. Argh! No possibility to explore local varables of calling procedures, no code navigation while debugging, a complicated way of defining watches and changing variables, unpractical setup of breakpoint properties... I really appreciate a well IDE integrated gdb instead. OK, I must enter an 'f' before the property name and string character indexes are null based, sometimes it is necessary to store a value into a testvariable but over all the productivity with MSEide/Lazarus-gdb is better than with Delphi 7.

Martin

Op 2010-10-13 14:43, Michael Van Canneyt het geskryf:

Why do you say "it sucks" ?

Simply for a lack of a stronger word. I was holding back on my frustrations.

It works, kind of. It depends on your expectations.

My expectations are rather low at the moment. Just show me the f**ken value of the variable!

"works, kind of" is so over exaggerated! I DOESN'T "tooltips debugging" was just a simple example... and not to mention that it at least showed more information that the damn Watches debug window! See the attached screenshot. The "Watches" window is even more useless than the tooltips debugging, so I opted for the best one out of the broken bunch.

So now I'm really confused at the what to believe in the Lazarus IDE? Tooltips that show values, but the wrong values, or the Watches debug window that shows nothing. And yes, both watches are Enabled.

So how did I come across this lovely debugging screwup...? I was trying to write a string parser, so debugging actual character values are a rather big deal in a string parser. But unfortunately Lazarus was NO this is what you get from a 10 year old compiler and an 8 year old IDE? Wow!

I successfully debug applications.

Please do share how you accomplish that feat. I think everybody here would love to learn from your experience. [this is a genuine request]

they scratch it. You have a different itch from the other developers.

I think every developer wants to debug their software. Nobody write bug-free software!

Regards,
- Graeme -

You should not use character indices with utf-8 anyway. ;-)

Martin

Op 2010-10-13 15:08, Martin Schreiber het geskryf:

based, sometimes it is necessary to store a value into a testvariable but

Oh, I tried this nugget you shared with me a little while back, but unfortunately as my screenshots show, that helped absolutely zero in this case. Watches debug window shows no value for the char variable. At least that is where MSEide outshined Lazarus IDE, by showing me the correct value of a char variable.

Regards,
- Graeme -

That you are frustrated is obvious to all, I would say =-)

I don't know what to say other than I press F9 and set a breakpoint. Then I step through the code. I never look at tooltips or watch window; Occasionally, when an access violation occurs, I look at the stack trace. All this works for my needs.

If I ever need to see actual values, I send them with SendDebug() to the debug server window, for the simple reason that
- it works without debugger as well,
- it doesn't mess with GUI events.
- It remains in the log on screen even after the execution has long moved on to another part of the code.

> they scratch it. You have a different itch from the other developers. I think every developer wants to debug their software. Nobody write bug-free software!

Correct, but most people simply take the tools at their disposal, shortcomings and all. This is not an excuse for not improving the existing tools. But saying that they don't work is an exaggeration.

Michael.

Op 2010-10-13 15:18, Martin Schreiber het geskryf:

> You should not use character indices with utf-8 anyway. ;-)

The string parser I am writing doesn't accept Unicode text. There are only 30 or so keywords in plain ASCII text, so inspecting the first character via an index is perfectly legal in this case. :)

Regards,
- Graeme -

Michael Van Canneyt wrote

That you are frustrated is obvious to all, I would say =-)

:) My apologies... I'll go drink a coffee on the deck to relax a bit.

Ah, this might be the solution then. Thanks for that.

Nono, coffee is bad for your nerves. Drink a beer instead :-)

You're welcome. Note that this uses
- dbugintf unit from FCL
- debugserver tool (lazarus/tools/debugserver)

Michael.

Everybody do what they want and can do.

As for the Duby project. I have tested it frequently and tried to contribute some minor patches here and there. Unfortunately my understanding of debuggers and debugger formats are near zero - I'm an application developer after all.

And we are (lazarus developers) not application developers you think? Do you think I know much about debugging formats? Know how to fix that drawf or stabs? No, although I tried. Lazarus gdb interface has been written by a lazarus developer and Duby has been written also by a lazarus developer. I don't remember much patches from the community into that part of lazarus. Also some debugger related patches was contributed to fpc project by lazarus developers.

So please don't try and imply that I am one of those "leachers" that just use software and don't contribute.

I did not imply that to you. I just said that you can't blame others because they don't do something you need because they do something else.

Best regards,
Paul Ishenin.

Op 2010-10-13 15:33, Michael Van Canneyt het geskryf:

I did a few quick tests using various data types and even property values of a class instance - it indeed seems like the most reliable way to debug using FPC. :)

** Friendly tip to Lazarus core developers **
Maybe change the Watches debug window to rather load up the debugserver instead - it seems a lot more useful and most importantly, reliable. Maybe you guys should even add a code tools template and hook it up to the keyboard shortcut used for "add watch at cursor" to rather inject a new source line SendDebugFmt() instead. I've already done the latter part via code templates, as show below - please consider adding these as default code templates.

-------------[ lazarus.dci ]-------------------
...
[sdf | SendDebugFmt]
$(AttributesStart)
EnableMakros=true
AutoOnSpace=true
RemoveChar=true
$(AttributesEnd)
SendDebugFmt('$Paste() = %|', [$Paste()]);
[sd | SendDebug]
$(AttributesStart)
EnableMakros=true
AutoOnSpace=true
RemoveChar=true
$(AttributesEnd)
SendDebug($Paste());
----------------------------

Regards,
- Graeme -

Graeme Geldenhuys wrote

So now I'm really confused at the what to believe in the Lazarus IDE? Tooltips that show values, but the wrong values, or the Watches debug window that shows nothing. And yes, both watches are Enabled.

maybe you attach the "debug output" window content?

So someone can look into why the watches did not show anything...

Martin

2010/10/13 Graeme Geldenhuys

@Graeme: I have to say that sometimes you make pointed criticisms which rub people the wrong way. I don't even know whether I have a place in the FreePascal community that entitles me to make such criticisms, and in a way I may be guilty of what I am accusing you of.

I don't know much about the private and working lives of the developers of FPC/Lazarus, and how much time they can afford to give the project, unless perhaps it impacts upon their own paid work, and probably neither do you, so I wouldn't criticize them in anyway. I am more of a taker than a giver here, as are a lot of FPC/Lazarus users.

I also don't know the issues which go into what they prioritize so I wouldn't criticize them on that.

It is clear from your output you are a talented and committed contributor to the FPC/Lazarus community and perhaps you feel that others do not have the commitment nor the vision that you do, but I don't think this is the way to express yourself. There shouldn't be any "you" or "you guys" in Lazarus or any other volunteer project, nor should they be addressed in a mocking manner - there should only be "we" or "us".

I posted this article - Observations on FreePascal and Lazarus Development<http://devblog.brahmancreations.com/content/observations-on-freepascal-and-lazarus-development>on my blog a few days ago, but because I haven't started any concrete work
on it, nor do I know when I can make time for it in the near future, I decided not to publicise it, unlike Build
Scripts<http://devblog.brahmancreations.com/content/build-scripts-for-installing-freepascal-and-lazarus-from-source>. If others come across it because they like the blog that would be good.

A similar issue came up in this thread on the forums - http://www.lazarus.freepascal.org/index.php/topic,10693.0.html - where I kind of inserted by observations in a sidewise manner.

Perhaps this drupal.org <http://drupal.org/node/897616> link may be of interest to you, but as a seasoned open source developer you must be familiar with the issues it addresses.

As an aside, I know the debugger issue you raised and it can be easily sidestepped by creating some simple variables and assigning the contents of the expressions you want so they can show in the debugger - a few judicious IFDEFs are an easy workaround. Many times I know the issue will hit and I am often too lazy to do it upfront (hint, hint), even though I know it will save me sometime in the edit,compile,debug cycle. Much easier than charged comments.

You should also realize that Lazarus does not have a great deal of commercial support as a lot of Delphi using companies are quite happy with it, even Delphi 7, and are not ready or interested to focus on the Linux space, unlike Ruby, Python, Scala and the other new fangled kids on the block.

As I have been composing this reply, about 12 new replies have been made to this thread and I don't know how relevant it still is - here it is anyway. I am of to read them now.

Not only FPC. I do the same in Delphi. Extremely useful for server debugging.

I use the following code templates in Delphi and Lazarus :

send | Senddebug statement | Borland.EditOptions.Pascal]
{$ifdef debug}SendDebug('|');{$endif}
[sendf | Senddebug statement with format | Borland.EditOptions.Pascal]
{$ifdef debug}SendDebug(Format('|',[]));{$endif}
[sendu | Add dbugintf to uses in define | Borland.EditOptions.Pascal]
{$ifdef debug}dbugintf,{$endif}
[sendme | SendMethodEnter | Borland.EditOptions.Pascal]
{$ifdef debug}SendMethodEnter('|');{$endif}
[sendmx | SendmethodExit | Borland.EditOptions.Pascal]
{$ifdef debug}SendMethodExit('|');{$endif}

The $ifdef allows you to switch it on or off quite easily.

Michael.

Op 2010-10-13 16:11, Martin het geskryf:

maybe you attach the "debug output" window content? So someone can look into why the watches did not show anything...

FPC: 2.4.3
System: Ubuntu Linux 10.04.1 64-bit
Lazarus: latest svn

The local char variable is: testvar

---------[ debug output window content ]---------------------- (gdb)
<-gdb-set confirm off>
^done
(gdb)
<-gdb-set new-console off>
^error,msg="No symbol table is loaded. Use the \"file\" command." (gdb)
<-gdb-version>
~"GNU gdb (GDB) 7.1-ubuntu\n"
~"Copyright (C) 2010 Free Software Foundation, Inc.\n" ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\n" ~"This is free software: you are free to change and redistribute it.\n" ~"There is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\n" ~"and \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\n" ~"For bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
^done
(gdb)
<-gdb-version>
~"GNU gdb (GDB) 7.1-ubuntu\n"
~"Copyright (C) 2010 Free Software Foundation, Inc.\n" ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\n" ~"This is free software: you are free to change and redistribute it.\n" ~"There is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\n" ~"and \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\n" ~"For bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
^done
(gdb)
<-gdb-set env BOOKSHELF=/opt/FPC_Docs/inf/>
^done
(gdb)
<-gdb-set env DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-f7vJ79V7T8,guid=8549b00c0344f0e2110ab80d4cb2ffd8> ^done
(gdb)
<-gdb-set env DEFAULTS_PATH=/usr/share/gconf/gnome.default.path> ^done
(gdb)
<-gdb-set env DESKTOP_SESSION=gnome>
^done
(gdb)
<-gdb-set env DISPLAY=:0.0>
^done
(gdb)
<-gdb-set env FPCHELP=rtl+fcl>
^done
(gdb)
<-gdb-set env GDM_KEYBOARD_LAYOUT=us\tdvorak>
^done
(gdb)
<-gdb-set env GDM_LANG=en_ZA.utf8>
^done
(gdb)
<-gdb-set env GDMSESSION=gnome>
^done
(gdb)
<-gdb-set env GNOME_DESKTOP_SESSION_ID=this-is-deprecated> ^done
(gdb)
<-gdb-set env GNOME_KEYRING_CONTROL=/tmp/keyring-H22nDY> ^done
(gdb)
<-gdb-set env GNOME_KEYRING_PID=1508>
^done
(gdb)
<-gdb-set env GTK_MODULES=canberra-gtk-module>
^done
(gdb)
<-gdb-set env HOME=/home/graemeg>
^done
(gdb)
<-gdb-set env LANG=en_ZA.utf8>
^done
(gdb)
<-gdb-set env LC_TIME=en_DK.UTF-8>
^done
(gdb)
<-gdb-set env LIBGL_DRIVERS_PATH=/usr/lib/fglrx/dri:/usr/lib32/fglrx/dri> ^done
(gdb)
<-gdb-set env LOGNAME=graemeg>
^done
(gdb)
<-gdb-set env MANDATORY_PATH=/usr/share/gconf/gnome.mandatory.path> ^done
(gdb)
<-gdb-set env ORBIT_SOCKETDIR=/tmp/orbit-graemeg>
^done
(gdb)
<-gdb-set env PATH=/home/graemeg/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/fpc-2.4.3/x86_64-linux/bin:/home/graemeg/apps/wipfc> ^done
(gdb)
<-gdb-set env PWD=/home/graemeg>
^done
(gdb)
<-gdb-set env ,unix/saturn:/tmp/.ICE-unix/1526>
^done
(gdb)
<-gdb-set env SHELL=/bin/bash>
^done
(gdb)
<-gdb-set env SPEECHD_PORT=7560>
^done
(gdb)
<-gdb-set env SSH_AGENT_PID=1566>
^done
(gdb)
<-gdb-set env SSH_AUTH_SOCK=/tmp/keyring-H22nDY/ssh> ^done
(gdb)
<-gdb-set env USER=graemeg>
^done
(gdb)
<-gdb-set env USERNAME=graemeg>
^done
(gdb)
<-gdb-set env WIPFC=/home/graemeg/apps/wipfc/>
^done
(gdb)
<-gdb-set env XAUTHORITY=/var/run/gdm/auth-for-graemeg-L8wBl0/database> ^done
(gdb)
<-gdb-set env XDG_CONFIG_DIRS=/etc/xdg/xdg-gnome:/etc/xdg> ^done
(gdb)
<-gdb-set env XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/> ^done
(gdb)
<-gdb-set env XDG_SESSION_COOKIE=5da05c10bd2c5ebb862261674bf650ed-1286799319.742014-1018818784> ^done
(gdb)
<-file-exec-and-symbols "/media/flash16gig/programming/fpgui/prototypes/miglayout/unittests/fpcunit_miglayout"> ^done
(gdb)
<-environment-cd .>
^done
(gdb)
<-environment-cd "/media/flash16gig/programming/fpgui/prototypes/miglayout/unittests/"> ^done
(gdb)
<-data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC> ^error,msg="No symbol \"FPC_THREADVAR_RELOCATE_PROC\" in current context." (gdb)
<info functions FPC_CPUINIT>
&"info functions FPC_CPUINIT\n"
~"All functions matching regular expression \"FPC_CPUINIT\":\n" ~"\n"
~"Non-debugging symbols:\n"
~"0x0000000000400e98 SYSTEM_FPC_CPUINIT\n"
^done
(gdb)
<-exec-arguments -a --format=plain>
^done
(gdb)
<set width 50000>
&"set width 50000\n"
^done
(gdb)
<-gdb-set language pascal>
^done
(gdb)
<info address main>
&"info address main\n"
~"Symbol \"main\" is a function at address 0x4001a0.\n" ^done
(gdb)
<-break-insert -t *4194720>
^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x00000000004001a0",func="main",file="fpcunit_miglayout.lpr",fullname="/media/flash16gig/programming/fpgui/prototypes/miglayout/unittests/fpcunit_miglayout.lpr",line="20",times="0",original-location="*4194720"} (gdb)
<ptype TObject>
&"ptype TObject\n"
~"type = ^TOBJECT = class \n"
~"end\n"
^done
(gdb)
<info address FPC_RAISEEXCEPTION>
&"info address FPC_RAISEEXCEPTION\n"
~"Symbol \"FPC_RAISEEXCEPTION\" is at 0x4108b0 in a file compiled without debugging.\n" ^done
(gdb)
<-break-insert *4262064>
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004108b0",at="<fpc_raiseexception>",times="0",original-location="*4262064"} (gdb)
<info address FPC_BREAK_ERROR>
&"info address FPC_BREAK_ERROR\n"
~"Symbol \"FPC_BREAK_ERROR\" is at 0x4145d8 in a file compiled without debugging.\n" ^done
(gdb)
<-break-insert *4277720>
^done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004145d8",at="<SYSTEM_HANDLEERRORADDRFRAME$LONGINT$POINTER$POINTER>",times="0",original-location="*4277720"} (gdb)
<info address FPC_RUNERROR>
&"info address FPC_RUNERROR\n"
~"Symbol \"FPC_RUNERROR\" is at 0x414718 in a file compiled without debugging.\n" ^done
(gdb)
<-break-insert *4278040>
^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000414718",at="<SYSTEM_RUNERROR$WORD>",times="0",original-location="*4278040"} (gdb)
<info file>
&"info file\n"
~"Symbols from \"/media/flash16gig/programming/fpgui/prototypes/miglayout/unittests/fpcunit_miglayout\".\n" ~"Local exec file:\n"
~"\t`/media/flash16gig/programming/fpgui/prototypes/miglayout/unittests/fpcunit_miglayout', file type elf64-x86-64.\n" ~"\tEntry point: 0x400140\n"
~"\t0x0000000000400120 - 0x0000000000400140 is .note.ABI-tag\n" ~"\t0x0000000000400140 - 0x000000000049ec10 is .text\n" ~"\t0x000000000069ec10 - 0x00000000006a1508 is .got\n" ~"\t0x00000000006a1508 - 0x00000000006a1520 is .got.plt\n" ~"\t0x00000000006a1520 - 0x00000000006ec280 is .data\n" ~"\t0x00000000006ec280 - 0x00000000006f1d80 is .bss\n" ^done
(gdb)
<-break-insert -f foo>
&"Function \"foo\" not defined.\n"
^done,bkpt={number="5",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="foo",times="0",original-location="foo"} (gdb)
<-break-delete 5>
^done
(gdb)
<-exec-run>
=thread-group-created,id="16421"
=thread-created,id="1",group-id="16421"
^running
*running,thread-id="all"
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x00000000004001a0",func="main",args=[],file="fpcunit_miglayout.lpr",fullname="/media/flash16gig/programming/fpgui/prototypes/miglayout/unittests/fpcunit_miglayout.lpr",line="20"},thread-id="1",stopped-threads="all",core="1" (gdb)
<info program>
&"info program\n"
~"\tUsing the running image of child process 16421.\n" ~"Program stopped at 0x4001a0.\n"
~"It stopped at a breakpoint that has since been deleted.\n" ~"Type \"info stack\" or \"info registers\" for more information.\n" ^done
(gdb)
<-break-insert -f gui_mig_constraintparser.pas:122> ^done,bkpt={number="6",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004467a0",func="STARTSWITHLENIENT",file="../gui_mig_constraintparser.pas",fullname="/media/flash16gig/programming/fpgui/prototypes/miglayout/gui_mig_constraintparser.pas",line="122",times="0",original-location="gui_mig_constraintparser.pas:122"} (gdb)
<-break-enable 6>
^done
(gdb)
<-exec-continue>
^running
*running,thread-id="all"
(gdb)
*stopped,reason="breakpoint-hit",disp="keep",bkptno="6",frame={addr="0x00000000004467a0",func="STARTSWITHLENIENT",args=[{name="this",value="0x7ffff7ff6320"},{name="S",value="0x6b3680 'abczz'"},{name="MATCH",value="0x6b3668 'abcdef'"},{name="MINCHARS",value="3"},{name="ACCEPTTRAILING",value="true"}],file="../gui_mig_constraintparser.pas",fullname="/media/flash16gig/programming/fpgui/prototypes/miglayout/gui_mig_constraintparser.pas",line="122"},thread-id="1",stopped-threads="all",core="1" (gdb)
<-symbol-list-lines /media/flash16gig/programming/fpgui/prototypes/miglayout/gui_mig_constraintparser.pas> ^done,lines=[{pc="0x0000000000446070",line="37"},{pc="0x000000000044608a",line="37"},{pc="0x00000000004460e1",line="38"},{pc="0x00000000004460fe",line="40"},{pc="0x000000000044610b",line="43"},{pc="0x000000000044614a",line="44"},{pc="0x0000000000446167",line="45"},{pc="0x0000000000446187",line="46"},{pc="0x00000000004461f3",line="45"},{pc="0x00000000004461f8",line="47"},{pc="0x0000000000446201",line="51"},{pc="0x0000000000446233",line="53"},{pc="0x000000000044624b",line="54"},{pc="0x0000000000446258",line="57"},{pc="0x0000000000446268",line="58"},{pc="0x000000000044627c",line="60"},{pc="0x00000000004462dc",line="62"},{pc="0x00000000004462ec",line="63"},{pc="0x000000000044630a",line="65"},{pc="0x000000000044636a",line="67"},{pc="0x000000000044637a",line="68"},{pc="0x0000000000446398",line="51"},{pc="0x00000000004463a1",line="73"},{pc="0x00000000004463d3",line="75"},{pc="0x00000000004463eb",line="76"},{pc="0x00000000004463f8",line="79"},{pc="0x000000000044642c",line="80"},{pc=" 0x0000000000446433",line="81"},{pc="0x000000000044643c",line="83"},{pc="0x0000000000446447",line="85"},{pc="0x0000000000446469",line="86"},{pc="0x0000000000446475",line="88"},{pc="0x00000000004464b3",line="89"},{pc="0x00000000004464c5",line="90"},{pc="0x00000000004464de",line="92"},{pc="0x00000000004464ec",line="93"},{pc="0x0000000000446506",line="100"},{pc="0x0000000000446570",line="99"},{pc="0x000000000044657a",line="100"},{pc="0x000000000044658c",line="99"},{pc="0x0000000000446596",line="100"},{pc="0x000000000044659d",line="99"},{pc="0x00000000004465a7",line="100"},{pc="0x00000000004465dd",line="99"},{pc="0x0000000000446657",line="73"},{pc="0x0000000000446660",line="104"},{pc="0x000000000044666e",line="105"},{pc="0x00000000004466dc",line="0"},{pc="0x00000000004466e0",line="108"},{pc="0x00000000004466f7",line="108"},{pc="0x0000000000446726",line="109"},{pc="0x0000000000446756",line="110"},{pc="0x0000000000446777",line="0"},{pc="0x0000000000446778",line="120"},{pc="0x0000000 000446797",line="121"},{pc="0x00000000004467a0",line="122"},{pc="0x00000000004467ae",line="124"},{pc="0x00000000004467b5",line="125"},{pc="0x00000000004467ba",line="128"},{pc="0x00000000004467c2",line="129"},{pc="0x00000000004467d2",line="131"},{pc="0x00000000004467e2",line="132"},{pc="0x00000000004467ec",line="134"},{pc="0x00000000004467f3",line="135"},{pc="0x00000000004467f8",line="138"},{pc="0x0000000000446808",line="139"},{pc="0x000000000044680f",line="140"},{pc="0x000000000044682f",line="142"},{pc="0x0000000000446834",line="143"},{pc="0x0000000000446837",line="142"},{pc="0x0000000000446869",line="145"},{pc="0x0000000000446893",line="147"},{pc="0x00000000004468c8",line="148"},{pc="0x00000000004468d0",line="150"},{pc="0x00000000004468d7",line="151"},{pc="0x00000000004468d9",line="153"},{pc="0x00000000004468dc",line="140"},{pc="0x00000000004468e5",line="155"},{pc="0x0000000000446908",line="156"},{pc="0x0000000000446910",line="158"},{pc="0x0000000000446917",line="159"},{pc=" 0x0000000000446920",line="0"}]
(gdb)
<-data-evaluate-expression testvar>
^done,value="97 'a'"
(gdb)
<ptype testvar>
&"ptype testvar\n"
~"type = Char\n"
^done
(gdb)
<-stack-list-frames 0 0>
^done,stack=[frame={level="0",addr="0x00000000004467a0",func="STARTSWITHLENIENT",file="../gui_mig_constraintparser.pas",fullname="/media/flash16gig/programming/fpgui/prototypes/miglayout/gui_mig_constraintparser.pas",line="122"}] (gdb)
<-data-evaluate-expression integer>
^error,msg="No symbol \"integer\" in current context." (gdb)
<-stack-info-frame>
^done,frame={level="0",addr="0x00000000004467a0",func="STARTSWITHLENIENT",file="../gui_mig_constraintparser.pas",fullname="/media/flash16gig/programming/fpgui/prototypes/miglayout/gui_mig_constraintparser.pas",line="122"} (gdb)
<-data-evaluate-expression parentfp>
^error,msg="No symbol \"parentfp\" in current context." (gdb)

--------------------------------------------------------------

Regards,
- Graeme -

2010/10/13 Frank Church :

I posted this article - Observations on FreePascal and Lazarus Development on my blog a few days ago, but because I haven't started any concrete work

I added the blog to:
http://wiki.lazarus.freepascal.org/Lazarus_Documentation#Lazarus_related_blogs_and_websites

I hope you don't mind.

Vincent

I hope you don't mind.

I am okay with that, I had something like that in mind before.

Op 2010-10-13 16:12, Frank Church het geskryf:

@Graeme: I have to say that sometimes you make pointed criticisms which rub people the wrong way.

Funny that, my wife (of all people) accused me of the same thing last week. Maybe it's just the way I write emails, but it's not always intended to come across so harsh.

I also don't know the issues which go into what they prioritize so I wouldn't criticize them on that.

Speaking as someone that manages a few projects at a time (open source and commercial) for many years now, it just frustrates me to see how the lazarus team runs their project. I have come to realize that there is nothing I can do about that, but it still frustrates me none the less.

As an aside, I know the debugger issue you raised and it can be easily sidestepped by creating some simple variables and assigning the contents of the expressions you want so they can show in the debugger

If you look at the screenshots I posted, that is exactly what I have done. Yet the Watch List debug windows shows no data, or the incorrect data.

The only good news that came out of this discussion, is Michael's hint about the dbugintf unit and the various SendDebug() methods. This actually looks like a workable solution. So all I'll use GDB for now, is to step through my code, while I watch the Debug Server window for variable values. At least this way, I can get around all the bugs in the debugger implementation.

Regards,
- Graeme -

Indeed there seem to be cases where individual debug windows ~~(watches / stack) are not updated....

Graeme Geldenhuys wrote

It's just amazing that everybody known that the debugger support in Lazarus and FPC absolutely sucks!

I don't think it sucks. It's better then vi, devcpp, doctor java, eclipse, etc.

In general, GDB is not at all a bottleneck in my software development needs. Of course I would be very happy if someone else writes a fpdebugger.

Plus, the tooltips always work for me. Maybe because I very rarely use the data type Char.

I would have thought everybody working with a compiler (that's any type of software developer) would know that a compiler and debugger go hand-in-hand.

That's more or less true but working with different languages and different debuggers shows that quality of debbugers varies a lot and that you cannot trust them 100%. So you come up with ways of debugging your software that work reliable on all languages you use. Once you found these ways the quality of the debugger gets less important as the debugger sees less use.

R.

2010/10/13 Felipe Monteiro de Carvalho :

Plus, the tooltips always work for me. Maybe because I very rarely use the data type Char.

I don't the problem is not the data type char, but that somewhere in the debugger tool chain (from lazarus tool-tips front end to the gdb backend using the fpc generated debug info) the assumption is used that pascal strings are indexed starting from 0 instead of 1.

Probably that is just how gdb works by default.

Vincent

GDB being C-biased, that is quite likely the cause. Means that the debugger interface must work around it.

Michael.

actually, I think in dwarf 3 the lower bound can be defined (and from a search in fpc sources, it may even be done...); but I couldn't get dwarf 3 results to work at all...

Martin

Martin wrote

actually, I think in dwarf 3 the lower bound can be defined (and from a search in fpc sources, it may even be done...); but I couldn't get dwarf 3 results to work at all...

Probably the wrong list to ask, but what is the state of dwarf3 support in FPC? From the many dwarf articles I have read tonight, it seems dwarf 3 final spec was released back in January 2006, so I would imagine any new debugger improvements must use dwarf 3 instead of dwarf 2? But as for as I know the default dwarf format used by FPC is dwarf 2... why is that?

From what I have read dwarf2 was just such a big mess as Coff - little

documentation, various incompatible implementations etc... All this and more was what dwarf 3 aimed to resolve. Correct?

Reimar Grabowski wrote

Once you found these ways the quality of the debugger gets less important as the debugger sees less use.

And that to me seems like the wrong way of approaching the problem. Treat the cause of the problem, not (band-aid) the symptoms. The debugger is there for a reason: to be used and trusted.

2010/10/13 Graeme Geldenhuys :

That may be so, but Reimar's expplanation also explains why it isn't such an itch for some of the more experienced Lazarus developers, they have learned to live the current limitations. It may be wrong, but that is how it works ...

Vincent

Graeme Geldenhuys wrote

Such basic features really should work in any IDE. If we can't trust the debugger, who can we trust?

I don't mean to hijack this thread but as we're talking about debugging here, there's a question I have been meaning to ask on the subject:

Sometime ago I checked with AQTime and --even though they seem to support every other compiler-- they don't support binaries produced by FPC.

I asked, in their forum, whether this was correct and the answer was "yes, we don't support FPC binaries".

I would have thought if a binary ran under Windows it was just like any other binary; but apparently not.

Does anyone know why AQTime wouldn't/couldn't support FPC produced binaries?

What's so different?

The debug format.

Michael.

The reason why DWARF 3 isn't used might be the following: http://www.hu.freepascal.org/lists/fpc-devel/2010-October/022297.html

Regards,
Sven

Even the latest Delphi versions don't support code-navigation while debugging. Even the code-completion doesn't work. Delphi's functionality drops to the level of MS Notepad when it's in debug-mode.

Joost.

Ah, now I see what you're problem is. You're trying to access indexed-strings. I've spend quite some time fixing that. It works now if you use Dwarf-3, fpc 2.5.1 and Fedora 13.

So if you really can't do without, just switch to Fedora and you're done. ;)

Joost.

Joost van der Sluis kirjoitti lauantai, 16. lokakuuta 2010 18:15:40:

Wow!
How to generate Dwarf-3 debug info?

Juha

-gw3

Joost

Le 16/10/2010 17:15, Joost van der Sluis a ?crit :

Is this a requirement on Fedora or a recent gdb build?

Thierrybo

I updated the latest FPC trunk version.
From a simple test program I get:
unit1.pas:(.debug_info+0x94): undefined reference to `DBG_FORMS_TForm' unit1.pas:(.debug_info+0xab): undefined reference to `DBG_STDCTRLS_TButton'

when built with -gw3. I have Fedora 13 but it is 64 bit system. -gw (without 3) works as before.

Juha

It's a gdb fix that isn't available in main-stream gdb, but which is included as a patch in Fedora's gdb.

Joost.

I also work on a 64 but system. You're sure you used fpc 2.5.1? And that you disabled smart-linking?

I used attached program to test gdb. (place breakpoint at second position and do a 'p s[2]')

Joost.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arrays.pas
Type: text/x-pascal
Size: 2303 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101017/ad4e0465/attachment.bin>

What's up with all the empty lines in your mail?

> I used attached program to test gdb. (place breakpoint at second > position and do a 'p s[2]') Form command line it works as advertized!

No, it does not. It should show 'test'#0'string'. At least with Dwarf-3.

ie: not good. Here it prints 'test'#0'string', as it should.

Hmm.. somewhat. Dwarf 3 adds the ability to store dynamic arrays properly. But stock-gdb doesn't support that properly. The problem is that it can not handle recursive types. So an array of an array fails miserably.

With some help of one of the RedHat developers I've created a patch for this. But it changes some really fundamental stuff, and the gdb-project is seriously understaffed. So it may take a while until this get into stock-gdb.

Elements of arrays show correctly but the values for whole arrays (DynArrInt, DynArrStr, DynArrChar) still don't, although it is different from -gw.

Works here. I'll check on a F13 system, to be honest I still use an older version.

Can you create a simple test-program that shows this behavior and post it as a bug?

Joost

Form command line it works as advertized!

arrays.pas, built with -gw, breaking gdb at line 82: (gdb) print s
$1 = 0x646240 'test'
(gdb) print s[1]
$2 = 101 'e'

The same built with -gw3:
(gdb) print s
$1 = 0x646240 'test'
(gdb) print s[1]
$2 = 101 't'

Great. So it means gdb's DWARF3 support was buggy and now it is fixed in Fedora package and later in others I guess.

Elements of arrays show correctly but the values for whole arrays (DynArrInt, DynArrStr, DynArrChar) still don't, although it is different from -gw. Whole static array (StatArrStr) actually shows better with -gw debug info.

I also created a Lazarus project from arrays.pas program, and set -gw3 to Project Options -> Other -> Custom Options.
Works well!

The problem comes when I create a Lazarus GUI application and set -gw3 there. From linker:
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? /home/juha/SW/LazTest/xxx/lib/x86_64-linux/unit1.o: In function `.La1': unit1.pas:(.debug_info+0x94): undefined reference to `DBG_FORMS_TForm' unit1.pas:(.debug_info+0xa5): undefined reference to `DBG_STDCTRLS_TButton'

With -gw it works.
I also tried to compile the whole Lazarus and LCL with -gw3 and got similar errors.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101017/1c186a28/attachment-0001.html>

17.10.2010 18:20, Juha Manninen (gmail) ?????:
<...>

Can you correct your time please?

Joost van der Sluis wrote

What's up with all the empty lines in your mail?

?
I don't see many empty lines.

Ok, you got me. I was only interested in this one char, ignored the rest and faked (copied) the output. Bad, sorry.

Many projects seem to be understaffed.

I copy here gdb's output when braking at line 82.

With -gw:
-----------
(gdb) p DynArrInt
$1 = 0x7ffff7fd6050
(gdb) p DynArrStr
$2 = 0x7ffff7fee0d0
(gdb) p DynArrChar
$3 = 0x7ffff7fe6090
(gdb) p StatArrStr
$4 = {0x7ffff7fde0d0 'str0', 0x7ffff7fde110 'str1', 0x7ffff7fde150 'str2', 0x7ffff7fde190 'str3', 0x7ffff7fde1d0 'str4', 0x7ffff7fde210 'str5', 0x7ffff7fde250 'str6', 0x7ffff7fde290 'str7', 0x7ffff7fde2d0 'str8', 0x7ffff7fde310 'str9', 0x7ffff7fde350 'str10', 0x7ffff7fde390 'str11', 0x7ffff7fde3d0 'str12'}
(gdb)

With -gw3 (no faking):
--------------------------
(gdb) p DynArrInt
$1 = '23456789:;<=>'
(gdb) p DynArrStr
$2 = {'?????'#127#0#0'0???', '?'#127#0#0'p????'#127#0, '?????'#127#0#0'????', '?'#127#0#0'0????'#127#0, 'p????'#127#0#0'????', '?'#127#0#0'?????'#127#0, '0????'#127#0#0'p???', '?'#127#0#0'?????'#127#0,
'?????'#127#0#0#129#128#19}
(gdb) p DynArrChar
$3 = 'abcdefghijklm'
(gdb) p StatArrStr
$4 = {'????', '?'#127#0, #16'???', '?'#127#0, 'P???', '?'#127#0, #144'???', '?'#127#0, '????', '?'#127#0, #16'???', '?'#127#0, 'P???', '?'#127#0, #144'???', '?'#127#0, '????', '?'#127#0, #16'???', '?'#127#0, 'P???', '?'#127#0, #144'???', '?'#127#0, '????'}
(gdb) p s
$5 = 'test'#0'string'
(gdb) p s[1]
$6 = 116 't'
(gdb)

> The problem comes when I create a Lazarus GUI application and set -gw3 > there.

[Snip]

Can you create a simple test-program that shows this behavior and post it as a bug?

Done:
#17651: Lazarus application fails to link when built with -gw3

Regards,
Juha

Maxim Ganetsky wrote

Can you correct your time please?

Ok, I fixed it now. This mail should have a correct time stamp. I don't know why it happens but dual-booting to Windows Vista always messes the time. There are some youngsters who use this "super-computer" for 3-D games on Windows.
I will try to check the time after booting.

Juha

17.10.2010 20:01, Juha Manninen (gmail) ?????:

Thanks.

I also had and have problems with the real time, in dual boots and in virtual machines. One cause is DST, which can result in multiple updates of the BIOS time. It's unclear why this problem persists, when nowadays the system time is synced via Internet. The implementation of this feature sucks, in both Windows and Linux systems; in one case I had to disable the update of the hardware clock, on shutdown of openSuse. In Windows different problems exist, possibly with the automatic DST and UTC adjustment.

Actually the hardware clock can be set to either UTC (Linux) or to local time, with *or* without DST adjustment (Windows). When one Windows assumes DST adjusted time, and another one assumes unadjusted local time, every boot or shutdown will result in a different setting of the hardware clock :-(

There are some youngsters who use this "super-computer" for 3-D games on Windows.

Older games used to manipulate the system time, perhaps relicts from those "good ole days" still exist in current gaming libraries?

Unfortunately it's not a good idea to run games in a VM, so that this essentially simple solution would frustrate your youngsters, with even worse consequences to your nerves :-(

DoDi

Older games used to manipulate the system time, perhaps relicts from those "good ole days" still exist in current gaming libraries?

Very, very unlikely. I would even call it far-fetched.

R.