On 09/14/2011 09:00 PM, Hans-Peter Diettrich wrote:
Every (reasonable) OS provides such features in its debug API.
Available support depends on the actual hardware, of course.
Can you point us to a description (Win XP, Win 7, Linux ?)
Thanks,
-Michael
On 09/14/2011 08:47 PM, dmitry boyarintsev wrote:
That's true. The only thing concerns me about that, is there's no
really a standard in GDB (i can be wrong).
This of course would be a necessary condition for working with the gdb team.
Also, IRC, Apple forked gdb (as well other gnu-tools) to
Hi,
On Thu, 15 Sep 2011 09:31:39 +0200, Michael Schnell wrote:
On 09/14/2011 09:00 PM, Hans-Peter Diettrich wrote:
Every (reasonable) OS provides such features in its debug API.
Available support depends on the actual hardware, of course.
Can you point us to a description (Win XP, Win 7,
On 14/09/2011 20:47, dmitry boyarintsev wrote:
really a standard in GDB (i can be wrong). But I've seen a lot of
issues in Lazarus gdb-support, because of the different builds of GDB
used.
Exactly the reason we need a FPC based debugger. Currently each Linux
distro includes a different version
On Thu, Sep 15, 2011 at 5:52 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Last night I made some good progress with my forked Duby. Over 50
patches since the fork, loads of memory leak fixes, class cleanup by
slowly removing those pesky global variables, finally have a working
On 15/09/2011 13:52, Marcos Douglas wrote:
And you will provide these patches, from SVN/Git, right? =)
Yes of course. Now that I know Dmitry's goals for Duby is quite
different to mine [based on his recent posts], I'll publish it to GitHub
in due time - with a different project name to
On Thu, Sep 15, 2011 at 3:34 AM, Michael Schnell mschn...@lumino.de wrote:
Yak !
Is a reunification in progress ?
I'd ask on Apple-dev-maillist, gdb-maillist, gnu-maillist or Jonas :)
2 Graeme: thanks for your hard work! I could definitely use code clean-ups.
thanks,
Dmitry
On 09/13/2011 04:52 PM, Hans-Peter Diettrich wrote:
It's not the CPU, it's more the MMU which can help in finding changed
(global) variables.
AFAIK, the MMU can not work in byte addresses but just with much bigger
blocks of data. So it does not seem to help with finding a write access
to a
On 09/13/2011 02:53 PM, Joost van der Sluis wrote:
You do know that GDB does have a Pascal extension, right?
IMHO, if we really can work with the gdb team on feeding the necessary
Object-Pascal specific add-ons into gdb, creating a new debugger from
scratch does not make any sense at all.
On 09/13/2011 04:59 PM, Hans-Peter Diettrich wrote:
IMO you're addressing the wrong audience. Most things, beyond
breakpoint handling, stepping and memory read/writes, can be done
outside the debugger. Such external code is not bound to debugger
support, and can use language specific
On 14.09.2011 12:44, Michael Schnell wrote:
On 09/13/2011 04:52 PM, Hans-Peter Diettrich wrote:
It's not the CPU, it's more the MMU which can help in finding changed
(global) variables.
AFAIK, the MMU can not work in byte addresses but just with much bigger
blocks of data. So it does not seem
On 09/14/2011 01:58 PM, Sven Barth wrote:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary
from the complete process memory down to
Sven Barth schrieb:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary from
the complete process memory down to only the page size.
On Wed, Sep 14, 2011 at 6:48 AM, Michael Schnell mschn...@lumino.de wrote:
IMHO, if we really can work with the gdb team on feeding the necessary
Object-Pascal specific add-ons into gdb, creating a new debugger from
scratch does not make any sense at all.
That's true. The only thing concerns
On 14.09.2011 14:53, Michael Schnell wrote:
On 09/14/2011 01:58 PM, Sven Barth wrote:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this. (I
have no idea which of the CPUs supported by FPC
On 09/12/2011 11:51 PM, Hans-Peter Diettrich wrote:
) 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 ;-)
A multi-arch compiler should come
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
Den 13-09-2011 10:15, Michael Schnell skrev:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this. (I
On 12 Sep 2011, at 15:23, r...@rdos.net wrote:
Why would anybody want to concentrate on gdb, which is an ancient
debugger,
It's only 7 years older than FPC (GDB: 1986; FPC: 1993).
that does not have a modern GUI integrated into it,
A GUI should not be integrated in a debugger. You don't
On 09/12/2011 03:23 PM, r...@rdos.net wrote:
that does not have a modern GUI integrated into it,
Why should a debugger have it's own GUI ? IMHO it should be used
integrated in an IDE, so tit should have a decent API to be used by an IDE.
So providing a command line interface (if started
On 09/13/2011 11:06 AM, Jonas Maebe wrote:
GDB is built for supporting multiple languages. E.g., its ADA support
has been much better than its C++ support for a long time (although
C++ support is getting fairly good nowadays too).
Unfortunately it seems to be hard (or close to impossible) to
On 13 Sep 2011, at 12:59, Michael Schnell wrote:
On 09/13/2011 11:06 AM, Jonas Maebe wrote:
GDB is built for supporting multiple languages. E.g., its ADA
support has been much better than its C++ support for a long time
(although C++ support is getting fairly good nowadays too).
On Tue, 2011-09-13 at 12:59 +0200, Michael Schnell wrote:
On 09/13/2011 11:06 AM, Jonas Maebe wrote:
GDB is built for supporting multiple languages. E.g., its ADA support
has been much better than its C++ support for a long time (although
C++ support is getting fairly good nowadays
On 09/13/2011 01:22 PM, Jonas Maebe wrote:
Don't insult people when you clearly don't have any experience
whatsoever in working with them.
Sorry if I sounded impolite. I did not at all mean to insult them. On
the contrary I praise them for their exceptional work !
I only wanted to state
On 13/09/2011 00:37, Jonas Maebe 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
On 09/13/2011 02:09 PM, Joost van der Sluis wrote:
Very well said !
Thanks,
-Michael (who does a lot more ANSI C than Pascal, as this is necessary
with embedded controllers.)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 13 Sep 2011, at 14:43, Graeme Geldenhuys wrote:
Wow, thanks for that tip! It's a rather important piece of
information.
Is it mentioned somewhere in the FPC docs? I searched the Programmers
Guide but couldn't find any reference to -O- or -O-n syntax.
-O-1 is the same as -O- -O1 (just
On Tue, 2011-09-13 at 14:48 +0200, Michael Schnell wrote:
On 09/13/2011 01:22 PM, Jonas Maebe wrote:
Don't insult people when you clearly don't have any experience
whatsoever in working with them.
Sorry if I sounded impolite. I did not at all mean to insult them. On
the contrary I
On 13/09/2011 14:53, Jonas Maebe wrote:
-O-1 is the same as -O- -O1 (just like -vwn is the same as -vw -vn --
all single-character FPC options behave that way).
OK, thanks.
-O- and -O1 are both listed in the overview of the command line
options of the Programmers Guide (Appendix A).
On Mon, Sep 12, 2011 at 7:59 PM, Martin laza...@mfriebe.de wrote:
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
On 13/09/2011 14:48, Michael Schnell wrote:
If we could really hope for this, I would vote for a gdb extension
instead of creating a completely new debugger from scratch .
I disagree. In the long term, I think a object pascal based debugger for
FPC is the way to go - potential for much easier
On Tue, Sep 13, 2011 at 10:10 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
On 13/09/2011 14:48, Michael Schnell wrote:
If we could really hope for this, I would vote for a gdb extension
instead of creating a completely new debugger from scratch .
I disagree. In the long term, I think
Michael Schnell schrieb:
GDB is built for supporting multiple languages. E.g., its ADA support
has been much better than its C++ support for a long time (although
C++ support is getting fairly good nowadays too).
Unfortunately it seems to be hard (or close to impossible) to work with
the g*
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this.
It's not the CPU, it's
Den 13-09-2011 16:52, Hans-Peter Diettrich skrev:
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU
On 13 Sep 2011, at 16:52, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU
On 13 September 2011 16:52, Hans-Peter Diettrich wrote:
That's why Delphi normally checks for changed values only when a breakpoint
is hit, not on every instruction.
That makes no sense at all! A watchpoint should trigger as soon as
that data referenced by some memory address changes. Then
I agree with Joost. I've always liked the Insight GUI for gdb, and as
best I know that's written in Tcl/Tk, of all things. So a FreePascal
front end for gdb isn't a bad idea, and would be a great deal easier
than writing a complete low-level debugger from scratch.
--73--
--Jeff Duntemann
I see no problems with the idea of creating another debugger,
especially if written in FPC.
Since there're plenty of the GDB-wrappers already!
And it's also a good option to support either ways: over-gdb and
native. In fact, I've been planning to add GDB target into Duby,
together with native
Jeppe Græsdal Johansen schrieb:
Hardware support for writes to arbitrary memory addresses is
restricted to very few addresses, not really useful.
How many times do you think you need more than 1-2 watchpoints? Lots of
breakpoints I can understand, but I've never found many uses for
On Tue, Sep 13, 2011 at 10:03 PM, Paul Ishenin i...@kmiac.ru wrote:
14.09.2011 9:21, dmitry boyarintsev wrote:
How would you estimate the costs of this task? Would you take it if we
collect some good sum of money or do work for a full day now?
It's not just 1 task. These are multiple tasks:
1)
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
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.
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
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
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
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.
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.
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- Graeme Geldenhuys graemeg.li...@gmail.com 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
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!
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
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,
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
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
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
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
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.
85 matches
Mail list logo
