Hi guys--

At the encouragement of Anthony Henry, I've been working on converting my 1993 book *Borland Pascal 7 From Square One* to focus on FreePascal. The book will eventually be released under Creative Commons as a free ebook, though it may take me a few more months to get there.

However, I've gotten the first three chapters into reasonably solid form, and the PDF file can be downloaded here without charge, so you can get a sense for what I'm doing:

http://www.lulu.com/content/2028228

The downloadable file is currently 2.2 MB in size. It will probably be 8 MB or so when complete.

I'm still perfecting the page layout templates, so any feedback about the book would be most useful. I've laid it out in the A4 page size to match the existing FreePascal documentation, and with full knowledge that most of the audience for a book like this will be outside the US. The book is an unprotected (no DRM) PDF file, and can be printed to paper if you work that way. (The Adobe Reader can scale it slightly to print on US letter size paper.) I'll be making the PDF freely available when the book is complete, and will offer printed copies from my storefront on lulu.com.

Note that this first volume is an absolute beginner's tutorial. It will be about the fundamentals of Pascal and will not cover Lazarus. (I have existing material on Delphi that I may adapt to Lazarus later on.) It will be about 250-300 pages in length. I envision a second volume covering more advanced topics like pointers, linked lists, and especially object-oriented programming.

I'm especially interested in how readable the book is for people who have English as a second (or third, or fourth) language. I'm an eccentric American, and some of my idioms may be obscure outside the US. If something in the text seems weird or incomprehensible, it's probably an Americanism. Clarifying things like that is easy, but I'm not the best judge of what needs changing. Do let me know.

Once the book is complete, I'll be happy to make all the publishing source files available to others who may want to translate it into another language. I do not have the ability to do that myself.

By the way, if this list is not the place for discussions of documentation or book projects like this, please let me know.

It's been interesting "reading the mail" here the past couple of months. Good luck and thanks!

--73--

--Jeff Duntemann
Colorado Springs, Colorado, USA

For some strange reason the download always breaks off at 99% of the file. (at 2,195,020 bytes, reported size 2,195,094).

I tried from various computers, but it is always the same problem.

Michael.

For me it always stops on 2,195,020 (49%), and it does not even support auto resume.

Ido

For me it worked at the first attempt, though it seemed to "hesitate" a bit at the end (progress bar already full).

Tom

In that case, can you mail me the PDF in private, please ?

Michael.

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)

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.

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 ?
Will some code of FPC be reusable ? (assembling / disassambling) Any general ideas, proposals, negative emotions ?
What is the state of Debugging information symbol support ? Are there any resources beside the source ?

thank you,

helmut

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

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.

A start of a FPC debugger written in FPC is at \Lazarus\debugger\windebug

Op Thu, 21 Feb 2008, schreef Helmut Hartl:

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

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.

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

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

Op Thu, 21 Feb 2008, schreef Jonas Maebe:

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

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

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

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

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

Daniël Mantione wrote

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

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

Op Fri, 22 Feb 2008, schreef Martin Schreiber:

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

No, I use the typeinfo that gdb returns.

Martin

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

Martin Schreiber пишет:

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.

Michael Schnell 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

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.

-Michael

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

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

Op Fri, 22 Feb 2008, schreef Michael Schnell:

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

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.

- 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.

And same for any other non-*nix use.

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.

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

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

I have read the text and I'd like to thank the author for the immense effort (both in the past and in the future) put into it.

The only criticism I might have on it would be that it is a little too US-centric.

I am referring to the stuff related to measurement systems, and other various things that are peculiar to living in US.

These are likely to make the job of translator rather hard and/or cause unnecessary confusion in the non-US (and, non-English) reader.

Unless of course you let the translators do their job by translating the gist of the matter --i.e. do cultural translation-- by skipping or altering those parts.

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 (not much more difficult than debugging the symbol table in FPC anyway).

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). It doesn't have any unusual external dependencies, pretty much everything that's required is included in the gdb source tree itself.

Jonas

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)

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 :)

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.

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).

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

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

Hi!

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

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

Hi!

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.

(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

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.

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