Hi all,

When you specify -gw3 to create Dwarf-3 debug information, there is no 'reference' pointer to a class in the debug information.

This means that when you evaluate a class-variable, it will show the contents of the variable, not the pointer you want to see the address of the class, you have to use @classname.

There are a few issues, though:
- If a class is not assigned (=nil), gdb shows the message that the class is not assigned. It doesn't show that it is nil. (Effectively this means the same offcourse, is this a problem? Should gdb be patched to show nil?)

- You can not compare two classes in gdb. It will complain that there is no operator to compare two classes. Which is right, offcourse. But in Pascal normally the addresses of the classes are compared when you compare two classes. Gdb can't handle that.

- There is an issue with Lazarus. With other debug-formats, the class of a type is often reported as '^Tfoo'. With Dwarf-3 it correctly reports TFoo. But when you ask for @FooInstance, it will give you (correctly) ^TFoo as it's type. But Lazarus doesn't recognize this as pointer to a class, because in the other debug-formats, this is considered the class itself.

The debug-tests from Lazarus helped me a lot with this, thanks Martin for that.

I also promised to build a Windows-gdb binary with the latest Dwarf-3 patches from the Archer-project. This can be downloaded here:

http://www.lazarussupport.com/downloads/gdb_win32_fedora15_with_pascal_patches.zip

You can use this gdb version to test the Dwarf-3 format (strings, open arrays), and the borland-fastcall calling convention. (ie: you can call functions/procedures from within the debugger)

And please report issues with the Dwarf-3 format in combination with this version of gdb.

Joost.

Yes. Nil is a value which is assigned to a class instance and therefore should be shown.

- You can not compare two classes in gdb. It will complain that there is no operator to compare two classes. Which is right, offcourse. But in Pascal normally the addresses of the classes are compared when you compare two classes. Gdb can't handle that.

Maybe to declare an operator? Looks like gdb understands FPC class as C++ class which is not a pointer?

A big step forward!

Best regards,
Paul Ishenin

This has nothing to do with gdb, but with the debug-information that fpc (-gw3) generates. Now it handles classes as if they are not pointers. I think that this is closer to how a class is defined in Pascal. A class is (imho) not a pointer, just like an ansistring is not a pointer. After all, we don't use AnObject^.Destroy....

So we have to choose what to do: make the implicit pointer visible in the debug-info and add some hacks to gdb that it converts AnObject.Destroy to AnObject^.Destroy. (This is what we do with stabs and Dwarf < 3)

Or we 'hide' the implicit pointer so that AnObject.Destroy works, but we have to add some hacks to gdb so that an unallocated class is shown as 'nil', and add the ability to do pointer-arithmetic on classes. (Like comparing two classes)

Two options, both have there pro's and con's?

Joost.

Delphi also allows skipping the ^ for e.g. pointers to records. A difference is that it does not allow using ^ at all for classes, but still...

Also, in Delphi (and in FPC's Delphi mode) untyped pointers can be automatically converted by the compiler into class types, so they are quite close. I don't really see a big advantage in changing the encoding of class types in the debug information, especially since even now stuff like classinstance.fieldname works.

Jonas

How was it done in stabs? IIRC with stabs objects behaved? (but I will have to retest this)

I don't remember what stabs did to nil, or compare....

I didn't change the (Dwarf-3) encoding of class types, it already omitted the implicit pointer. But it wasn't done properly so I fixed that.

If we agree on this, we can change this.

I'll see if I can find any other differences between the code that writes the Dwarf-3 class info and the other Dwarf-formats. If we are happy with the Dwarf-2 class debug-info, maybe the Dwarf-3 code can even be removed.

Joost.

In our previous episode, Joost van der Sluis said:

And casting(?), e.g. for stuff like tlist where there are pointers class casts.

Marco van de Voort wrote

And casting(?), e.g. for stuff like tlist where there are pointers class casts.

Can you create a simple example to test this?

Joost.

Joost van der Sluis wrote

The debug-tests from Lazarus helped me a lot with this, thanks Martin for that.

I added a tool that allows to run any gdb command against several gdb/fpc versions...

It takes the same config as the tests. 2 files: fpclist.txt, gdblist.txt I attached mine as samples.

You specify a pascal program/source.
And you specify a file (of the program) and Line to set a breakpoint.

It will compile the program with each given compiler (gs,gw, godwarfset, gw3), other options given (eg -Xe), and run it in each of the debuggers. It then issues the list of commands and reports the results.

So you can quickly see what works in which version.

Martin

Martin wrote

It takes the same config as the tests. 2 files: fpclist.txt, gdblist.txt I attached mine as samples.

Xgw3 is my way to comment out gw3

I've done some more tests with -gw2. 'p classinstance' gives you the address of the class-instance and not the values within the class. That's a big issue to me. To show the class, you have to use 'p classinstance^', which is nonsense in a Pascal-way of view.

And if the classinstance is nil it shows '0x0' and not 'nil'. 'p @classinstance' will give you rubbish.

Otoh, with gw3, this all works. The patch to show 'nil' when a class is not assigned for gdb is two lines. And to be honest, I think the 'p classinstance1=classinstance2' case is a real corner-case. The cases explained above are more important, imho. (Delphi does allow class-comparisons in the debugger, but you can't add or substract anything form a classinstance. With gdb (gw2) you can)

Overall, I think that omitting the implicit-pointer as Dwarf-3 does now, is the right way to go, so I'll continue with that.

Joost.

It presumably gives you the address of the class instance pointer. It's the same in a plain Pascal program: @classinstance gives you the address in memory where the class instance pointer is located, and classinstance is the pointer (not the fields).

Otoh, with gw3, this all works. The patch to show 'nil' when a class is not assigned for gdb is two lines. And to be honest, I think the 'p classinstance1=classinstance2' case is a real corner-case.

I think that giving the class instance pointer for "p @classinstance" is quite counterintuitive. And at least I use class instance pointers a lot during debugging the compiler (for conditional breakpoints during reruns).

Jonas

...

...

Overall, I think that omitting the implicit-pointer as Dwarf-3 does now, is the right way to go, so I'll continue with that.

Another point....
The above is all true, if debugging directly in gdb...

---
In terms of consistency, stabs and dwarf both currently handle classes as pointers. Yet they display type info differently.

And currently, with both stabs and dwarf (-gw) can do: Foo.Value
withou having to write the "^".

the ^ is only needed if Foo is standalone

----
What about something like what happens with pchar? where gdb shows the address, followed by the data?

No idea, if possible....

----
So for the IDE it is already quite a trick (but entirely possible) to find out what it is looking at.

If you change the way, the data is represented in future, then my question is:
Is there any whatis or ptype command, that will have a different output? So the IDE can still detect what is happening.

Yes of course, it can look at the data returned. But that makes it even trickier. Because at current the data is only retrieved with the help of the type info, so all the workarounds for dereferencing, or casting [1] can be applied

[1] casting is needed under dwarf for param by ref types (var param / constref) =>they are encoded with that "&", they work fine, if in an expression, but not if standalone. Typecasting them, to the type they already are, makes them work.....

=> one thing would be: for "Bar: TFoo;" (where TFoo is a class) ptype Bar
~"type = TFoo = class : public TOBJECT \n"

because at current, both stabs and dwarf return: (note the "^" before TFoo) ~"type = ^TFoo = class : public TOBJECT \n"

while for using ptype on the class, not the variable ptype TFoo
dwarf has the ^ and stabs does not.....

Or not.

Because then still in dwarf3

ptype BarPointer
~"type = ^TFoo = class : public TOBJECT \n"

and the IDE was in trouble again

I've done some more tests with -gw2. 'p classinstance' gives you the address of the class-instance and not the values within the class. That's a big issue to me. To show the class, you have to use 'p classinstance^', which is nonsense in a Pascal-way of view.

That's not nonsense, because there must exist ways to access both the address and contained data. If you'd have to write "p @classinstance" instead, that wouldn't simplify anything, it only would burden the Lazarus debugger with another translation into the debugger application syntax - differently for every concrete debugger. A general debugger has no special notion of the Pascal view...

(Delphi does allow class-comparisons in the debugger, but you can't add or substract anything form a classinstance. With gdb (gw2) you can)

Delphi has its own debugger, while Lazarus has to use whatever is installed on a specific machine.

Overall, I think that omitting the implicit-pointer as Dwarf-3 does now, is the right way to go, so I'll continue with that.

As long as you don't break debugging on other users' machines...

DoDi

It might be that it is all consistent, but that way we are building a complete new universe, which is consistent with itself, but inconsistent with both the official Dwarf standard and the Pascal language. I want to clear up all the debug-mess. All hacks and workarounds, which are applied just to make it work.

The basic example: in the GDB sources there is a comment that all identifiers are uppercased, because the fpc compiler does that too. And in the fpc-compiler there was the comment that the identifiers had to be uppercased because GDB needs that. I want to get rid off that.

But yes, we need something so that Lazarus can keep both systems apart. (To make that difficult, units with other debug-formats can be used together...)

Yes, offcourse. Not that difficult, but needs a gdb patch. But then there's still the @ and the nil issues. But I have to investigate Jonas mail about that first.

You don't need the whatis and ptype commands anymore, because everything will be showed directly. This was all necessary (for classes) to work around the gdb/fpc debugging-issues. I want to solve those underlying issues.

[1] casting is needed under dwarf for param by ref types (var param / constref) =>they are encoded with that "&", they work fine, if in an expression, but not if standalone. Typecasting them, to the type they already are, makes them work.....

That was another work-around. Which isn't necessary anymore with current fpc-trunk. (You can try your lazarus-debug-tests, remove the nodwarf flags from the var-tests)

I don't understand this entirely, but we have to find a solution for this.

Joost.

You are right. I thought it was some internal (inferior) gdb-address. This makes this argument moot.

To sum up, as far as I can see now, the current gw2 implementation has only two disadvantages: it doesn't show nil, and to show the complete class you have to add '^'.

Both can be fixed in gdb, and current Lazarus already has work-arounds for this or they can be added.

Martin, do you still have any problems with classes and the -gw2 output?

Any other new arguments/problems?

Joost.

Sure.

I didn't mean that an argument against fixing things. Like "we cant fix it, because we rely on it being broken"

But yes, we need something so that Lazarus can keep both systems apart. (To make that difficult, units with other debug-formats can be used together...)

Yeah, I had that feeling, and I will have to add that to tests too.

BTW: did you see my other mails?
If you are fixing gdb too, can gdb please output "ptype set" more menaingfull?

ptype enum, gives a list of all the enum values.
ptype set (dwarf) gices: set of low..high
no way to get the other values.

The values are there, they are in the dwarf info, but gdb does not print them....

Well it sounded like gdb may need a patch (or two) anyway?

And I guess "pchar1 = pchar2 does evaluate?

there is another diff between ptype and whatis

ptype shows the final type.
ptype shows ONE ^, never mind how many levels of pointers

whatis shows the next type

type
   TFoo = Class ... end;
   PFoo = ^TFoo;
   PPFoo = ^PFoo;
var
   Foo: PPFoo;

ptype Foo
type = ^TFoo = class
// just assume the ^ is for the pointer, not the class => it would be if TFoo had been "Tfoo = Int64" instead...

whatis Foo
type = PPFoo
whatis PPFoo
type = PFoo

of course hard to say if PPFoo was just another name for PFoo type PPFoo = TYPE PFoo
(depending on symbol type, that may give 2 types in gdb)

I haven tried
whatis Foo^
but that should be a save way to detect things...

--------------
The other issue is, that issuing a command (at least on w32) is a slow thing to do.

The more ptype and whatis are needed, the worse it gets....

I will, as soon as my IDE works again => in the middle of reworking the gdb type parser....

currently both dwarf and stabsd add the ^ before classes.

Both have differnet ways to find out, if it is a real (pointer~) ^ => or a dummy, "I am a class" ^.

if I do
ptype SomeVariableObject
there will always be a ^ in front of the name

If I do
ptype TObject
ptype PObject

then stabs will give the ^ only for PObject => good but dwarf will have it both times

under dwarf I can do:
whatis TObject
whatis PObject
and it gives
type = ^TObject = class // not a pointer
type = ^TObject = // this is a pointer

Isn't live just fun???

----
So if we add new formats

I could detect

ptype Foo
type = TFoo = claa: public ...
I would see and detect the missing ^ => and I would know it is the new finally good dwarf3 encoding.

BUT
ptype FooPointer
type = ^TFoo = claa: public ...

because FooPointer is "PFoo = ^TFoo", the gdb result would (correctly) have the ^
Only now i need a way to know, this ^ does mean, what it should.

Because it looks no different from the current dummy ones................

Martin

Joost van der Sluis wrote

Martin, do you still have any problems with classes and the -gw2 output? Any other new arguments/problems?

Is -gw2 the same as -gw ?

See my other mail. I can interpret them 99% good.

Some deeply nested types may not work (or would require a lot of whatis being sent to gdb...)

Also in addition to my last mail:
in current -gw
the
type = ^TFoo = class
becomes
type = &Foo = class

for var param.

The & replaces the ^
=> while for none classes you get both
ptype PIntVarParam
type ^&Integer

but that isn't to much of an issue....

What will happen to "procedure of object" ?

currently on Stabs
<ptype ArgObjProcedure>
&"ptype ArgObjProcedure\n"
~"type = ^(procedure )\n"
^done
(gdb)

and on Dwarf
<ptype ArgObjProcedure>
&"ptype ArgObjProcedure\n"
~"type = record \n"
~" procedure Proc(POINTER, LONGINT, SHORTSTRING);\n" ~" Self : TOBJECT;\n"
~"end\n"

That one just crashed, when I tested with stabs

Martin

Works here. Do you have an example program?

And what I've discovered is that this version doesn't work right, if the file being debugged is specified on the command line, and isn't in the current directory. Maybe that that is your problem?

Joost.

The latest version of my testcase.

Running the TTEstExceptionOne with
fpc 2.4.2 stabs
the above gdb

and other combinations too

-------------------
btw, does that version also include full support for all string types already?

did you see my question in the other mail? is -gw = dwarf2, or is there a diff between -gw and -gw2 ?

Is the decission on how classes are encoded (no pointer deref any longer) final, or still just consideration?
(if it is final, I need to fix, getting exception msg...

> TCmdLineDebugger.SendCmdLn "x/s ^Exception($eax)^.FMessage"

<< TCmdLineDebugger.ReadLn "&"x/s ^Exception($eax)^.FMessage\n"" << TCmdLineDebugger.ReadLn "&"A syntax error in expression, near `FMessage'.\n""
obviously the ^ has to go....

Also need to find why it breaks:

> TCmdLineDebugger.SendCmdLn "-data-evaluate-expression

^^shortstring(^POINTER($eax)^+12)^^"
<< TCmdLineDebugger.ReadLn "^error,msg="A syntax error in expression, near `shortstring(^POINTER($eax)^+12)^^'.""
TGDBMIDebugger.ProcessResult Error: ,msg="A syntax error in expression, near `shortstring(^POINTER($eax)^+12)^^'."

but the alternative seems to work:

> TCmdLineDebugger.SendCmdLn "-data-evaluate-expression

^char(^pointer(^POINTER($eax)^+12)^+1)"
<< TCmdLineDebugger.ReadLn "^done,value="0x410821 'Exception'"" << TCmdLineDebugger.ReadLn "(gdb) "

Martin

I'll try. But I have a little problem with git again, so it can take a few hours until I have the source in a valid state again.

------------------- btw, does that version also include full support for all string types already?

It should, yes.

did you see my question in the other mail? is -gw = dwarf2, or is there a diff between -gw and -gw2 ?

I think not, if -gw would create dwarf-1 info, it woudn't contain classes... So the default Dwarf format is probably -gw2.

I think it will stay as it is, now. Until something new pops-up. (that is, an implicit pointer will be added)

I've never really understood why this is necessary?

We should fix fpc so that it is possible to compile the rtl in such a way that debug-info is added for TException.

Joost.

I did some more test., I will check in later...

None of the old dwarf or stabs seems to define the operator for classes. p FooBar
gives unknown symbold FooBar
So it does take it as one symbol?

nil
nil is not defined ever.
but under stabs dwarf2 Foo=0 works

Dwarf 3:
While the debugger can not do "@ArgTFoo^" in any stabs/dwarf, with the older formats it can do "(@ArgTFoo)^" (apparently a question of the order in which the operators are applied)
Under dwarf 3 this fails.
It outputs a class, so it has correctly gotten the type => but the data in the class, the values of the members are wrong. So it may have somewhere messed the address up ?

a: PAnsiString = 'abc'
-data-evaluate-expression a^
empty string, but shopuld be 'abc'

Martin wrote

I did some more test., I will check in later...

Variant has also changed. Maybe intended, but no result can be optained...

*** gdb 7.2-50 (fpc trunk / Dwarf3) TTestWatches TTestWatches TestWatches

<ptype ArgVariantInt>
&"ptype ArgVariantInt\n"
~"type = Variant = record \n"
~" <no data fields>\n"
~"end\n"
^done
(gdb)
<-data-evaluate-expression ArgVariantInt>
^done,value="{}"
(gdb)

*** it used to be:
*** gdb 7.0 (fpc 2.4.2 / Stabs) TTestWatches TTestWatches TestWatches

<ptype ArgVariantInt>
&"ptype ArgVariantInt\n"
~"type = VARIANT = record \n"
~" VTYPE : WORD;\n"
~" RES1 : WORD;\n"
~" RES2 : WORD;\n"
~" RES3 : WORD;\n"
~" VSMALLINT : SMALLINT;\n"
~" VINTEGER : LONGINT;\n"
~" VSINGLE : record <unknown>;\n"
~" VDOUBLE : DOUBLE;\n"
~" VDATE : TDATETIME;\n"
~" VCURRENCY : record <unknown>;\n"
~" VOLESTR : PWIDECHAR;\n"
~" VDISPATCH : POINTER;\n"
~" VERROR : HRESULT;\n"
~" VBOOLEAN : record <unknown>;\n"
~" VUNKNOWN : POINTER;\n"
~" VSHORTINT : SHORTINT;\n"
~" VBYTE : BYTE;\n"
~" VWORD : WORD;\n"
~" VLONGWORD : LONGWORD;\n"
~" VINT64 : INT64;\n"
~" VQWORD : QWORD;\n"
~" VWORD64 : QWORD;\n"
~" VSTRING : POINTER;\n"
~" VANY : POINTER;\n"
~" VARRAY : PVARARRAY;\n"
~" VPOINTER : POINTER;\n"
~" VRECORD : POINTER;\n"
~" PRECINFO : POINTER;\n"
~" VLONGS : record <unknown>;\n"
~" VWORDS : record <unknown>;\n"
~" VBYTES : record <unknown>;\n"
~"end\n"
^done
(gdb)
<-data-evaluate-expression ArgVariantInt>
^done,value="{VTYPE = 16, RES1 = 0, RES2 = 0, RES3 = 0, VSMALLINT = 5, VINTEGER = 5, VSINGLE = <incomplete type>, VDOUBLE = 2.4703282292062327e-323, VDATE = 2.4703282292062327e-323, VCURRENCY = <incomplete type>, VOLESTR = 0x5 <Address 0x5 out of bounds>, VDISPATCH = 0x5, VERROR = 5, VBOOLEAN = <incomplete type>, VUNKNOWN = 0x5, VSHORTINT = 5, VBYTE = 5, VWORD = 5, VLONGWORD = 5, VINT64 = 5, VQWORD = 5, VWORD64 = 5, VSTRING = 0x5, VANY = 0x5, VARRAY = 0x5, VPOINTER = 0x5, VRECORD = 0x5, PRECINFO = 0x0, VLONGS = <incomplete type>, VWORDS = <incomplete type>, VBYTES = <incomplete type>}"

Martin, you go way too fast. ;) The decision to change the Dwarf3-object behavior was taken yesterday, and not even final. So now a patch has to be written and committed. (Well, it is written...)

Same for variants and the enumerations. Your input is valuable, though. Maybe better to open bug-reports for the variants and enumerations. So it won't be forgotten.

For now I my main point is to get a proper case-sensitivity fix. Without that the rest of dwarf-3 is useless anyway.

btw: you can see what is changed for Dwarf-3 yourself very easily. It's all in compiler/dbgdwarf.pp. The Dwarf-3 class overrides some methods. (Indeed also those for variants)

Joost.

There's a new version at that location now. This one has a better case-sensitivity patch and support for viewing class-constants. For those interested...

Joost.

Forbidden

You don't have permission to access
/downloads/gdb_win32_fedora15_with_pascal_patches.zip on this server.

Best regards,
Paul Ishenin

Fixed.

Joost

The new one crashes, when my test application is run (dwarf and dwarf 3):

> TCmdLineDebugger.SendCmdLn "-exec-continue"

<< TCmdLineDebugger.ReadLn "^running"
<< TCmdLineDebugger.ReadLn "*running,thread-id="all"" << TCmdLineDebugger.ReadLn "(gdb) "
<< TCmdLineDebugger.ReadLn "&"stack.c:293: internal-error: print_frame_args: Assertion `nsym != NULL' failed.\nA probl m internal to GDB has been detected,\nfurther debugging may prove unreliable.""
[Debugger] Log output: &"stack.c:293: internal-error: print_frame_args: Assertion `nsym != NULL' failed.\nA problem in ernal to GDB has been detected,\nfurther debugging may prove unreliable." << TCmdLineDebugger.ReadLn "&"\n""
[Debugger] Log output: &"\n"
<< TCmdLineDebugger.ReadLn ""
<< TCmdLineDebugger.ReadLn "This application has requested the Runtime to terminate it in an unusual way.
lease contact the application's support team for more information." [DBGTGT] This application has requested the Runtime to terminate it in an unusual way.
lease contact the application's support team for more information.

I coudn't reproduce, but I had some local changes. I reverted them and now I also have some strange results. I have no time to invest this now any further. But maybe you can try with my local changes. (Although in principle this shoudn't make any difference)

Index: gdbmidebugger.pp
=================================================================== --- gdbmidebugger.pp (revision 28962)
+++ gdbmidebugger.pp (working copy)
@@ -2979,7 +2979,7 @@

     // check whether we need class cast dereference
     if ExecuteCommand('ptype TObject', R)
     then begin

- if (LeftStr(R.Values, 15) = 'type = ^TOBJECT')
+ if (sametext(LeftStr(R.Values, 15),'type = ^TOBJECT'))

       then include(TargetInfo^.TargetFlags, tfClassIsPointer);
     end;

@@ -5437,6 +5437,7 @@
       // for win32, turn off a new console otherwise breaking gdb will
fail
       // ignore the error on other platforms
       ExecuteCommand('-gdb-set new-console off', [cfIgnoreError]);
+      ExecuteCommand('-gdb-set case-sensitive off', []);
       if not ParseGDBVersionMI then ParseGDBVersion;
       CheckGDBVersion;

IT could be this line => but with it, all my other gdb versions start failing => including the one I use to run the testcase (the one I have configured in lazarus / 7.2-1)

But it's the same line in the error msg => so seems there is something.

That is bad news, because it seems like it that the final-case-sensitivity solution will be that the case-sensitive flag is used to control the behavior. But that will then break backwards compatibility...
A solution could be that the default case-sensitivity setting is set to 'auto' by Lazarus, and that we set 'off' as the default for Pascal in newer GDB versions, that do properly support it. I don't know if that works, though. And I don't know what Pierre thinks of this.

But it's the same line in the error msg => so seems there is something.

The underlying problem is that a symbol is found, and then somewhere else in the code, gdb needs some more information about the symbol. It tries to look up the symbol, but can't find it anymore. Then you get this assertion-problem. So it has indeed to do with the symbol-search routines. (Which are indeed broken when case-sensitivity is set off in unpatched versions of gdb)

Joost.

The IDE can make decisions based on GDB version. So if it gets fixed cross platform, and I know the version...

Btw, I am still trying to figure out, I've seen 3 diff notations of version 5.2.1-1 / 7.0.50 / 7.2-50
So I can interpret either as:
Version . SubVersion [ . MinorVersion ] [ - patchlvl ] Or
Version . SubVersion ( . | - ) patchlvl # and discard -1 in 5.2.1.-1

Alternatively, gdb could output some info somewhere, e.g in the version string....

Martin

Well, the version I use has version 7.2.50.20110107-cvs. But those version-numbers are a mess. Especially since Fedora in fact uses a fork of gdb (Archer) but it has the same name. It's this fork I base my work on. And I don't think you can detect the difference between the forked (archer) gdb and the original one.

Maybe another way to detect this is: (After an application is loaded, but you have to do this only once)

set case off
b MaiN
-> fails = old/no case-insensitive support = set case on (or auto) -> works = new/working case-insensitive support = set case off

Or is that too ugly?

Joost

Maybe possible, but I would have to do it the save way, that is, the IDe needs to detect if gdb crashed, and then be able to restart, and omit... => that is some extra worrk...
Or maybe, it will be enough if I just combine that with the version check too. (need to find out.

Also need to see what else can be used in the version string:

"This GDB was configured as "i686-pc-mingw32"."
Not sure what that was on fedora?

Not sure if yur patched version can add something unique?

Alternatively, as soon as I fix the user-config for the debugger (in the ide options) to be persistent (there is a mantis issue, so apparently it doesn't work)
Then I could just add an option, and leave it to the user...

What are the chances for that to be fixed in

No, I think it won't crash. (Mine old gdb didn't)

Well, the official rpm: x86_64-redhat-linux-gnu, but he one I build myself: x86_64-unknown-linux-gnu

Not sure if yur patched version can add something unique?

That's possible. But give it some time and there will be other versions with these patches too. But to show what is possible, this is the outpu of an official rpm:

GNU gdb (GDB) Fedora (6.8.50.20090302-40.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.

So the 'Fedora' string is added. I could make it something like 'Pascal-edition' ?

Alternatively, as soon as I fix the user-config for the debugger (in the ide options) to be persistent (there is a mantis issue, so apparently it doesn't work) Then I could just add an option, and leave it to the user...

That's an idea. This is only useful if the user also uses -gw3.

What are the chances for that to be fixed in

In what...?

Joost.

Strange. Some of my mail didn't make it...

What are the chances of the assertation bug being fixed in other branches of gdb? how soon?

Joost van der Sluis wrote

That is bad news, because it seems like it that the final-case-sensitivity solution will be that the case-sensitive flag is used to control the behavior. But that will then break backwards compatibility...

I have osx, freebsd, linux and windows as targets. Currently debugging with lazarus under osx is a horrible experience :-). (http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Known_Problems and more)

Is there a chance to build (your) patched gdb versions for that targets too? So that there is the possibility to have the same (working) gdb version for all targets.(dreaming)
Maybe even a static build? (more dreaming)

As this is our daily business I think I am able to donate some time in testing/debugging/codeing too,
if that could help.

helmut

Won't be soon. Because the patch to fix the case-insensitive searching depends on another patch. (the full symtab expansion-patch) That patch is quite big and leads to some regressions in the gdb-testsuite. Which needs some more patches. All those patches are in the review-queue of gdb, and this queue is huge...

So, half a year? A year?

More info: ('FSF gdb' is the original gdb-version) http://sourceware.org/ml/gdb/2011-01/msg00029.html

Joost.

You can search "macports gdb" for a gdb 7.1 for osx.

BUT afaik it doesn't start app-bundles, you need to start the exe inside the bundle directly => which may cause other issues...

Also the same may be true for the gdb discussed in these mails => afaik only the special gdb by apple does the bundle support => and that still is 6.3-50

-------
Also the gdb of these mails, is about improved displaying of certain data types.

- objects, if gdb is used outside the IDE => in the IDE it's already done
- strings with index: SomeStringFoo[1] is the first (1-based index) char, but gdb thinks it is the 2nd.
- some other data types...
------------
For your issues probably start a new mail thread (and on the lazarus list) => it it is about the way watches display data, then describe what you get, and what you expect.. => though in this case not all will be fixed in the IDE, and some may be better with this new gdb.

=> if it is, about the gdb hangs, or crashes.... then there will be a need for plenty of logs, etc.

Martin

Joost van der Sluis wrote

Same for variants and the enumerations. Your input is valuable, though. Maybe better to open bug-reports for the variants and enumerations. So it won't be forgotten.

I' ll be happy to open reports, I wasn't sure, since I can not tell if an issue is fpc or gdb....

More:
array types, but similar for strings

   type
     TDynIntArray = Array of Integer;
     TStatIntArray = Array [5..9] of Integer;
   var
     VarDynIntArray: TDynIntArray;   // named type
     VarDynIntArrayA: Array of Integer;    // "anonymous" type => hence
the "A" postfix of the var-name
     VarStatIntArray: TStatIntArray;
     VarStatIntArrayA: Array [5..9] of Integer;

**** dynamic arrays

<ptype VarDynIntArray> ~"type = array [0..1] of LongInt\n" #GOOD <ptype VarDynIntArrayA> ~"type = array [0..1] of LongInt\n" <whatis VarDynIntArray> ~"type = TDynIntArray\n" #GOOD <whatis VarDynIntArrayA> ~"type = array [0..-4220246888] of LongInt\n" # Interesting difference in the range.... but does not mean it's wrong

# IMHO it would be nice if the type resolved too
<ptype TDynIntArray> ^error,msg="Cannot resolve DW_OP_push_object_address for a missing object"
<whatis TDynIntArray> ^error,msg="Cannot resolve DW_OP_push_object_address for a missing object"

<whatis @VarDynIntArray> ~"type = ^TDynIntArray\n" #GOOD <ptype @VarDynIntArray>
~"type = ^"
^error,msg="Cannot resolve DW_OP_push_object_address for a missing object"

**** static arrays
<ptype VarStatIntArray> ~"type = array [5..9] of LongInt\n" #GOOD <ptype @VarStatIntArray> ~"type = ^LongInt\n" # where is the array gone ? => but probably a gdb issue

# Are staic arrays pointers?
/ The same for the DynArray is ok, but for static? <ptype VarStatIntArray^> ~"type = LongInt\n"

* 2)

The problem is now that debug-problems aren't reported and no-one feels responsible for them because it could be that it's someone elses problem.

Just report them, I (we) can always look if it is a gdb or fpc issue. And ask on the gdb lists for help.

It's not as if you just add bugs to the bug-tracker, without any investigation or background-info. ;)

Are fully implemented in Dwarf-3 and the gdb I've send. I don't think it is a good spending of my time to let the Dwarf-2 info give nice messages that it won't work. ;)

It works with some luck in some cases. I don't think I'll spend time on that. But please open a bug-report. Maybe I or someone else will.

Joost.