Hi,

Recently I mentioned a issue with debugging (using GDB) and indexing in a AnsiString to retrieve a specific character from that string.

DWARF2
-----------
eg:

  S := 'mystring';

GDB can display the value of S without problems because it is treated as a PChar (from what I can see and understand).

  c := s[1]

GDB displays the wrong character from the string. GDB displays the 'y' character instead of the 'm' character. GDB or DWARF2 treats a AnsiString (or an array of char) being 0-indexing instead of 1-indexed.

DWARF3
-----------

   c := s[1]

GDB correctly displays the first character of the string stored in s. This is accomplished by using tho lower_bound = 1 attribute in DWARF3.

  s := 'mystring'

GDB cannot display the value of the ansistring stored in s, even thou DW_AT_type is set as well. It seems GDB cannot figure out how to handle displaying s, even though it knows it's an character array.

It seems the DWARF2/3 support with GDB is playing the vice-versa game. Fix one, break one.

This last part in DWARF3 above... it seems FPC has fulfilled the specs for DWARF3 (again from what I can understand from the DWARF3 spec inself) by correctly describing a AnsiString, so what is the issue now
- why can't GDB display the value (full string value) of a ansistring variable? Is it now the lack of Object Pascal support in GDB giving us the problems?

Sorry if this sounds dumb, but I'm new to DWARF and debuggers, so I just want to try and get my bearings with where exactly the problem sits. Is it with FPC, or with GDB, or both.

Nothing new. The problem with debugging is not only a fpc-problem, there are problems with gdb also. The problem is that if a problem in fpc is fixed properly, that will lead to problems in gdb. And the other way around. Only way to fix those is to update both at the same time. This is difficult because of the different release-cycles.

As I try to do things now, is to fix these problems in the Dwarf-3 debug information. (Even it's not a Dwarf-3 issue. See for example the case-sensitivity) This will lead to problems with debugging with Dwarf-3 at the short-term. (Ie: with unpatched gdb versions) But it won't affect the debugging with Dwarf-2. So you can use the default Dwarf-debug format for normal circumstances. And if you want to test and improve the debugging, try Dwarf-3. (Although improving the debugging with Dwarf 2 isn't forbidden, offcourse.)

Joost.

Op 2010-10-26 10:23, Joost van der Sluis het geskryf:

are problems with gdb also. The problem is that if a problem in fpc is fixed properly, that will lead to problems in gdb. And the other way around. Only way to fix those is to update both at the same time. This is difficult because of the different release-cycles.

OK, this is what I thought.

As I try to do things now, is to fix these problems in the Dwarf-3 debug information. (Even it's not a Dwarf-3 issue. See for example the case-sensitivity).

OK, I'll take a look.

What I am trying to do, is invest some time in duby development (Object Pascal based debugger). This is a rather large undertaking for me, because I lack compiler, debugger and dwarf knowledge - but I am up for the challenge and think the effort I put in will be rewarded later down the line. Currently duby reads stabs and dwarf3 debugging. I want to concentrate on the dwarf3 debugging only.

I haven't looked at the code you mentioned yet, so I might have this wrong, but it sounds like you are implemented non-standard dwarf3 debugging "hacks" in the dwarf3 debug class, and then want to patch gdb to work with that. That is not good, because I want duby to be dwarf3 compliant and work with FPC + DWARF3 + Object Pascal, so we can finally have a native Object Pascal debugger.

GDB is too C/C++ centric, and Object Pascal support will never come near as good. Using duby instead will also mean we can easily coordinate releases or debug features (in FPC and duby), contributions are made easier because it uses our familiar Object Pascal language etc. Then later down the line, even consider moving duby into FPC source tree and become the default debugger for FPC (but lets not get ahead of ourselves).

I'm just getting sick of the sad state that FPC debugging (with our only choice GDB) is in. It's near unusable and currently only good for stepping through code. So I'll take the cue and see if I can do something about it.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I'm just getting sick of the sad state that FPC debugging (with our only choice GDB) is in. It's near unusable and currently only good for

stepping

through code. So I'll take the cue and see if I can do something about

it.

Because more or less these are also my thoughts, in case you need help count me in.

regards,

На 26.10.2010 11:59, Graeme Geldenhuys напісаў(ла):

I know at least two developers who stand - the only thing preventing them of using FPC is GDB.

Regards,
Anton

Anton Kavalenka wrote

I know at least two developers who stand - the only thing preventing them of using FPC is GDB.

Windows-only developers?

Or else I don't know another compiler which will offer better debugging in the rest of the platforms.

Felipe Monteiro de Carvalho wrote

Or else I don't know another compiler which will offer better debugging in the rest of the platforms.

If Java can also be considered as a platform I must say that debugging in eclipse is better.

Best regards,
Paul Ishenin.

?? 26.10.2010 13:33, Felipe Monteiro de Carvalho ???????(??):

Yes, windows only.
But they fully understand bonuses from FPC and Lazarus but really hate GDB. Their last argument - we need assembly-line stepping debugger like in Delphi.

regars,
Anton

?? 26.10.2010 14:10, Paul Ishenin ???????(??):

Completely agree.
Even debugging C++ and PHP in Eclipse is nice.
I've debugged C++ dll with FPC host application under x86_64 linux. It was amazing to start from FPC source and get into C++ source and back without a hassle.
Btw Eclipse tunes GDB so it is notified on dynamic DLL loading and sets breakpoints properly,
in Lazarus I have to reset breakpoints manually after dynamic DLL (via dlopen()) i.e. without manual reset it won't work.

regards,
Anton

Graeme Geldenhuys wrote

I'm just getting sick of the sad state that FPC debugging (with our only choice GDB) is in. It's near unusable and currently only good for stepping through code. So I'll take the cue and see if I can do something about it.

I expect the LLVM debugger <http://llvm.org/docs/SourceLevelDebugging.html> to be much better in the future that GDB is now. But an all-Pascal debugger is ideal, of course.

Regards,

Adriaan van Os

Op 2010-10-26 13:22, Anton Kavalenka het geskryf:

Their last argument - we need assembly-line stepping debugger like in Delphi.

This is actually supported in MSEide, I did it the other day ("View > Assembler" and use 'Next instruction' in stead of 'Next' in the debugger toolbar). Even breakpoints can be set at assembly line level. From my experience MSEide's debugging is miles ahead of Lazarus IDE, but in the end there are still many problems (in both IDE's) due to missing DWARF information or usage of GDB not understanding Object Pascal language.

Regards,
- Graeme -

???
Works with gdb, see MSEide example:
http://mseide-msegui.berlios.de/debugger.png
Or did I misunderstand?

Martin

+1

although it must be said that is mainly for lazarus. The fpc-ide debugger for instance is the only way to get assembler-viewing+stepping to work. (to some extend)

at least on win32

kind regards,
Dimitri Smits

It is OK for 32 bit stabs but 64 bit FPC debugger support (dwarf AFAIK) is probably not finished. I do not recommend to use 64 bit for FPC development at the moment if 32 bit can be used instead.

Martin

Op 2010-10-26 14:13, Martin Schreiber het geskryf:

It is OK for 32 bit stabs but 64 bit FPC debugger support (dwarf AFAIK) is probably not finished. I do not recommend to use 64 bit for FPC development at the moment if 32 bit can be used instead.

Well I don't think it's that bad compared to 32-bit FPC, well not for me, because I debug more without GDB that with it. Lately I limit my GDB usage only for stepping the source code. Anyway, in MSEide and with FPC 64-bit under 64-bit Linux I can still step the assembly instructions. The CPU window doesn't work at all though, where it did under 32-bit Linux.

http://opensoft.homeip.net/~graemeg/mseide_debug_windows.png

Regards,
- Graeme -

Op 2010-10-26 14:10, Dimitri Smits het geskryf:

although it must be said that is mainly for lazarus. The fpc-ide debugger for instance is the only way to get assembler-viewing+stepping to work. (to some extend)

Try MSEide instead, it works very well there.

Regards,
- Graeme -

Plase check if 'Project'-'Options'-'Debugger'-'Target'-'Processor' is set to 'i386' instead of 'auto' or 'x86_64'.

Martin

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

> Plase check if 'Project'-'Options'-'Debugger'-'Target'-'Processor' is set to 'i386' instead of 'auto' or 'x86_64'.

Ah, that did the trick, thanks Martin. :)

The problem is then in the MSEide template projects (issue is probably in svn repository too, because the default ones are not changed locally). I went "Project > New > From Template > console.prj". By default it is set it i386 instead of Auto.

Regards,
- Graeme -

Please try again with trunk 4042, thanks for reporting.

Martin

was Re: [fpc-devel] AnsiString in DWARF2 vs DWARF3

----- "Anton Kavalenka" wrote

На 26.10.2010 13:33, Felipe Monteiro de Carvalho напісаў(ла):

On Tue, Oct 26, 2010 at 12:08 PM, Anton Kavalenka wrote:

I know at least two developers who stand - the only thing preventing them of using FPC is GDB. Windows-only developers?

Or else I don't know another compiler which will offer better debugging in the rest of the platforms. Yes, windows only.

But they fully understand bonuses from FPC and Lazarus but really hate GDB. Their last argument - we need assembly-line stepping debugger like in Delphi.

I count myself in that category as well. Assembler stepping is maybe not for everyone, but if you want some fine grained control, you sometimes need to delve deeper into the internals. This is especially so with compiler-code or RTL speedups.

I've been trying to see if I could write a better/faster FillChar last weekend. My asm was a bit rusty (and I definately have some learning curve to go through with gasm AT&T syntax), so I wanted to test something out that (and the include-file mess in RTL that needs some getting used to), I needed to see the compiled version of a regular FPC FillChar for Win32. I suspected it to be in i386.inc, but wasn't sure.

In lazarus => complete fail.
lots of tries to get debuginfo/mapfiles generated. Nothing usefull came out for use in a debugger. I didn't try the build with asm files of the RTL, as I inherently evolved past makefiles years ago (Delphi/ant/want/VisualStudio build systems are more in my current skillset). tried a disassembler like PE Explorer (trial) => no exported methods, so I got a somewhat 'guess where everything is' -asm. fpc-ide on vista => no fullscreen support, so practically unusable in too high res, but finally managed to asm-step and confirm.

While I get that gdb is a powerfull debugger (and cross-architecture/platform), it too has a steep learning curve.

So, aside from the build-system, most of the "complaints" I have about missing features are not inherent to fpc, but more to the tools around it (like lazarus with it's subpar debugging compared to D7).

I guess it's time to put my code where my mouth is, but some of the issues above make it nearly a catch 22.

kind regards,
Dimitri Smits

Op 2010-10-27 01:28, Dimitri Smits het geskryf:

In lazarus => complete fail. lots of tries to get debuginfo/mapfiles generated. Nothing usefull came out for use in a debugger.

I find myself switching between Lazarus IDE and MSEide often. Just about every project I work on has both a *.lpi (Lazarus project) and *.prj (MSEide project) file. In either case, I don't write LCL or MSEgui applications - I use fpGUI exclusively or write console utility apps. What makes it easier for me, is that fpGUI's Form Designer is a stand-alone app, so it works from any IDE I choose (via their external tools menu).

I did find MSEide a lot better at debugging though, and Lazarus IDE a lot better and code navigation. Hence I keep switching between the two of them, depending on what I am doing.

I highly recommend you try MSEide. It is very fast, and doesn't get in the way of programming (Lazarus IDE has way to many automated [IDE things it is clever] features I need to keep disabling).

Regards,
- Graeme -

a) as has been mentioned before, gdb does support assembler stepping b) to step through FillChar's assembler code, you don't need assembler stepping because the code was written in inline assembler. That means that FPC generates Pascal-level debug information for each line of assembler from that routine, and regular stepping will step through that code one assembler statement at a time

While I get that gdb is a powerfull debugger (and cross-architecture/ platform), it too has a steep learning curve.

Maybe I should write a tutorial on the wiki, because there aren't that many commands you have to know, along with a few gotchas. Time, time...

Jonas

Op 2010-10-27 10:55, Jonas Maebe het geskryf:

Maybe I should write a tutorial on the wiki, because there aren't that many commands you have to know, along with a few gotchas. Time, time...

Even better, would be to add a "Debugging with GDB" chapter to the official FPC documentation.

I too have the time problem. :)

Regards,
- Graeme -

Graeme Geldenhuys wrote

Even better, would be to add a "Debugging with GDB" chapter to the official FPC documentation.

This got me thinking, maybe I should write a chapter on "Debugging without GDB". I should speak to Michael about this.

I am not out to hijack this thread; just a quick question:

I asked this in the Sourceforge forum of duby, but seeing that mine is the only one ever, I don't see much chance that it mey ever get answered there.

When I try to compile any duby project, it fails saying winTools32 is missing. This is in the uses section of winDbgProc.pas

Any idea where I can locate winTools32.pas?

Op 2010-10-28 03:19, Adem het geskryf:

Any idea where I can locate winTools32.pas?

I have no idea, I've only every worked on duby under Linux. I searched my linux and windows development machines and found no such unit. Maybe email Dmitry directly. He might have forgotten to add that unit to the repository.

Regards,
- Graeme -

Op 2010-10-28 03:19, Adem het geskryf:

Any idea where I can locate winTools32.pas?

I just had a look at the repository history of duby. wintools32.pas was removed in r230. The commit comment was that it had to be replaced by FCL. I'm not sure if Dmitry completed that process. Otherwise just check out a slightly older revision to get the missing unit back.

Regards,
- Graeme -

Thanks.

229 has it and it compiles with minor modifs.
Next step is to find out how it is used.

BTW, much of the code needed from wintools32.pas could be gathered from Jedi libs but removing circular references might take time.