Re: [fpc-devel] In FPC written FPC Debugger

2008-02-25 Thread Michael Schnell


This is a limitation of the user interface you are using on top of the  
gdb infrastructure, as e.g. Xcode (which uses the gdb mi) does display  
such types.



Yea, I already thought that Eclipse, DDD, Anjuta, ... could also wrap
that functionality. But with your statement nearly every missing feature
in GDB can be dropped by referring to the UI.
  
So it looks like at least pert of the missing stuff can be added by 
means of the Lazarus IDE.


Thus it looks more promising (and a lot less work to do) to go this way 
with the standard GDB as far as possible and introduce GDB extensions 
(as patches) if absolutely necessary.


  

- Set breakpoints within template functions. A template function might
 be instantiated multiple times, i.e. for every type it is used for.
 If you set a breakpoint at the source line within a template
 function, only one instantiation is (randomly?) chosen.
  
Use the rbreak command instead of break (and you may also have to use  
dwarf instead of stabs).


Am enhanced Lazarus IDE would be able to remote-control GDB in that way 
(managing multiple code breakpoints behind a single source code line), too.


-Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-24 Thread Jonas Maebe


On 22 Feb 2008, at 18:44, Johann Glaser wrote:

I want to second that. GDB also lacks some features very useful for C 
++

programmers (yes, I have to use it):
- Display STL types (e.g. std::string, std::vector, std::map). These
 are the usual way of making strings and containers in C++ and are
 quite complex internally. GDB displays this internal structure of
 these types instead of beautifying it according to its semantics. For
 the containers it's even impossible to view its elements.


This is a limitation of the user interface you are using on top of the  
gdb infrastructure, as e.g. Xcode (which uses the gdb mi) does display  
such types.



- Set breakpoints within template functions. A template function might
 be instantiated multiple times, i.e. for every type it is used for.
 If you set a breakpoint at the source line within a template
 function, only one instantiation is (randomly?) chosen.


Use the rbreak command instead of break (and you may also have to use  
dwarf instead of stabs).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-24 Thread Johann Glaser
Hi!

  - Display STL types (e.g. std::string, std::vector, std::map). These
   are the usual way of making strings and containers in C++ and are
   quite complex internally. GDB displays this internal structure of
   these types instead of beautifying it according to its semantics. For
   the containers it's even impossible to view its elements.
 
 This is a limitation of the user interface you are using on top of the  
 gdb infrastructure, as e.g. Xcode (which uses the gdb mi) does display  
 such types.

Yea, I already thought that Eclipse, DDD, Anjuta, ... could also wrap
that functionality. But with your statement nearly every missing feature
in GDB can be dropped by referring to the UI.

  - Set breakpoints within template functions. A template function might
   be instantiated multiple times, i.e. for every type it is used for.
   If you set a breakpoint at the source line within a template
   function, only one instantiation is (randomly?) chosen.
 
 Use the rbreak command instead of break (and you may also have to use  
 dwarf instead of stabs).

(gdb) help rbreak
Set a breakpoint for all functions matching REGEXP.

Hmm, so, this is just a workaround and only works for the start of a
function, as far as I understand the help message. 

But nevertheless, thanks for the hint.

Bye
  Hansi


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Michael Schnell




no gdb or even a GNU compiler exists for Win64.

Does that mean, if you want to use open source tools,  you can write 
code for Win64 in Pascal but not in C ?


Amazing !

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Felipe Monteiro de Carvalho
On Fri, Feb 22, 2008 at 9:10 AM, Michael Schnell [EMAIL PROTECTED] wrote:
  Does that mean, if you want to use open source tools,  you can write
  code for Win64 in Pascal but not in C ?

You can use Visual Studio and the Microsoft C Compiler to write win64 code too.

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Felipe Monteiro de Carvalho
On Fri, Feb 22, 2008 at 9:14 AM, Felipe Monteiro de Carvalho
[EMAIL PROTECTED] wrote:
 On Fri, Feb 22, 2008 at 9:10 AM, Michael Schnell [EMAIL PROTECTED] wrote:
Does that mean, if you want to use open source tools,  you can write
code for Win64 in Pascal but not in C ?

  You can use Visual Studio and the Microsoft C Compiler to write win64 code 
 too.

Ops, didn't read the open source part =) sorry ... please ignore

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Ales Katona

Paul Ishenin  wrote / napísal(a):


And we need:
1. abstraction layer to use gdb or native debugger or any other debugger
2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide
I agree 100% on this, unless gdb people don't accept patches at all I 
think this is the way to go. Writing our own debugger would be an 
unfinished endless process riddled with bugs anyhow. Of course Marc has 
more to say about gdb than most of us :)


Ales
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Paul Ishenin

Martin Schreiber пишет:

On Friday 22 February 2008 08.19:27 Daniël Mantione wrote:


Displaying of ansistrings, widestrings and dynamic arrays is possible
with current gdb. MSEide uses some tricks to achieve correct display in
most of the cases.

How? I have been playing with the idea of doing memory dumps with the x
command and process the data yourself, but to do so, you need to have info
about the symbols. A possibility for the textmode IDE, because ithas an
integrated compiler, but a problem for an IDE that does not include the
compiler. You are parsing ppu files or so?


No, I use the typeinfo that gdb returns.


Maybe everybody will benefit in you boys will do 1 good bicycle instead 
of 3?


I see that Martin, Daniël and Marc are working/worked on one thing - 
debugger for fpc. And now we have 3 implementation based on gdb. + one 
start of native debugger.


And we need:
1. abstraction layer to use gdb or native debugger or any other debugger
2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide

Is that more difficult than fixing/reimplementing already 
fixed/implemented things?


Best regards,
Paul Ishenin.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Michael Schnell


Displaying of ansistrings, widestrings and dynamic arrays is possible with 
current gdb. MSEide uses some tricks to achieve correct display in most of 
the cases.
  

GREAT !

The Lazarus team should take a look at this. (I was very disappointed to 
see that dynamic arrays could not be monitored.)

(I did not play much with debugging FP without Lazarus.)

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Daniël Mantione



Op Fri, 22 Feb 2008, schreef Michael Schnell:



Lack of Pascal support like with, local procedures, widestrings, dynamic 
arrays, properties is platform independend. Therefore all platforms would 
benefit.


Are these things depending on the internal structures of GDB part and 
informations for the executables that is needed to be used under a GIU like 
Lazarus or Eclipse ) or is it just a shortcoming of the command line user 
interface of GDB ?


The internal structures of GDB don't allow for full Dwarf support, which 
is what is needed to fully support the Pascal language. Further, GDB would 
have to be enhanced to display data types as Pascal coders expect them.


Would it not be more appropriate to enhance GDB itself instead of setting up 
a completely new project.


Enhancing gdb has been done several times. Basically all Pascal support by 
GDB was written by our own Pierre Muller. However, there are several 
downsides:

- GDB does not accept patches from everyone
- It takes a long time between patch submission and when people
  actually have such a gdb on their systems.
- You cannot rewrite the GDB internals as an outsider to properly support
  Dwarf and thus Pascal

This seems to be a lot less work that reinventing 
the wheel. I feel that Delphi language is not the only language that offers 
features like or similar to local procedures, widestrings, dynamic arrays, 
properties. So this effort should be supported by the powers  of GDB.


You will find many people are only interrested in C. People working on 
gdb are mainly employed by embedded Linux companies of which C is the 
primary language. They don't mind someone working on Pascal support, but 
don't expect them to start acticvely working on features for other 
languages.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Marco van de Voort
 Op Fri, 22 Feb 2008, schreef Michael Schnell:
 have to be enhanced to display data types as Pascal coders expect them.
 
  Would it not be more appropriate to enhance GDB itself instead of setting 
  up 
  a completely new project.
 
 Enhancing gdb has been done several times. Basically all Pascal support by 
 GDB was written by our own Pierre Muller. However, there are several 
 downsides:
 - GDB does not accept patches from everyone
 - It takes a long time between patch submission and when people
actually have such a gdb on their systems.
 - You cannot rewrite the GDB internals as an outsider to properly support
Dwarf and thus Pascal
  
  - I don't have the feeling GDB is really trying to improve the quality on
 win* platforms. It seems we are still as far as we were when GDB 6.1
 came out.
 
  This seems to be a lot less work that reinventing 
  the wheel. I feel that Delphi language is not the only language that 
  offers 
  features like or similar to local procedures, widestrings, dynamic arrays, 
  properties. So this effort should be supported by the powers  of GDB.
 
 You will find many people are only interrested in C. People working on 
 gdb are mainly employed by embedded Linux companies of which C is the 
 primary language. They don't mind someone working on Pascal support, but 
 don't expect them to start acticvely working on features for other 
 languages.

And same for any other non-*nix use.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Florian Klaempfl
Ales Katona schrieb:
 Paul Ishenin  wrote / napísal(a):

 And we need:
 1. abstraction layer to use gdb or native debugger or any other debugger
 2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide
 I agree 100% on this, unless gdb people don't accept patches at all I

GDB is written in C, even worse it is written in a 80th hackish style
using tons of macros. Most advanced pascal programmers can read it but
writing or even debugging is another matter. Compiling gdb as any gcc
written software is a nightmare especially on non unix. People not
believing it might be my guest in creating new cross binutils for
windows. Using Cygwin doesn't count because the dependency on
cygwin1.dll causes only trouble for the user.

And even if gdb supports everything, you are still stuck to it's
sluggish machine interface when accessing it from IDEs since libgdb is
not supported officially anymore.

 think this is the way to go. Writing our own debugger would be an
 unfinished endless process riddled with bugs anyhow. Of course Marc has
 more to say about gdb than most of us :)
 
 Ales
 ___
 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] In FPC written FPC Debugger

2008-02-22 Thread Michael Schnell



Using Cygwin doesn't count because the dependency on
cygwin1.dll causes only trouble for the user.
  
That is _very_ true ! I had tons of those problems in non FP projects 
with several different development environments.

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Florian Klaempfl
Jonas Maebe schrieb:
 
 On 22 Feb 2008, at 09:32, Florian Klaempfl wrote:
 
 GDB is written in C, even worse it is written in a 80th hackish style
 using tons of macros. Most advanced pascal programmers can read it but
 writing or even debugging is another matter.
 
 It is not /that/ hard to debug 

But it is hard for people knowing C not that well but knowing pascal,
that's what I meant. Would you ever have be able to contribute to fpc if
the compiler had been written in C (yes, I did a prototype in C in '93
because I wanted a 32 Bit compiler to bootstrap :) )? Luckily enough I
got the money to buy BP7 so I could use at least PM to have enough
memory, this was before I got the idea to abuse TEMSStream to store
symbols :)

 
 Compiling gdb as any gcc
 written software is a nightmare especially on non unix.
 
 
 On unix (at least on Linux and Mac OS X) it is trivial to compile
 (./configure ; make). 

Yes, and then you can go drinking 3 cups of coffee ;) even using a
modern machine and not considering the unix centric approach it uses. If
you've bad luck, make distclean doesn't clean everything, happens
regularily, and you need to create a patch of your changes, re-unpack
the sources and apply your patch.

 It doesn't have any unusual external dependencies,
 pretty much everything that's required is included in the gdb source
 tree itself.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Jonas Maebe


On 22 Feb 2008, at 11:24, Florian Klaempfl wrote:


Jonas Maebe schrieb:


On 22 Feb 2008, at 09:32, Florian Klaempfl wrote:

GDB is written in C, even worse it is written in a 80th hackish  
style
using tons of macros. Most advanced pascal programmers can read it  
but

writing or even debugging is another matter.


It is not /that/ hard to debug


But it is hard for people knowing C not that well but knowing pascal,
that's what I meant.


If you can read the gdb sources, you can also debug it. I speak from  
experience, and I'm really not a C expert. It does take a while before  
you can find your way in the sources, but the same goes for any big  
project.


It's obvious that if gdb were written in Pascal, more Pascal  
programmers could easily contribute to it. But I personally do not  
consider that downside big enough to rewrite the whole thing from  
scratch in Pascal (at least not for Mac OS X and Linux; and other  
people are obviously free to spend their time however they like).



Would you ever have be able to contribute to fpc if
the compiler had been written in C (yes, I did a prototype in C in '93
because I wanted a 32 Bit compiler to bootstrap :) )?


Not at that time (I didn't know C at all in 1997).


On unix (at least on Linux and Mac OS X) it is trivial to compile
(./configure ; make).


Yes, and then you can go drinking 3 cups of coffee ;) even using a
modern machine and not considering the unix centric approach it uses.


It's true that the first build takes a long time (especially if you,  
like me, build it on a network volume). But after that the incremental  
builds don't take that long.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Daniël Mantione


About reinventing the wheel... It is not about reinventing GDB.

You can compare this story with designing a car: You can use an engine 
designed for an older car, this saves you the work of designing a new 
engine. But the existing engine does not fullfill all needs of the new 
car. So, some designers want to design a new engine which perfectly fits 
in the car and therefore gives many advantages. Others look up to the work 
needed and want to use the existing engine, with some modifications and 
live with the rest of its quirks.


Both are valid engineering decisions.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Marco van de Voort
 On 22 Feb 2008, at 09:32, Florian Klaempfl wrote:
 
 On unix (at least on Linux and Mac OS X) it is trivial to compile (./ 
 configure ; make). It doesn't have any unusual external dependencies,  

It has some problems in general with preinstalled versions of the GNU
libraries it packages (intl,readline), if your distribution deviates from what 
Linux/x86
packages. (or is explicitely fixed in configure).

I routinely disable intenationalisation (-disable-nls) because of it.

 pretty much everything that's required is included in the gdb source  
 tree itself.

Which then in turn is also a cause for problems. Nothing an experienced Unix
person can't handle, but not userfriendly either. IMHO the gdb tree should
not build those libraries shared, or reject versions outside the tree to
avoid this)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Johann Glaser
Hi!

On Fre, 2008-02-22 at 09:20 +0100, Michael Schnell wrote:
  Lack of Pascal support like with, local procedures, widestrings, 
  dynamic arrays, properties is platform independend. Therefore all 
  platforms would benefit.
 
 Are these things depending on the internal structures of GDB part and 
 informations for the executables that is needed to be used under a GIU 
 like Lazarus or Eclipse ) or is it just a shortcoming of the command 
 line user interface of GDB ?
 
 Would it not be more appropriate to enhance GDB itself instead of 
 setting up a completely new project. This seems to be a lot less work 
 that reinventing the wheel. I feel that Delphi language is not the 
 only language that offers features like or similar to local procedures, 
 widestrings, dynamic arrays, properties. So this effort should be 
 supported by the powers  of GDB.

I want to second that. GDB also lacks some features very useful for C++
programmers (yes, I have to use it):
 - Display STL types (e.g. std::string, std::vector, std::map). These
   are the usual way of making strings and containers in C++ and are
   quite complex internally. GDB displays this internal structure of
   these types instead of beautifying it according to its semantics. For
   the containers it's even impossible to view its elements.
 - Set breakpoints within template functions. A template function might
   be instantiated multiple times, i.e. for every type it is used for.
   If you set a breakpoint at the source line within a template
   function, only one instantiation is (randomly?) chosen.
Hmm, these rather like a GDB wish list bug report looking items point
out that GDB doesn't even intensively care about C++ (despite it
supports name (de-)mangling).

Besides the mentioned points, I really dissuade from starting with a
completely new debugger project, since there is so many basic work to
implement and to care for and then to support. The FPC community is IMHO
still too small for such a project. And GDB still lacks a lot of
improvements.

Bye
  Hansi


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] In FPC written FPC Debugger

2008-02-22 Thread Helmut Hartl
Paul Ishenin wrote:
 Maybe everybody will benefit in you boys will do 1 good bicycle
 instead of 3? 

At the moment i do not see the good bicycle to ride on.

 I see that Martin, Daniël and Marc are working/worked on one thing -
 debugger for fpc. And now we have 3 implementation based on gdb. +
 one start of native debugger.  
 
 And we need:
 1. abstraction layer to use gdb or native debugger or any other
 debugger 2. program interface which can satisfy fpc ide, mse ide, and
 lazaraus ide  

Well the abstraction layer should be one feature of the native debugger,
to make it usable for projects like lazarus, mseide etc ...
At the moment i don't see gdb supporting all necessary features
(e.g. gdb does not care for pascal enough).

 Is that more difficult than fixing/reimplementing already
 fixed/implemented things? 

I am currently trying to find pros and cons, feasibility.

Usecase: I want to develop and debug on an arm target nice and productive.
The arm target has udp, or serial console, but no display and has limited mem.
My vision is as follows load: The fpc native debugger stub to the arm board.
Communicate with the debugger, show a nice gui on linux/win. Do your job.
The same should(could) hold for windows, linux, macos too ...

The reality now would be: 
How do i find in internet or compile the gdb
for my target ? (2 weeks) Deal with linking (2 days), Deal with libraries (3 
days)
,deal with makefiles (1 day), deal with c code (1/2 day),
deal with memory shortage, deal with the poor gdb pacal support, 
deal with the poor gdb interfacing support. (priceless ;-))
Then start doing the job with limitations ...
In lazarus i have gdb/interfacing related crashes every one debugging run 
(making console apps for linux).
What i want to say in my firm i need 3 experts to set up the whole thing.
So why should i not start the project in c(++)?
Because i can write and read pascal code after 1 bottle of wodka :-)
And i vomit reading c code, as the language drives every user to win an 
obfuscation contest,
including me when i used it for firmware projects.

That is my motivation ...

PS: i did not had a look marc weustinks code, nor knowed about it, i will have 
a look soon ..

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Jonas Maebe


On 21 Feb 2008, at 18:56, Helmut Hartl wrote:


The advantage i see is that it should be buildable with fpc only, thus
working on all supported platforms from scratch,


The second part does not follow from the first part. Debugging by  
definition requires interfacing with the OS at a very low level, and  
quite a bit of cpu-specific code.



I have some general questions to the fpc team:

What do you think about the idea ?


For Mac OS X (the platform I maintain) I do not consider it worth the  
trouble (regular low level changes in the dynamic linker and available  
debugger api's, a new architecture every couple of years, changes only  
become know/available once a new release is out, ...).


I know that several developers are in favour for it for Linux and  
Windows, however.



Will some code of FPC be reusable ? (assembling / disassambling)


FPC does not contain a disassembler. You don't need an assembler in a  
debugger (except if you want to support live patching or so). I don't  
think much, if any, code from FPC would be usable (except for maybe  
the symbol table, although I'm not sure how easy it is to rip it out  
and reuse it).



Any general ideas, proposals, negative emotions ?


One general thing you have to think of is whether you only want to  
support Pascal, or also projects combining Pascal and code written in  
other languages.



What is the state of Debugging information symbol support ?


Quite good, in general. Some things which are still missing are  
dynamic arrays, and strings are also only a hack (although they work  
well with gdb).



Are there any resources beside the source ?



The dwarf specs.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Florian Klaempfl
Helmut Hartl schrieb:
 Are there any resources beside the source ?

Did you look already at:
http://svn2.freepascal.org/svn/lazarus/trunk/debugger/windebug/
?

It's a start for a fpc written debugger for lazarus by Marc Weustinek.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Wanderlan Santos dos Anjos
A start of a FPC debugger written in FPC is at \Lazarus\debugger\windebug
-- 

Wanderlan Santos dos Anjos
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Jonas Maebe


On 21 Feb 2008, at 21:37, Daniël Mantione wrote:

This discussion takes place in the fpc team from to time. It is  
clear we will need our own debugger, even though not everyone likes  
to maintain a debugger for its platform.


I disagree it is even necessary for Mac OS X, as gdb works fine there  
(and both Apple and SourceWare have been fairly receptive to the - 
small- patches I have submitted).



Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Daniël Mantione



Op Thu, 21 Feb 2008, schreef Helmut Hartl:



Hi,

When using Freepascal for various projects, tests and platforms, i tried
to identify what makes productivity bottlenecks for me and my team.

We currently mainly do daemon console apps with Delphi and Lazarus as
IDE for linux,
arm projects on NLSU2, and several WinCE Tests also performed well.

One of the main problems we face is the debugger gdb, wich makes us less
productive.
(unhandy, no real good pascal support)


You are right, debugging is the weak point of FPC and this will not 
improve as long as we are using gdb.



So i am thinking about a freepascal debugger written in freepascal,
taking advantage of
the freepascal code/structures itself. Features should include a clean
interface, remote debugging ability
via net/udp (thinking about a rdp/vnc like server to control the
debugger) and or serial console and the ability
to integrate it with a nice gui. (and other Features like Delphi's
debugger).

The advantage i see is that it should be buildable with fpc only, thus
working on all supported platforms from scratch,
maybe even suitable for mini OS Developments for embedded devices.


One platform that would benefit is Win64. Debugging is currently not 
possible on Win64, because no gdb or even a GNU compiler exists for Win64.



I am currently trying to study feasibility of such a project, and making
myself familiar with debugging techniques and
the DWARF(3) format.

I have some general questions to the fpc team:

What do you think about the idea ?


This discussion takes place in the fpc team from to time. It is clear we 
will need our own debugger, even though not everyone likes to maintain a 
debugger for its platform.


The FPC coders have to do lists to keep them busy until well in the next 
decade. If you want to write a debugger, I consider that welcome.


Daniël
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Daniël Mantione



Op Thu, 21 Feb 2008, schreef Jonas Maebe:



On 21 Feb 2008, at 21:37, Daniël Mantione wrote:

This discussion takes place in the fpc team from to time. It is clear we 
will need our own debugger, even though not everyone likes to maintain a 
debugger for its platform.


I disagree it is even necessary for Mac OS X, as gdb works fine there (and 
both Apple and SourceWare have been fairly receptive to the -small- patches I 
have submitted).


GDB works well on any Unix. It's the non-Unix platforms where gdb does not 
work well. Lack of Pascal support like with, local procedures, 
widestrings, dynamic arrays, properties is platform independend. Therefore 
all platforms would benefit.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Marco van de Voort
 Op Thu, 21 Feb 2008, schreef Jonas Maebe:

  This discussion takes place in the fpc team from to time. It is clear we 
  will need our own debugger, even though not everyone likes to maintain a 
  debugger for its platform.
 
  I disagree it is even necessary for Mac OS X, as gdb works fine there (and 
  both Apple and SourceWare have been fairly receptive to the -small- patches 
  I 
  have submitted).
 
 GDB works well on any Unix.

I can not really relate to that. GDB is a stopgap on Unix too IMHO.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Jonas Maebe


On 21 Feb 2008, at 22:22, Daniël Mantione wrote:


Op Thu, 21 Feb 2008, schreef Jonas Maebe:



On 21 Feb 2008, at 21:37, Daniël Mantione wrote:

This discussion takes place in the fpc team from to time. It is  
clear we will need our own debugger, even though not everyone  
likes to maintain a debugger for its platform.


I disagree it is even necessary for Mac OS X, as gdb works fine  
there (and both Apple and SourceWare have been fairly receptive to  
the -small- patches I have submitted).


GDB works well on any Unix. It's the non-Unix platforms where gdb  
does not work well.


That's why I said it's not needed for Mac OS X (and not it's not  
needed for any platform).


Lack of Pascal support like with, local procedures, widestrings,  
dynamic arrays, properties is platform independend. Therefore all  
platforms would benefit.


All Unixes would just as well benefit from the same support in gdb,  
with the added advantage that you immediately also have C/C++ support  
(handy for mixed source projects) + you don't have to implement and  
maintain all the low level support for those platforms.


Both approaches have their pros and cons (e.g. gdb has against it that  
is written in C), but I consider it far from clear that we will need  
our own debugger (at least not for all platforms).



Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Daniël Mantione



Op Thu, 21 Feb 2008, schreef Marco van de Voort:


Op Thu, 21 Feb 2008, schreef Jonas Maebe:



This discussion takes place in the fpc team from to time. It is clear we
will need our own debugger, even though not everyone likes to maintain a
debugger for its platform.


I disagree it is even necessary for Mac OS X, as gdb works fine there (and
both Apple and SourceWare have been fairly receptive to the -small- patches I
have submitted).


GDB works well on any Unix.


I can not really relate to that. GDB is a stopgap on Unix too IMHO.


One reason why GDB works better on Unix than on other platforms is 
that it assumes Unix. I.e. it assumes a Unix filesystem and has no 
knowledge about driveletters.


Another reason is that it depends on various libraries, like libiberty, 
readline, which not only don't care much about other platforms, but also 
enforce Unix emulators like Cygwin.


While I don't disagree with your second sentence (GDB is not quality 
software), GDB does work well on Unix for the functionality it advertises.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Vincent Snijders

Daniël Mantione schreef:


One platform that would benefit is Win64. Debugging is currently not 
possible on Win64, because no gdb or even a GNU compiler exists for Win64.


Not true. Download a win64 lazarus snapshot and you get the 
'expirimental' gdb for win64.


Vincent
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Martin Schreiber
On Thursday 21 February 2008 22.22:27 Daniël Mantione wrote:
 Op Thu, 21 Feb 2008, schreef Jonas Maebe:
  On 21 Feb 2008, at 21:37, Daniël Mantione wrote:
  This discussion takes place in the fpc team from to time. It is clear we
  will need our own debugger, even though not everyone likes to maintain a
  debugger for its platform.
 
  I disagree it is even necessary for Mac OS X, as gdb works fine there
  (and both Apple and SourceWare have been fairly receptive to the -small-
  patches I have submitted).

 GDB works well on any Unix. It's the non-Unix platforms where gdb does not
 work well. Lack of Pascal support like with, local procedures,
 widestrings, dynamic arrays, properties is platform independend. Therefore
 all platforms would benefit.

Displaying of ansistrings, widestrings and dynamic arrays is possible with 
current gdb. MSEide uses some tricks to achieve correct display in most of 
the cases.

Martin



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Daniël Mantione



Op Fri, 22 Feb 2008, schreef Martin Schreiber:


On Thursday 21 February 2008 22.22:27 Daniël Mantione wrote:

Op Thu, 21 Feb 2008, schreef Jonas Maebe:

On 21 Feb 2008, at 21:37, Daniël Mantione wrote:

This discussion takes place in the fpc team from to time. It is clear we
will need our own debugger, even though not everyone likes to maintain a
debugger for its platform.


I disagree it is even necessary for Mac OS X, as gdb works fine there
(and both Apple and SourceWare have been fairly receptive to the -small-
patches I have submitted).


GDB works well on any Unix. It's the non-Unix platforms where gdb does not
work well. Lack of Pascal support like with, local procedures,
widestrings, dynamic arrays, properties is platform independend. Therefore
all platforms would benefit.


Displaying of ansistrings, widestrings and dynamic arrays is possible with
current gdb. MSEide uses some tricks to achieve correct display in most of
the cases.


How? I have been playing with the idea of doing memory dumps with the x 
command and process the data yourself, but to do so, you need to have info 
about the symbols. A possibility for the textmode IDE, because ithas an 
integrated compiler, but a problem for an IDE that does not include the 
compiler. You are parsing ppu files or so?


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] In FPC written FPC Debugger

2008-02-21 Thread Martin Schreiber
On Friday 22 February 2008 08.19:27 Daniël Mantione wrote:

  Displaying of ansistrings, widestrings and dynamic arrays is possible
  with current gdb. MSEide uses some tricks to achieve correct display in
  most of the cases.

 How? I have been playing with the idea of doing memory dumps with the x
 command and process the data yourself, but to do so, you need to have info
 about the symbols. A possibility for the textmode IDE, because ithas an
 integrated compiler, but a problem for an IDE that does not include the
 compiler. You are parsing ppu files or so?

No, I use the typeinfo that gdb returns.

Martin

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel