[fpc-devel] bounty: FPC based debugger
Hi, Speaking of the subject in another thread, and to show the desire I have to finding a solution to this [what I consider a very serious] problem FPC needs its own debugger! GDB is just rubbish when it comes to the Object Pascal language. Also if FPC had it's own debugger, the time it would take developers to benefit from new debugger features, would be much quicker that it currently takes with GDB. If anybody with the know how is interested in implementing a Object Pascal based debugger (or extending Duby specifically for use with FPC), please let me know. I am more than willing to pay a few hundred US dollars (or Euros) towards this bounty. So consider this an official bounty. If others want to add to this bounty, you are more than welcome. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
On 12 Sep 2011, at 08:56, Graeme Geldenhuys wrote: On 11/09/2011 23:40, Jonas Maebe wrote: extensions. I don't see the advantage of allocating one of those and communicating it to other compiler writers (to avoid them using that same extension for something else) instead of submitting it for inclusion in the official DWARF standard though. I understand that, but waiting for the DWARF specification to accept it, You don't have to wait until it is published. Both gcc and gdb supported provisional DWARF4 features before the standard was out. Simply asking for comments on the DWARF list and then posting it in their issue tracker is probably already enough. The point is simply to make sure that there is a fleshed out spec that can be implemented, rather than a hack that will have to be broken again next year because someone forgot about something, and which also will have to be maintained forever for compatibility with existing tools that implemented it (like the hack for shortstring support in Stabs). Is there any reason why you or somebody else in the FPC team, that knows DWARF, haven't submitted such a a proposal yet? What's the hold-up? That someone has to spend time on writing a formal specification, and preferably do some tests to flesh out at least some obvious shortcomings. That is quite a bit of work. The reasons I personally have not done that are a) I have no need whatsoever for debug information for properties b) there are plenty of other things to work on that I consider more interesting (also known as "time") Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Project Idea: Mini-FPC
P5 is also in an unusuable state. It should not be allowed to write code as follows: repeat if a < b then begin end until a < b; ^ This code should produce an error becomes end is not ended with a semicolon –> ; This confuses Delphi’s source beautifier, which could be seen as a short coming in Delphi’s source beautifier. I take indentation very seriously. Code with spaces is high risk of indentation mistakes. The P5 code is not properly indented. The risk of a indentation mistake (editing the wrong begin/end) is huge so I am not going to spent any further time on it. Until perhaps a source beautifier can correct the situation. But since the code is now probably undocumented The code does silly things like: end (* some comment *) ; ^ semi colon at the back ?!?!?!?!?!?!?!?!?!?!?!?!?!?! One little missing semi colon like that and all hell breaks loose, very unwise to write code like that. Better is to write: end; (* some comment *) This coding style is probably what causes some kind of indentation problem for the source beautifier. I fail to see how I could make sense of “proper identation” of an automated tool cannot ?!? Bye, Skybuck.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc and inherited methods
On Sun, 11 Sep 2011, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: I'm a user of fpdoc, not a maintainer, have no idea of the internals. In that case, please do not say things like 'this extension should not be too hard to implement' But please, file a bug report so we won't forget. This whole threads is about bugs and problems with FPDoc, in the hope that most can be fixed without extra bug reports. If I ask you to add this as a bug report it is because a) I indeed consider it a bug b) I realize it is not fixable in 10 minutes and hence will not be done anytime soon. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
On 12/09/2011 09:13, Jonas Maebe wrote: > > You don't have to wait until it is published. Both gcc and gdb > supported provisional DWARF4 features before the standard was out. And then standing the chance of it being reject - thus doing the implementation in GCC and GDB all for nothing. But maybe that would just be an extreme case. > The point is simply to make sure that there is a fleshed out spec that > can be implemented, So maybe one should start a wiki page regarding this, putting down some ideas that others can review and contribute towards? Building up towards a specification we can later submit to the DWARF guys. > b) there are plenty of other things to work on that I consider more > interesting (also known as "time") Would the incentive of money make it more "interesting"? ;-) See my bounty I just posted to the mailing list. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : [fpc-devel] duplicating a fcl-db bugreport with mysql
> Hello, > > Could sb with a recent trunk based system and mysql please > try to duplicate Mantis #15324? > > Thanks in advance. > ] > > Marco > On XP SP2 with fpc 2.7.1 rev 18901: < C:\Documents and Settings\Ludo\Mes documents\Lazarus Projects\test\leak0015324>leak.exe Heap dump by heaptrc unit 189 memory blocks allocated : 11362/12624 189 memory blocks freed : 11362/12624 0 unfreed memory blocks : 0 True heap size : 196608 (144 used in System startup) True free heap : 196464 C:\Documents and Settings\Ludo\Mes documents\Lazarus Projects\test\leak0015324> > No leak (anymore?), Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Project Idea: Mini-FPC
On 11/09/2011 13:51, Skybuck Flying wrote: > > The P5 code is not properly indented. Now you are on the border line of ridiculous! Simply run the code through JCF (Jedi Code Formatter), and the code will look exactly as you specified in all of 2 seconds! Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Project Idea: Mini-FPC
On Sun, Sep 11, 2011 at 1:51 PM, Skybuck Flying wrote: > ^ This code should produce an error becomes end is not ended with a > semicolon –> ; Looks like you are not aware that Pascal uses semicolon as separators, not statement enders. AFAIK the code you posted is valid, and so it is to write for example: procedure something; begin if X then begin end // <- no semi-colon end; If the identation program has issues with that then you found a bug. See: http://en.wikipedia.org/wiki/Comparison_of_Object_Pascal_and_C#Semicolon_use -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
On 12 Sep 2011, at 09:22, Graeme Geldenhuys wrote: So maybe one should start a wiki page regarding this, putting down some ideas that others can review and contribute towards? Building up towards a specification we can later submit to the DWARF guys. That certainly sounds like a good idea. Would the incentive of money make it more "interesting"? ;-) See my bounty I just posted to the mailing list. No, I have no interest in writing or maintaining a self-written debugger. Especially because on the platforms I primarily support (Mac OS X, iOS) the debugger interface with the OS is partially private and regularly changes between OS releases. Writing and maintaining a multi- platform debugger is not something you quickly do on the side and then forget about, it's a major project by itself that requires sustained development just like a compiler. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 2011-09-12 09:08, Graeme Geldenhuys wrote: Hi, Speaking of the subject in another thread, and to show the desire I have to finding a solution to this [what I consider a very serious] problem FPC needs its own debugger! GDB is just rubbish when it comes to the Object Pascal language. Also if FPC had it's own debugger, the time it would take developers to benefit from new debugger features, would be much quicker that it currently takes with GDB. If anybody with the know how is interested in implementing a Object Pascal based debugger (or extending Duby specifically for use with FPC), please let me know. I am more than willing to pay a few hundred US dollars (or Euros) towards this bounty. So consider this an official bounty. If others want to add to this bounty, you are more than welcome. Regards, - Graeme - I can +1 this post and add that my company is also willing to add a few hundred Euros to this bounty. I really miss the easy use of the Delphi debugger from D7. Especially the live inspection of object during single step of the code. Perhaps you Graeme will add this bounty to the wiki: http://wiki.freepascal.org/Bounties You can put me down as EpiData Association, with (at least) 250€. Kind regards, Torsten Bonde Christiansen. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] duplicating a fcl-db bugreport with mysql
In our previous episode, Ludo Brands said: > > < > C:\Documents and Settings\Ludo\Mes documents\Lazarus > Projects\test\leak0015324>leak.exe > > Heap dump by heaptrc unit > 189 memory blocks allocated : 11362/12624 > 189 memory blocks freed : 11362/12624 > 0 unfreed memory blocks : 0 > True heap size : 196608 (144 used in System startup) > True free heap : 196464 > > C:\Documents and Settings\Ludo\Mes documents\Lazarus > Projects\test\leak0015324> > > > > No leak (anymore?), Thanks. I set the bug to resolved. Afaik several memory leaks were patched during the last months. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc and inherited methods
On 09/11/2011 07:33 PM, Hans-Peter Diettrich wrote: No Latex support here (Win7) Virtual Box is your friend :-) . -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc and inherited methods
On 12/09/2011 10:21, Michael Schnell wrote: > On 09/11/2011 07:33 PM, Hans-Peter Diettrich wrote: >> No Latex support here (Win7) > Virtual Box is your friend :-) . Even easier, you get LaTeX for Windows too... I think it is called something like MiKTex. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc and inherited methods
In our previous episode, Graeme Geldenhuys said: > >> No Latex support here (Win7) > > Virtual Box is your friend :-) . > Even easier, you get LaTeX for Windows too... I think it is called > something like MiKTex. Even better, TeXLive has easy installers nowaday, and that is the TeX distro mostly used on *nix. I tried and it works if you do one manual at the time, but have to comment some unix shell script in Makefile.4ht which moves the generated files to a directory. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Project Idea: Mini-FPC
Skybuck Flying schrieb: end until a < b; ^ This code should produce an error becomes end is not ended with a semicolon –> ; Please understand Pascal first, before you try to modify it. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
Martin schrieb: More than that, Lazarus is not the only way to use the info, people use other IDEs or gdb directly => all that needs to be considered. You can't have one tool for everybody and everything. A debugger can not (and must not) know about all languages. Language specific support IMO should reside in another layer (IDE, plugin...) between the debugger and the user. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
Graeme Geldenhuys schrieb: Just the other day I had to use Delphi 7 again to do some maintenance on one of our older products. That's when I again came to the realization what dismal state FPC's debugging support is at - it's like travelling back in time to the early 80's where using writeln() was the normal debugging process. I'll happily pay the $800 licensing fee to Embarcadero if I could get at the same time much better debugging support under Linux. IMO debugging support was one of the reasons, why Kylix was based on Wine, and the cross-platform versions of Delphi use remote debugging only. For that implementation a tiny (remote) debugger interface is sufficient, and the IDE can implement all the language specific debug support. I'd be happy if somebody could tell me how to make all those "no such identifier in scope" messages disappear, that currently reduce debugging "support" to breakpoints, call stack and local variables. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
Graeme Geldenhuys schrieb: If anybody with the know how is interested in implementing a Object Pascal based debugger (or extending Duby specifically for use with FPC), please let me know. I am more than willing to pay a few hundred US dollars (or Euros) towards this bounty. I'd add another 100€ for reasonable debugging support in Lazarus :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 08:47, Torsten Bonde Christiansen wrote: I really miss the easy use of the Delphi debugger from D7. Especially the live inspection of object during single step of the code. In that case you (all involved) better specify the required features. The debugger itself (in my understanding) can either have a library-like interface or command-line driven or both. Representing the data in an object-inspector-like format (I guess that is what you mean) is part of a debugger frontend (such as is included in Lazarus). And btw, Lazarus does have an "Debug inspector" (context menu: "Debug" > "Inspect" or alt-F5) => So it appears it doesn't correctly refresh. Nor does it allow to unfold [+] any sub-classes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
On 12/09/2011 10:55, Hans-Peter Diettrich wrote: Martin schrieb: More than that, Lazarus is not the only way to use the info, people use other IDEs or gdb directly => all that needs to be considered. You can't have one tool for everybody and everything. A debugger can not (and must not) know about all languages. Language specific support IMO should reside in another layer (IDE, plugin...) between the debugger and the user. Never said that. My statement was about pascal (fpc) only. people debug fpc compiled code, in various ways. some use plain gdb, others use MSEIDE, some Lazarus, maybe some use other gdb frontends... Any debug info, encoded into the app must not prevent people from using any of those methods. That does not mean that all of those must understand the added info. By far not, only that all of them must not be stopped from using already present info, just because new info was added. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 09/12/2011 12:18 PM, Hans-Peter Diettrich wrote: I'd add another 100€ for reasonable debugging support in Lazarus :-) Could you generate a wish-List ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
On 12/09/2011 11:06, Hans-Peter Diettrich wrote: IMO debugging support was one of the reasons, why Kylix was based on Wine, and the cross-platform versions of Delphi use remote debugging only. For that implementation a tiny (remote) debugger interface is sufficient, and the IDE can implement all the language specific debug support. I'd be happy if somebody could tell me how to make all those "no such identifier in scope" messages disappear, that currently reduce debugging "support" to breakpoints, call stack and local variables. IMHO that's a bit exaggerated (the last line)? I do use plenty of watches, and never got any such message. Ok I know I can't see properties, and I do not try to do so. That leaves still plenty of ways to get information. Mind, I do NOT want to play down say that the lack of property support. Not to break an other war about how serious this is or is not. let everyone decide for themself. But to me a statement like the above, is simple wrong, as I do use Lazarus+gdb, and in 99% of my personal use cases (mostly debugging the IDE itself) it has not caused an issue. (Personally I thing such over exaggerated statements are made in some hope, that making things look worse, would get *others* to fix them => another of my experiences says, that does not work at all) Anyway, I started the topic exactly because I want the situation to be improved, and to see what can be done. yes, a none gdb debugger would be nice, infact it is on the list. but it will be a lot of time till then, and even than it will require the debug info. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 11:43, Martin wrote: > > The debugger itself (in my understanding) can either have a library-like > interface or command-line driven or both. Duby already has both (in rudimentary form). At this point I will be fine with a command-line debugger only, that can actually debug my code. Integration in a IDE (eg: like the GDB-MI interface) can come later. Duby even has instruction on how to integrate itself with Lazarus IDE, but I have never been able to get that to work for whatever reason. I've only used Duby from the command-line interface. Just being able to debug your code without requiring writeln() or log-to-file statements, would already be a 100x better than what we currently have. Here is what I would consider a "debugger": - command line interface at least - watches - breakpoints - expression handling with break points would be very handy. eg: break when i = 1234 - watchpoints. break when data at memory address changed. Very handy to debug those procedural programs that loves to use global variables. MSEide supports this (but it is actually a GDB feature) - querying variables, properties, arrays, strings. Irrespective if things like variables are local, global, or if parameters are from a nested function, method, event handler. Querying properties of a class instance (like can be done in Delphi for years) is very important (irrespective of the "potential" dangers in that). - Object Pascal expression evaluation (but I guess this goes hand-in-hand with Watches and Breakpoints. Yes I know there are many other items than can be added (thread debugging, remote debugging etc), but I would consider the above features a "usable debugger" with FPC. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 11:10, Graeme Geldenhuys wrote: Here is what I would consider a "debugger": - command line interface at least - watches since lazarus displays watches, using gdb, maybe this should be more specific? - Yes, certain expressions are not supported, or not well supported. -- strings: 0 vs 1 base => need to test with stabs 3 => need to adapt some part of Lazarus to deal with gdb output when using stabs3 -- properties: discussed before -- dyn-arrays: lazarus deals with simple cases, but by far not with all -- please add? - breakpoints - expression handling with break points would be very handy. eg: break when i = 1234 Lazarus does support conditional expressions. And they do work, I have used them - watchpoints. break when data at memory address changed. Very handy to debug those procedural programs that loves to use global variables. MSEide supports this (but it is actually a GDB feature) Yes indeed. Btw, i have used them a few times in Lazarus. they are on the todo list Though to use them in Lazarus, quite a few hacks are required. The big issue, is that gdb often scopes them wrong, and you loose the watch point before you it triggers - querying variables, properties, arrays, strings. Irrespective if things like variables are local, global, or if parameters are from a nested function, method, event handler. Querying properties of a class instance (like can be done in Delphi for years) is very important (irrespective of the "potential" dangers in that). That is a repeat of "watches" ? - Object Pascal expression evaluation (but I guess this goes hand-in-hand with Watches and Breakpoints. Yes I know there are many other items than can be added (thread debugging, remote debugging etc), but I would consider the above features a "usable debugger" with FPC. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
Martin wrote: On 12/09/2011 08:47, Torsten Bonde Christiansen wrote: I really miss the easy use of the Delphi debugger from D7. Especially the live inspection of object during single step of the code. In that case you (all involved) better specify the required features. The debugger itself (in my understanding) can either have a library-like interface or command-line driven or both. Allowing that gdb is implemented over a wide variety of CPUs and OSes, I wonder whether it would make more sense to "adopt" libgdb than writing something from scratch? I've managed to compile this and incorporate it into the fp IDE for a number of Linux platforms, with the exception of ARM which was problematic. I can't remember the extent to which I've tried for Windows and Solaris. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
12.09.2011 11:08, Graeme Geldenhuys: [...] If anybody with the know how is interested in implementing a Object Pascal based debugger (or extending Duby specifically for use with FPC), please let me know. I am more than willing to pay a few hundred US dollars (or Euros) towards this bounty. I'd also happily contribute $300 or so (in case there is a reasonable chance to actually get it working at least on windows/linux/bsd) However, the effort needed is probably much much more expensive (Supposedly some pretty skilled developer(s) would have to work hard for several months, therefore it would then cost several thousands $ or more...) Nikolai So consider this an official bounty. If others want to add to this bounty, you are more than welcome. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 12:23:44 Martin wrote: > > - watchpoints. break when data at memory address changed. Very > > > > handy to debug those procedural programs that loves to use global > > variables. MSEide supports this (but it is actually a GDB feature) > > Yes indeed. > > Btw, i have used them a few times in Lazarus. they are on the todo list > > Though to use them in Lazarus, quite a few hacks are required. > > The big issue, is that gdb often scopes them wrong, and you loose the > watch point before you it triggers > MSEide has popup menu functions 'Address Watchpoint 8', 'Address Watchpoint 16', 'Address Watchpoint 32' and 'Address Watchpoint 64' in watch window in order to prevent gdb from dropping the watchpoint. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 11:51, Martin Schreiber wrote: The big issue, is that gdb often scopes them wrong, and you loose the watch point before you it triggers MSEide has popup menu functions 'Address Watchpoint 8', 'Address Watchpoint 16', 'Address Watchpoint 32' and 'Address Watchpoint 64' in watch window in order to prevent gdb from dropping the watchpoint. ah, yes I was planning on doing the same thing ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 12:45:40 Nikolai Zhubr wrote: > 12.09.2011 11:08, Graeme Geldenhuys: > [...] > > > If anybody with the know how is interested in implementing a Object > > Pascal based debugger (or extending Duby specifically for use with FPC), > > please let me know. I am more than willing to pay a few hundred US > > dollars (or Euros) towards this bounty. > > I'd also happily contribute $300 or so (in case there is a reasonable > chance to actually get it working at least on windows/linux/bsd) > > However, the effort needed is probably much much more expensive > (Supposedly some pretty skilled developer(s) would have to work hard for > several months, therefore it would then cost several thousands $ or > more...) > True. And maintaining all platforms is a fulltime job too. And a FPC only debugger can not debug linked c libraries which we can do currently with gdb. And think of the remote debugging options gdb provides with many targets. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/11 12:00, Martin Schreiber wrote: And a FPC only debugger can not debug linked c libraries which we can do Good point. I've found this very handy in the past. currently with gdb. And think of the remote debugging options gdb provides with many targets. Another one very handy for embedded developers. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 09/12/2011 12:10 PM, Graeme Geldenhuys wrote: - watchpoints. break when data at memory address changed. Very handy to debug those procedural programs that loves to use global variables. MSEide supports this (but it is actually a GDB feature) Ooops. (Without hardware support) This would need the debugger to run the program completely in single step mode and after each step check the condition. - Object Pascal expression evaluation A think object pascal expression evaluator software is available in Pascal source code so this should be doable. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 13:08:31 Michael Schnell wrote: > On 09/12/2011 12:10 PM, Graeme Geldenhuys wrote: > > - watchpoints. break when data at memory address changed. Very > > > > handy to debug those procedural programs that loves to use global > > variables. MSEide supports this (but it is actually a GDB feature) > > Ooops. (Without hardware support) This would need the debugger to run > the program completely in single step mode and after each step check the > condition. > gdb uses hardware watchpoint support if available. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 13:00, Martin Schreiber wrote: > > True. And maintaining all platforms is a fulltime job too. Maintenance should be MUCH less work than the initial implementation. So I don't consider this too a big problem. FPC doesn't change that radically that often. > And a FPC only debugger can not debug linked c libraries which we can do Then use GDB for such cases. > currently with gdb. And think of the remote debugging options gdb provides > with many targets. As I mentioned, there are many additional features that could be added to a "debugger". But for an initial implementation, I think what I listed should suffice to most often used cases. GDB wasn't developer overnight, neither would a FPC debugger. But that is no reason, not to implement one. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
12.09.2011 15:01, Henry Vermaak: On 12/09/11 12:00, Martin Schreiber wrote: And a FPC only debugger can not debug linked c libraries which we can do Good point. I've found this very handy in the past. currently with gdb. And think of the remote debugging options gdb provides with many targets. Another one very handy for embedded developers. Well maybe this could be resolved by allowing to select either gdb or another hypothetical debugger at runtime, if designed as kind of plugin. No feature loss would then happen, compared to current state. That would be even more work, though :( Nikolai Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
12.09.2011 19:00, Martin Schreiber wrote: True. And maintaining all platforms is a fulltime job too. And a FPC only debugger can not debug linked c libraries which we can do currently with gdb. And think of the remote debugging options gdb provides with many targets. As I understand the plan is to create a new debugger without destroying what we already have with gdb. At the moment Lazarus allows to write debugger plugins. When the new debugger is ready the new plugin should be written. As result you should be able to debug linked c libraries as before with gdb and to debug other code with the new debugger. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 13:12:11 Graeme Geldenhuys wrote: > On 12/09/2011 13:00, Martin Schreiber wrote: > > True. And maintaining all platforms is a fulltime job too. > > Maintenance should be MUCH less work than the initial implementation. So > I don't consider this too a big problem. FPC doesn't change that > radically that often. > The platforms change too. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 12:45, Nikolai Zhubr wrote: > > I'd also happily contribute $300 or so (in case there is a reasonable > chance to actually get it working at least on windows/linux/bsd) > > However, the effort needed is probably much much more expensive Well, considering the about of people that are already willing to contribute money towards the bounty, a reasonable sum of money should be on offer in the end. The many responses also clearly indicate the demand for a "working" debugger. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 13:16:58 Graeme Geldenhuys wrote: > On 12/09/2011 12:45, Nikolai Zhubr wrote: > > I'd also happily contribute $300 or so (in case there is a reasonable > > chance to actually get it working at least on windows/linux/bsd) > > > > However, the effort needed is probably much much more expensive > > Well, considering the about of people that are already willing to > contribute money towards the bounty, a reasonable sum of money should be > on offer in the end. > ??? EUR 100'000..200'000? Really? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 13:16:21 Paul Ishenin wrote: > 12.09.2011 19:00, Martin Schreiber wrote: > > True. And maintaining all platforms is a fulltime job too. And a FPC > > only debugger can not debug linked c libraries which we can do > > currently with gdb. And think of the remote debugging options gdb > > provides with many targets. > > As I understand the plan is to create a new debugger without destroying > what we already have with gdb. At the moment Lazarus allows to write > debugger plugins. When the new debugger is ready the new plugin should > be written. > > As result you should be able to debug linked c libraries as before with > gdb and to debug other code with the new debugger. > I think it is better to invest time into gdb support instead into a FPC debugger which probably never will reach a usable state. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 13:32, Martin Schreiber wrote: > > I think it is better to invest time into gdb support instead into a FPC > debugger which probably never will reach a usable state. [sarcasm on] With that attitude the same could be applied to MSEide, MSEgui and fpGUI too. Why did we bother investing time and effort into developing such frameworks or IDE's, when the should rather have invested our time in Lazarus?? Then again, why did somebody invest in FPC when we could simply have used the de-facto standard Object Pascal compiler - Delphi, stick to Windows (which covers 90% of the market). [sarcasm off] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 13:30, Martin Schreiber wrote: > ??? > EUR 100'000..200'000? Really? Yes, we all know your rates a much higher than others - so we will not ask you to do the work. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 13:36:43 Graeme Geldenhuys wrote: > On 12/09/2011 13:32, Martin Schreiber wrote: > > I think it is better to invest time into gdb support instead into a FPC > > debugger which probably never will reach a usable state. > > [sarcasm on] > With that attitude the same could be applied to MSEide, MSEgui and fpGUI > too. Why did we bother investing time and effort into developing such > frameworks or IDE's, when the should rather have invested our time in > Lazarus?? Then again, why did somebody invest in FPC when we could > simply have used the de-facto standard Object Pascal compiler - Delphi, > stick to Windows (which covers 90% of the market). > [sarcasm off] > True. And because we know what it means to develop something new from scratch and because I know that I don't want to invest several years into development of a FPC debugger and because we know that there are not so many people who can make such a development and are able to *finish* the project I suggest to concentrate on gdb. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
12.09.2011 19:36, Graeme Geldenhuys wrote: On 12/09/2011 13:32, Martin Schreiber wrote: I think it is better to invest time into gdb support instead into a FPC debugger which probably never will reach a usable state. [sarcasm on] With that attitude the same could be applied to MSEide, MSEgui and fpGUI too. Why did we bother investing time and effort into developing such frameworks or IDE's, when the should rather have invested our time in Lazarus?? I also want to know. Imo, you are loosing your time :) Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? On 11/09/2011 23:15, Martin wrote: Like it was done for properties that directly map to a field. The now are somehow encoded, so the field is read. BTW anyone, why is that dwarf only => could stabs not just define another entry under the property name? Even then it would be a long way, because it would only be in fpc 2.6.2 (if merged) or 2.8.0; before a lazarus release would benefit. On the other hand it would anyway take time for lazarus to be adapted to use the info. And currently the info would have to be readable through gdb, something I hope to change in future. More than that, Lazarus is not the only way to use the info, people use other IDEs or gdb directly => all that needs to be considered. Also there are (at least to me) 2 levels. 1) Make available the info that a property exists, even if no way exists to access it. (via gdb) 2) access to the data, or information about hpw to access (pointer to getter/setter functions) (via gdb) The first would simply mean that something in the "ptype" result of a class indicates the presence of a property Of course, if the property already maps (aliases) the field (if directly mapped to field) then it is impossible for ptype to return a different result, than the type of the field. And returning the content of the field is essential, especially if fields themself are structured types (classes). FooObject.BarObjFieldProperty.BarValue only works with the current "alias" solution. While an IDE could transform the expression, if really that was needed, a user using gdb directly would relay on this working (and for an IDE it is much easier and leads to better performance, if that is working) That already defies the idea of encoding properties as structure (actually differnet properties = diff structures) with a field for getter and setter. The structure could have been identified as property by a none pascal name (like the $fp framepointer in nested functions) The structure approach would have been nice, as it would have provided the info about the property in place of the real property name. - It would have been fine if FooObject.BarObjFieldProperty would return and display the whole structure. An IDE can deal with it, and a gdb user can still read it (assuming that the structure displays all it's values, rather than just an address) - But it would break FooObject.BarObjFieldProperty.BarValue . Unless the "." after the property can be tought to be an operator that uses the "read-value" field (if it is a field) (and similar for arras with []) I am not sure if something like this can be done (and reliable with current gdb versions) --- Another approach, by far not as nice: - Leave the getter as is / maybe add getters with function to declare the property to be the same as the read function. - And add another field PropertyName$Set with the setter info Accessing a property in value evaluation would work as it does now. An IDE getting a "ptype" could detect the xxx$Set entries, match the getters, and know what is a property => even have a way of modifying them, if it can do code-execution for that purpose... Alternative xxx$Property with a record (or xxx$Set / xxx$get), to provide info about properties; but leave the actual name mapped to the field (were appropriate) so the expression evaluation would still work ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 13:49, Martin Schreiber wrote: > True. And because we know what it means to develop something new from scratch > and because I know that I don't want to invest several years into development > of a FPC debugger and because we know that there are not so many people who Please have a look at some of the Google Summer of Code projects. Some people can do amazing things in a fraction of the time it takes others. Oh, and they [Google Summer of Code entrants] don't get paid hundreds of thousands of euros for their work either. So how much did you benefit from the FPC project so far? And how much did you pay for FPC? Oh. Never thought of contributing back, have you? > can make such a development and are able to *finish* the project I suggest to > concentrate on gdb. Fine, so we all now know that YOU are not interested in the project, so lets leave it at that. In the mean time, I'll just continue the work in my little spare time I have, so maybe some day at least one person can benefit from it. I just thought, by offering a bounty, the work could possibly be done in a fraction of the time than what it would take me. My thoughts was that if it was written in Object Pascal, more people [in the FPC community] might be able to contribute and help here and there, just like what is done in FPC, Lazarus, fpGUI etc. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12 Sep 2011, at 12:23, Martin wrote: The big issue, is that gdb often scopes them wrong, and you loose the watch point before you it triggers If you use an expression in a watch point, gdb will reevaluate that expression if a value used in the watch expression changes. Since in general you don't want that, you can take the address of the watched value once when the watchpoint is enabled and then put a watchpoint on that calculated address (similar to what Martin Schreiber said). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 13:07, Graeme Geldenhuys wrote: On 12/09/2011 13:49, Martin Schreiber wrote: True. And because we know what it means to develop something new from scratch and because I know that I don't want to invest several years into development of a FPC debugger and because we know that there are not so many people who Please have a look at some of the Google Summer of Code projects. Some people can do amazing things in a fraction of the time it takes others. Oh, and they [Google Summer of Code entrants] don't get paid hundreds of thousands of euros for their work either. So how much did you benefit from the FPC project so far? And how much did you pay for FPC? Oh. Never thought of contributing back, have you? I think Greame, that is not very well worded. Whatever you attempted to express... I believe that Martin Schreiber has contributed back quite well. By providing an excellent IDE, he helps spreading fpc. And that is a huge contribution. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 14:07, Paul Ishenin wrote: > I also want to know. Imo, you are loosing your time :) [off-topic: so this will be my last public response to this] No, fpGUI has now reached a point where I can knock out apps in a fraction of the time it took me 5 years ago. Also those apps are considerably more stable and consistent across platforms than what Lazarus could offer. So the time was well spent - and I enjoyed it! :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 09/12/2011 01:15 PM, Martin Schreiber wrote: gdb uses hardware watchpoint support if available. That seems hard to beat when doing a new multi-arch debugger -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 13:11, Jonas Maebe wrote: On 12 Sep 2011, at 12:23, Martin wrote: The big issue, is that gdb often scopes them wrong, and you loose the watch point before you it triggers If you use an expression in a watch point, gdb will reevaluate that expression if a value used in the watch expression changes. Since in general you don't want that, you can take the address of the watched value once when the watchpoint is enabled and then put a watchpoint on that calculated address (similar to what Martin Schreiber said). Yes, I know that, and done that too. BTW, another issue with watchpoint is, that gdb 9latest tested with 7.2, need to test 7.3) warns you to late => actually applies to any breakpoint that can not be set) If you have more watchpoints than gdb can set (or any other breakpoint fails the following happens (depends on gdbn version) [gdb paused] - inserting watch abnd breakpoints] - send step or run command [ gdb will print warnings / not error] [gdb will step or partly step] - send step or run command again [gdb will give an error, about the watch/breakpoints] on that first partly step, something could have happen to the watched value... I need to see if that is fixed in gdb 7.3 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On Monday 12 September 2011 14:20:06 Michael Schnell wrote: > On 09/12/2011 01:15 PM, Martin Schreiber wrote: > > gdb uses hardware watchpoint support if available. > > That seems hard to beat when doing a new multi-arch debugger > Correct. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
12.09.2011 15:08, Graeme Geldenhuys wrote: So consider this an official bounty. If others want to add to this bounty, you are more than welcome. I suggest to create a wiki page with: 1) at least brief specification 2) a list of sponsors 3) a list of jury members 4) acceptance criteria Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
- "Graeme Geldenhuys" schreef: > On 12/09/2011 13:30, Martin Schreiber wrote: > > ??? > > EUR 100'000..200'000? Really? > > > Yes, we all know your rates a much higher than others - so we will > not > ask you to do the work. > > Graeme, I think you underestimate the work required when doing it from scratch (or from Duby, which, from what I can see hasn't released anything to tinker with yet on their sf.net page). That said, even when I think of the entry-level programming fee (no freelance/consultant) a professional developer gets a month in my country (Belgium), and divided by 20 to get a "daily" fee from it, it still is 125 euro before taxes etc (after which you have about 3/5 left). When you take into account the "black market" or "undeclared sidejob" as opposed to "hobby", that could go down to 50 or so. But still, it would take quite some more effort than "a few 1000 euro's" in manhours, especially for those "programmers with experience" (whom have a higher "cost" ofcourse). I don't disagree with the need for a prime debugger, nor with the amounts of bounty everyone is offering, just with the statements above. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Error compiling trunk
I'm trying to compile from svn trunk on Win32, but I get this when I do "make clean all": Free Pascal Compiler version 2.4.4 [2011/04/23] for i386 Copyright (c) 1993-2010 by Florian Klaempfl Target OS: Win32 for i386 Compiling fpmake.pp fpmake.pp(20,51) Error: Identifier not found "iPhoneSim" fpmake.pp(198) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make.exe[3]: *** [fpmake] Error 1 make.exe[3]: Leaving directory `E:/fpc/packages/fcl-base' make.exe[2]: *** [fcl-base_smart] Error 2 make.exe[2]: Leaving directory `E:/fpc/packages' make.exe[1]: *** [packages_smart] Error 2 make.exe[1]: Leaving directory `E:/fpc' ..\FPC-bin\bin\i386-win32\make.exe: *** [build-stamp.i386-win32] Error 2 Leonardo M. Ramé http://leonardorame.blogspot.com___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error compiling trunk
On 12 Sep 2011, at 15:48, Leonardo M. Ramé wrote: I'm trying to compile from svn trunk on Win32, but I get this when I do "make clean all": Try manually deleting all "units" directories under fpc/packages/*. In general, you should always perform a "make distclean" *before* updating from svn to prevent risking stale units from surviving forever (in case they are moved). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 14:57, Dimitri Smits wrote: > > I don't disagree with the need for a prime debugger, nor with the > amounts of bounty everyone is offering, just with the statements > above. I still stand with my statement that it will NOT cost 100,000 - 200,000 euros to get a basic working debugger! Then you should also keep an open mind that this is an open-source project - thus costs are generally much lower to commercial counterparts. Why, because it is often done part-time with no or little time constraints, by developers that love to improve open-source software. It's for the love of programming, not just to get rich. Then also deduct the cost you saved from getting FPC and its stacks of tools, components and high quality documentation for FREE. Embarcadero will charge you $3500 for something similar, but which lacks in many other areas compared to Free Pascal. Not to mention that EMB forces you to re-purchase a new version/upgrade after every release - roughly once every 12-18 months. It's simple really. If nobody is interested, that is fine too! I'll continue my efforts either way, albeit much slower than somebody that has more free time than I, or that is more experienced in the subject than I. It's a great learning experience for me already, so I don't consider my time waisted so far. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Comparison FPC 2.4.4 - FPC fixes_2_6 - Delphi 7
Hi, I compiled MSEide with FPC 2.4.4, FPC fixes_2_6 and Delphi 7 for comparison. Delphi 7: Borland Delphi Version 15.0 Copyright (c) 1983,2002 Borland Software Corporation [...] 308390 lines, 6.20 seconds, 2279788 bytes code, 827729 bytes data. Exe size: 3.23MB FPC 2.4.4: Free Pascal Compiler version 2.4.4 [2011/04/23] for i386 Copyright (c) 1993-2010 by Florian Klaempfl Target OS: Win32 for i386 [...] 307589 lines compiled, 45.0 sec , 2280160 bytes code, 1706696 bytes data Exe size: 3.82 MB FPC fixes_2_6: Free Pascal Compiler version 2.5.1 [2011/09/11] for i386 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Win32 for i386 [...] 307589 lines compiled, 41.9 sec , 2350144 bytes code, 1719420 bytes data Exe size: 3.90 MB Source: http://svn.berlios.de/viewvc/mseide-msegui/trunk/ Commandline Delphi: dcc32.exe -B -I..\..\lib\common\kernel -U..\..\lib\common\kernel -U..\..\lib\common\kernel\i386-win32 -U..\..\lib\common\graphics -U..\..\lib\common\image -U..\..\lib\common\widgets -U..\..\lib\common\ifi -U..\..\lib\common\printer -U..\..\lib\common\designutils -U..\..\lib\common\sysutils -U..\..\lib\common\editwidgets -U..\..\lib\common\dialogs -U..\..\lib\common\regcomponents -U..\..\lib\common\serialcomm -U..\..\lib\common\delphicompatibility -dmse_no_db -dmse_no_opengl -dmse_no_math mseide.pas Commandline FPC: ppc386.exe -O2 -CX -XX -Xs -B -Fi..\..\lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\kernel\i386-win32 -Fu..\..\lib\common\graphics -Fu..\..\lib\common\image -Fu..\..\lib\common\widgets -Fu..\..\lib\common\ifi -Fu..\..\lib\common\printer -Fu..\..\lib\common\designutils -Fu..\..\lib\common\sysutils -Fu..\..\lib\common\editwidgets -Fu..\..\lib\common\dialogs -Fu..\..\lib\common\regcomponents -Fu..\..\lib\common\serialcomm -dmse_no_db -dmse_no_opengl -dmse_no_math -omseidefpc.exe mseide.pas All MSE *.o,*.ppu and *.dcu files deleted before compiling. System: win2000, AMD Athlon XP 3000+, 1GB RAM Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12 Sep 2011, at 14:07, Martin wrote: > Anyone care to comment on those ideas? > > Are they worth to be made a feature request? > And if so, which of the proposed ideas should be made into a feature request? I really don't like hacks like that. They will have to be maintained almost forever because tools will rely on them, just like the previously mentioned hack for shortstrings (they're also represented using a fake record). While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 18:32, Jonas Maebe wrote: On 12 Sep 2011, at 14:07, Martin wrote: Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? I really don't like hacks like that. They will have to be maintained almost forever because tools will rely on them, just like the previously mentioned hack for shortstrings (they're also represented using a fake record). While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. Using codetools is currently in discussion. There is someone who might contribute towards that. If it is done, it will be used anyway, since it will not have to wait for another fpc release. But I don't think it is the preferable solution, if symbols could somehow be provided by debug info means. (even, i they would require an extra switch at compile time / though from your comment that doesn't change the issue). Adding declared-in-unit info: not sure if it will help much. afaik codetools has no problem finding that. Also it would rely on gdb being able to return this info. And currently all is done through gdb. I do plan in future to read dwarf directly, that will solve other issues. But of course it can again only provide info that is present ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 19:08, Martin wrote: On 12/09/2011 18:32, Jonas Maebe wrote: On 12 Sep 2011, at 14:07, Martin wrote: Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? I really don't like hacks like that. They will have to be maintained almost forever because tools will rely on them, just like the previously mentioned hack for shortstrings (they're also represented using a fake record). While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. A less drastic idea: Currently properties that map to a field are already present in dwarf (again why not in stabs?). Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so public property Counter: Integer read GetCounter could appear the same as the function "GetCounter" ? In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 19:14, Martin wrote: On 12/09/2011 19:08, Martin wrote: On 12/09/2011 18:32, Jonas Maebe wrote: While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible because you don't know which unit the type is declared in: DWARF supports adding information about where an entity is declared to the debug information. While FPC currently does not do that, this is something that could be added if it would help you. A less drastic idea: Currently properties that map to a field are already present in dwarf (again why not in stabs?). Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so public property Counter: Integer read GetCounter could appear the same as the function "GetCounter" ? In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field. Maybe they can even in both cases (field or function) be encoded as "internal pointer" (the same that is used vor "var param" or objects, if I underatnad them correctly? They do auto deref if used , but in ptype some gdb show them , so they can be detected (and where gdb does not show them special, they will be detectable if debug info is read by the IDE, bypassing gdb (planned for future)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12 Sep 2011, at 20:20, Martin wrote: > On 12/09/2011 19:14, Martin wrote: >> Currently properties that map to a field are already present in dwarf (again >> why not in stabs?). Because Stabs is legacy and I don't want to spend time on it. >> Could not properties mapping to a function be implemented the same way => >> normal functions are already listed in "ptype" so >> public >> property Counter: Integer read GetCounter >> could appear the same as the function "GetCounter" ? >> >> In that case at least the list of available symbols is complete. The only >> thing that then would need codetools involved was to check if the name is a >> property and not a function/field. That may be possible, yes. > Maybe they can even in both cases (field or function) be encoded as "internal > pointer" (the same that is used vor "var param" or objects, if I underatnad > them correctly? > > They do auto deref if used , but in ptype some gdb show them , so they can be > detected (and where gdb does not show them special, they will be detectable > if debug info is read by the IDE, bypassing gdb (planned for future)) I don't understand this idea. A var parameter is in fact a pointer at the machine code level. A field or method used to implement a property isn't in any way different from other fields or methods. You probably also should not rely on var-parameters being shown as pointer types in gdb, since that's most likely a gdb implementation detail. > Adding declared-in-unit info: not sure if it will help much. afaik codetools > has no problem finding that. It cannot know from which unit the type comes. It's even not necessarily a type that is visible in the current unit. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 19:31, Jonas Maebe wrote: On 12 Sep 2011, at 20:20, Martin wrote: Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so public property Counter: Integer read GetCounter could appear the same as the function "GetCounter" ? In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field. That may be possible, yes. That would be good... :) Maybe they can even in both cases (field or function) be encoded as "internal pointer" (the same that is used vor "var param" or objects, if I underatnad them correctly? They do auto deref if used , but in ptype some gdb show them , so they can be detected (and where gdb does not show them special, they will be detectable if debug info is read by the IDE, bypassing gdb (planned for future)) I don't understand this idea. A var parameter is in fact a pointer at the machine code level. A field or method used to implement a property isn't in any way different from other fields or methods. You probably also should not rely on var-parameters being shown as pointer types in gdb, since that's most likely a gdb implementation detail. You are right that wasn't thought through. They can't be, there is no pointer-value I was looking if there is by any chance any kind of small flag that could be embedded. yet would not chnage the behaviour for gdb. Double nice if it can be displayed via gdb, but even if not, then in future the IDE could read it. I have not much knowledge of dwarf yet, so all my ideas are more or less random attempt... what is DW_AT_sibling used for? could a property be a sibling of the field? from dwarf 3 specs: In cases where a producer of debugging information feels that it will be important for consumers of that information to quickly scan chains of sibling entries, while ignoring the children of individual siblings, that producer may attach a DW_AT_sibling attribute to any debugging information entry. The value of this attribute is a reference to the sibling entry of the entry to which the attribute is attached Sounds like it is just like a "hint" that any compiler (debug-info-producer) can add as it wants? Adding declared-in-unit info: not sure if it will help much. afaik codetools has no problem finding that. It cannot know from which unit the type comes. It's even not necessarily a type that is visible in the current unit. That depends: if we speak of the declared type => then it should be visible? if we speak of the actual instance type => then true. We are not talking about virtual methods. (though we might get there, if we have to resolve a function) We are speaking about properties. IIRC, if a property gets re-declared in child classes, then resolution is by declared type? --- I am sure there is a lot more that could be added. I saw thereeven is a field for "with" blocks. And there will be a need for variables from parents in case of nested procedures procedure Outer; var i: integer; procedure Middle; procedure Inner; begin writeln(i); // from outer end; var i: integer; // middle // not in scope for inner begin end; begin end; Currently we just search parent frames => but that means to get the "i" from middle. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote: > On 12 Sep 2011, at 20:20, Martin wrote: > > > On 12/09/2011 19:14, Martin wrote: > >> Currently properties that map to a field are already present in dwarf > >> (again why not in stabs?). > > Because Stabs is legacy and I don't want to spend time on it. > > >> Could not properties mapping to a function be implemented the same way => > >> normal functions are already listed in "ptype" so > >> public > >> property Counter: Integer read GetCounter > >> could appear the same as the function "GetCounter" ? > >> > >> In that case at least the list of available symbols is complete. The only > >> thing that then would need codetools involved was to check if the name is > >> a property and not a function/field. > > That may be possible, yes. What is it that we actually need? At the Dwarf-level: Is the information that a property actually has a getter, and the name of that getter enough? Or do we want that when the value of a property is asked, the getter is called automagically? (And that there is some kind of flag that indicates that a getter is being used?) I don't think that we can add a stack-script in the DW_AT_Location that executes the getter. I've looked at DW_OP_call, but that won't help us here. Or, and maybe this is the best solution: some 'opaque' type that returns a reference to something else. Which can be different for reading and writing values... Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Calling methods from within gdb
Hi all, Does someone knows a trick how to make gdb call a method (function) from a class? When I have this class defined, compiled with dwarf2: (-gw3 gives an IE, I'll have a look at that too) type TMyClass = class public function Read: integer; end; ptype returns: (gdb) ptype aclass type = ^TMYCLASS = class : public TOBJECT public function READ () : LONGINT; end Which seems ok to me, but something like print or call gives: (gdb) call aclass^.READ() Type TMYCLASS = class has no component named READ(). Is there some syntactical trick that makes this work, or do I have to debug gdb again? -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
On 12/09/2011 20:46, Joost van der Sluis wrote: On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote: On 12 Sep 2011, at 20:20, Martin wrote: Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so public property Counter: Integer read GetCounter could appear the same as the function "GetCounter" ? In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field. That may be possible, yes. What is it that we actually need? At the Dwarf-level: Is the information that a property actually has a getter, and the name of that getter enough? Or do we want that when the value of a property is asked, the getter is called automagically? (And that there is some kind of flag that indicates that a getter is being used?) I don't think that we can add a stack-script in the DW_AT_Location that executes the getter. I've looked at DW_OP_call, but that won't help us here. Or, and maybe this is the best solution: some 'opaque' type that returns a reference to something else. Which can be different for reading and writing values... There are 2 conflicting desires. -data-evaluate-expression FooObject.BarObjProp.BarValue ptype FooObject / ptype FooObject.BarObjProp The first only works, ( at current) if it is a field, not a getter function. IMHO that is ok. While alot of people do want code execution for properties, there must be a mean of control (in the front end, e.g lazarus). Even if that was enabled by default. That means, I would like that gdb does *not* automatically call the function. So for data evaluation we are fine. If it is a function, the expression fails, and the IDE needs to look into it. Well having said that. If the function was only called, if brackets are supplied, maybe. -data-evaluate-expression FooObject.BarObjProp().BarValue But it is not a must. I am not even sure if desirable. the 2nd issue is knowledge that a) a there is something in the object under the name of the property b) this something happens to be a property a) is already fulfilled if it is a field-property. Hence I asked, if functions could be added the same way. -data-evaluate-expression FooObject.GetCounter currently gets no value -data-evaluate-expression FooObject.Counter gives an error, "no symbol" if Counter could be the same as GetCounter (making it effectively a function of the object), then at least the symbol was present. And at the same time, this solves the question of "does it get executed or not" => same rules as for "GetCounter" b) The above of course does make no difference between it being a property or just a function. for normal evaluation, this may most times make no difference. But for "debug inspector" type windows (that offer an object inspector like view of the object, with values) it may make a diff. If the users setting is to auo-execute properties, then properties would be executed => but functions would not. So then it would be desirable, if there was any indicator between a function (or even field), and a property. Ideally this difference would be viewable via gdb => but that is not even a must. Eventually the IDE will read dwarf directly, at which time it could make use of it. - As for the whole "auto execution": I do not know what the options are => I have not even checked all the means of controlling it in gdb --- I know, that given that the IDE anyway hasn't support for it yet, it is a very early request. But support in the IDE is hard to implement, if the feature cannot be tested. And also given that it will take time until the feature is present in a release, it is neer to early to ask ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Calling methods from within gdb
On 12 Sep 2011, at 22:05, Joost van der Sluis wrote: > Does someone knows a trick how to make gdb call a method (function) from > a class? It requires a patch to gdb. I'm fairly sure I already sent it to you in the past. It was part of an, incomplete, patch set to also add support for the Borland fastcall calling convention. The patch to add the method calling support was a hack though. I don't have those patches anymore because they were on a laptop that was stolen last year, but they may still be somewhere in my mail archive (I think I also sent them to Pierre once). I can only search for them in my mail tomorrow though (after having two laptops stolen, I've stopped allowing my mail client to cache my entire IMAP account locally; I'm not interested in the overhead of whole disk or home directory encryption). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
Martin schrieb: You can't have one tool for everybody and everything. A debugger can not (and must not) know about all languages. Language specific support IMO should reside in another layer (IDE, plugin...) between the debugger and the user. Never said that. My statement was about pascal (fpc) only. people debug fpc compiled code, in various ways. some use plain gdb, others use MSEIDE, some Lazarus, maybe some use other gdb frontends... IMO using gdb is not much more than using an disassembler, WRT inspecting values. Any debug info, encoded into the app must not prevent people from using any of those methods. That does not mean that all of those must understand the added info. By far not, only that all of them must not be stopped from using already present info, just because new info was added. I expect that RTTI is used by an FPC debugger, but I don't expect that external debuggers use RTTI, beyond their own (language independent) specs. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)
Martin schrieb: On 12/09/2011 11:06, Hans-Peter Diettrich wrote: IMO debugging support was one of the reasons, why Kylix was based on Wine, and the cross-platform versions of Delphi use remote debugging only. For that implementation a tiny (remote) debugger interface is sufficient, and the IDE can implement all the language specific debug support. I'd be happy if somebody could tell me how to make all those "no such identifier in scope" messages disappear, that currently reduce debugging "support" to breakpoints, call stack and local variables. IMHO that's a bit exaggerated (the last line)? I do use plenty of watches, and never got any such message. Ok I know I can't see properties, and I do not try to do so. That leaves still plenty of ways to get information. When 95% of the identifiers in a subroutine (method) can *not* be inspected, this makes an debugger somewhat useless to me. The hint window on e.g. Self provides some information, but only from the base classes - the remainder is out of view :-( Mind, I do NOT want to play down say that the lack of property support. I didn't notice until now that my problems may be related to properties. AFAIR I also couldn't inspect global variables. I'll watch out when debugging the next time. WRT inspecting properties I'd be happy with the content of the fields, where a property value is stored, e.g. TControl.FBoundsRect for Left or Right. Calling getter methods can be dangerous, I wouldn't expect such support. Again I only realize right now, that such a feature may require an hint in code, which property is stored or derived from which stored field. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
Michael Schnell schrieb: On 09/12/2011 12:18 PM, Hans-Peter Diettrich wrote: I'd add another 100€ for reasonable debugging support in Lazarus :-) Could you generate a wish-List ? For now: see my notes on Graeme's wish list. I haven't been debugging for a while, because it mostly ended up in frustration and adding DebugLn's and other hacks to the code :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
Graeme Geldenhuys schrieb:
Here is what I would consider a "debugger":
- command line interface at least
Me: GUI interface at least.
Where "GUI" is not a special property of the interface, only a set of
(callback) procedures that allow to implement desired language-specific
display features, regardless of GUI or Console display and use.
- watches
+1
- breakpoints
- expression handling with break points would be very handy.
eg: break when i = 1234
Nice to have, but I could live without this.
- watchpoints. break when data at memory address changed. Very
handy to debug those procedural programs that loves to use global
variables. MSEide supports this (but it is actually a GDB feature)
Again I could live without it, depending on the time required to
determine such changes. I've seen applications crawl when such a feature
was used :-(
- querying variables, properties, arrays, strings. Irrespective if
things like variables are local, global, or if parameters are from
a nested function, method, event handler. Querying properties of
a class instance (like can be done in Delphi for years) is very
important (irrespective of the "potential" dangers in that).
+1 (as far as calling getters can be avoided, somehow).
- Object Pascal expression evaluation (but I guess this goes
hand-in-hand with Watches and Breakpoints.
Nice to have.
Another wish: separation of debug info and debug code.
Currently I can't step into packages or FCL/RTL, without compiling these
first for debugging. But doing so puts in all the debug code
(output...), residing in the units. What I want is a dedicated option,
that provides everything required to debug the entire application,
without enabling special {$IFDEF DEBUG} code. Or did I simply miss
something already existing?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
Paul Ishenin schrieb: 12.09.2011 19:00, Martin Schreiber wrote: True. And maintaining all platforms is a fulltime job too. And a FPC only debugger can not debug linked c libraries which we can do currently with gdb. And think of the remote debugging options gdb provides with many targets. As I understand the plan is to create a new debugger without destroying what we already have with gdb. At the moment Lazarus allows to write debugger plugins. When the new debugger is ready the new plugin should be written. My wishes don't call for an new (platform dependent) debugger, I only want *better* high-level (language specific) support in Lazarus. Finally I want to debug applications, not an new debugger with different behaviour and restrictions on every platform ;-) In so far I'm not very interested in commandline and remote debugging, when these discourage the use of an already existing debugger (gdb...). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
debug hints in lazarus [Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]
cced to lazarus list. please switch list. On 12/09/2011 21:28, Hans-Peter Diettrich wrote: Martin schrieb: Mind, I do NOT want to play down say that the lack of property support. I didn't notice until now that my problems may be related to properties. AFAIR I also couldn't inspect global variables. I'll watch out when debugging the next time. 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 WRT inspecting properties I'd be happy with the content of the fields, where a property value is stored, e.g. TControl.FBoundsRect for Left or Right. Calling getter methods can be dangerous, I wouldn't expect such support. Again I only realize right now, that such a feature may require an hint in code, which property is stored or derived from which stored field. 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...) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
lazarus debug with gdb [Re: [fpc-devel] bounty: FPC based debugger]
cced lazarus On 12/09/2011 22:51, Hans-Peter Diettrich wrote: Paul Ishenin schrieb: 12.09.2011 19:00, Martin Schreiber wrote: True. And maintaining all platforms is a fulltime job too. And a FPC only debugger can not debug linked c libraries which we can do currently with gdb. And think of the remote debugging options gdb provides with many targets. As I understand the plan is to create a new debugger without destroying what we already have with gdb. At the moment Lazarus allows to write debugger plugins. When the new debugger is ready the new plugin should be written. My wishes don't call for an new (platform dependent) debugger, I only want *better* high-level (language specific) support in Lazarus. Finally I want to debug applications, not an new debugger with different behaviour and restrictions on every platform ;-) In so far I'm not very interested in commandline and remote debugging, when these discourage the use of an already existing debugger (gdb...). Best to list individual issues. If told it should work, then the best is to provide little test apps, that demonstrate the issue. See my notes on hints in the other mail though. However, I still recommend trunk => a lot of fixes have been applied. Known issues are : - properties with getter. - strings 0 versus 1 based (I do hope to test with dwarf3 soon, but no idea yet, if it will help...) - dyn array, element access in deeply nested pascal expression (simple cases are normally handled) - dyn array: not possible to see the entire list. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 12/09/2011 22:16, Hans-Peter Diettrich wrote:
Another wish: separation of debug info and debug code.
Currently I can't step into packages or FCL/RTL, without compiling
these first for debugging. But doing so puts in all the debug code
(output...), residing in the units. What I want is a dedicated option,
that provides everything required to debug the entire application,
without enabling special {$IFDEF DEBUG} code. Or did I simply miss
something already existing?
I do not know if it helps. Never had an issue with any of those debug
stuff you mention.
But how to you build fpc?
Maybe this will help?
make.exe all OPT="-gl -gw -godwarfsets -O1 "
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
On 13 Sep 2011, at 00:31, Martin wrote: > Maybe this will help? > > make.exe all OPT="-gl -gw -godwarfsets -O1 " You should use -O-1 instead of -O1. The default for "make all" is "-O2", and "-O2 -O1" is the same as "-O2" (it says "enable -O2 optimizations and also -O1 optimizations", but -O2 already includes -O1). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: lazarus debug with gdb [Re: [fpc-devel] bounty: FPC based debugger]
On 12/09/2011 23:18, Martin wrote: However, I still recommend trunk => a lot of fixes have been applied. And if you are on windows, I recommend gdb 7.3 32bit: http://svn.freepascal.org/svn/lazarus/binaries/i386-win32/gdb/bin libraries go into the same folder as gdb. 64 bit => not yet updated. Debugging on win64 bit is not yet that good ( though if you get yourself the latest gdb, and use fpc trunk, it may even work) Otherwise I recommend at least gdb 7.x Though version 6.7.5 and 6.8.3 seem to work too for many cases ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
I don't understand why a property with a getter could ever be ran by a debugger. If I have a property called NextValue, implanted by a method called GetNextValue, that increments a field, stores it in a database, and returns the new value, I absolutely do not want the debugger to execute that even if I'm dumb enough to try to ask it to view that property. I would expect it to give me a rational error message such as "Property NextValue implemented by method GetNextValue" which would tell me that it understood what I was asking, and why it couldn't do it. On Sep 12, 2011 4:14 PM, "Martin" wrote: > On 12/09/2011 20:46, Joost van der Sluis wrote: >> On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote: >>> On 12 Sep 2011, at 20:20, Martin wrote: > Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so > public > property Counter: Integer read GetCounter > could appear the same as the function "GetCounter" ? > > In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field. >>> That may be possible, yes. >> What is it that we actually need? At the Dwarf-level: >> >> Is the information that a property actually has a getter, and the name >> of that getter enough? >> >> Or do we want that when the value of a property is asked, the getter is >> called automagically? (And that there is some kind of flag that >> indicates that a getter is being used?) I don't think that we can add a >> stack-script in the DW_AT_Location that executes the getter. I've looked >> at DW_OP_call, but that won't help us here. >> >> Or, and maybe this is the best solution: some 'opaque' type that returns >> a reference to something else. Which can be different for reading and >> writing values... >> > > There are 2 conflicting desires. > > -data-evaluate-expression FooObject.BarObjProp.BarValue > ptype FooObject / ptype FooObject.BarObjProp > > The first only works, ( at current) if it is a field, not a getter > function. IMHO that is ok. > > While alot of people do want code execution for properties, there must > be a mean of control (in the front end, e.g lazarus). Even if that was > enabled by default. > That means, I would like that gdb does *not* automatically call the > function. > > So for data evaluation we are fine. > If it is a function, the expression fails, and the IDE needs to look > into it. > > Well having said that. If the function was only called, if brackets are > supplied, maybe. > -data-evaluate-expression FooObject.BarObjProp().BarValue > > But it is not a must. I am not even sure if desirable. > > > the 2nd issue is knowledge that > a) a there is something in the object under the name of the property > b) this something happens to be a property > > a) is already fulfilled if it is a field-property. Hence I asked, if > functions could be added the same way. > -data-evaluate-expression FooObject.GetCounter > currently gets no value > -data-evaluate-expression FooObject.Counter > gives an error, "no symbol" > > if Counter could be the same as GetCounter (making it effectively a > function of the object), then at least the symbol was present. > And at the same time, this solves the question of "does it get executed > or not" => same rules as for "GetCounter" > > b) The above of course does make no difference between it being a > property or just a function. > > for normal evaluation, this may most times make no difference. But for > "debug inspector" type windows (that offer an object inspector like view > of the object, with values) it may make a diff. > If the users setting is to auo-execute properties, then properties would > be executed => but functions would not. > > So then it would be desirable, if there was any indicator between a > function (or even field), and a property. > Ideally this difference would be viewable via gdb => but that is not > even a must. Eventually the IDE will read dwarf directly, at which time > it could make use of it. > > - > As for the whole "auto execution": > > I do not know what the options are => I have not even checked all the > means of controlling it in gdb > > > --- > I know, that given that the IDE anyway hasn't support for it yet, it is > a very early request. > But support in the IDE is hard to implement, if the feature cannot be > tested. And also given that it will take time until the feature is > present in a release, it is neer to early to ask > > > > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
DaWorm schrieb: I don't understand why a property with a getter could ever be ran by a debugger. If I have a property called NextValue, implanted by a method called GetNextValue, that increments a field, stores it in a database, and returns the new value, I absolutely do not want the debugger to execute that even if I'm dumb enough to try to ask it to view that property. Right, property getters can have side effects, like all procedures. That's why I already suggested an hint on property declarations, telling which data item should be displayed for the property. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Possible to set an object function/procedure to external?
Hi, Is it possible to set a object/class procedure/function to external? I want to do something like this: TGObject = object function new: PGObject; cdecl; external 'libglib.so' name 'g_object_new'; There are other cases where this maps better (i'm ignoring the 'self' parameter in this example). Regards, Andrew ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
