On 09/01/2011 19:51, Joost van der Sluis wrote:
On Sun, 2011-01-09 at 17:50 +0000, Martin wrote:
On 09/01/2011 16:56, Joost van der Sluis wrote:
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.
...
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. w2) 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.
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.
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.
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....
----
What about something like what happens with pchar?
where gdb shows the address, followed by the data?
No idea, if possible....
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.
Well it sounded like gdb may need a patch (or two) anyway?
And I guess "pchar1 = pchar2 does evaluate?
----
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.
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.
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....
[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 will, as soon as my IDE works again => in the middle of reworking the
gdb type parser....
=> 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.....
I don't understand this entirely, but we have to find a solution for
this.
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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
