[fpc-devel] Dwarf3 and the encoding of classes
fpc at mfriebe.de
Sun Jan 9 21:24:45 CET 2011
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
>>>>> (-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.
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
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
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
>> 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
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
TFoo = Class ... end;
PFoo = ^TFoo;
PPFoo = ^PFoo;
type = ^TFoo = class
// just assume the ^ is for the pointer, not the class => it would be if
TFoo had been "Tfoo = Int64" instead...
type = 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
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....
>>  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
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
there will always be a ^ in front of the name
If I do
then stabs will give the ^ only for PObject => good
but dwarf will have it both times
under dwarf I can do:
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
type = TFoo = claa: public ...
I would see and detect the missing ^ => and I would know it is the new
finally good dwarf3 encoding.
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................
More information about the fpc-devel