Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2009-07

Dwarf type-information for gdb

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Joost van der Sluis

Hi all,

I discovered that when you use a type in a program, and this type is not defined in a unit for which debug-info is generated, there is no DW_TAG_typedef entry generated for the dwarf-debuginfo.

The result is that gdb doesn't recognise the type. Using 'ptype <typename>' will result in the message that the type is not found.

When you use 'info type' the type is in the list, but not in the form

type longing=longint

but only:

longint=longint
(this is the dw_tag_reference_type entry in the dwarf-debuginfo)

The attached patch solves the problem, but I doubt this is the right place to do this, since this way the 'DW_TAG_typedef' entry is always added, and in some cases double.

How (and where) to fix this properly? And can someone see if this is a problem within gdb, or is it according to the dwarf-specs that this entry should be there?

Joost.

Reply by email

Jonas Maebe
to Joost van der Sluis
Joost van der Sluis wrote 5 lines
The attached patch solves the problem, but I doubt this is the right place to do this, since this way the 'DW_TAG_typedef' entry is always added, and in some cases double. How (and where) to fix this properly?

I guess by removing the Darwin :1614, and by
removing the :2263-2274 (i.e., by making all that
code active for all targets, not just for Darwin).

And can someone see if this is a problem within gdb, or is it according to the dwarf-specs that this entry should be there?

I don't think the DWARF specs say anything particular about this. But in a way, it is logical. If you don't have a separate typedef, then it is like using something like "var a: record a: longint; end;" in Pascal. I.e., there is some kind of inline type definition, but it's not defined as a separate entity.

The difference is that in DWARF you can also associate a name with such inline type definitions and you can refer multiple times to it (for debug info size reasons), but that in itself does not make them independent entities that stand on their own.

Jonas

Reply by email

Joost van der Sluis
to Jonas Maebe

Op zondag 19-07-2009 om 21:23 uur [tijdzone +0200], schreef Jonas Maebe:

Show quoted text 11 lines
On 19 Jul 2009, at 20:57, Joost van der Sluis wrote: > The attached patch solves the problem, but I doubt this is the right > place to do this, since this way the 'DW_TAG_typedef' entry is always > added, and in some cases double. > > How (and where) to fix this properly? I guess by removing the Darwin :1614, and by removing the :2263-2274 (i.e., by making all that code active for all targets, not just for Darwin).

Yes, that works. It's almost the same as mine patch, only you add it before appenddef, I did it afterwards. And you removed the code which adds it as a duplicate.

Show quoted text 14 lines
> And can someone see if this is a > problem within gdb, or is it according to the dwarf-specs that this > entry should be there? I don't think the DWARF specs say anything particular about this. But in a way, it is logical. If you don't have a separate typedef, then it is like using something like "var a: record a: longint; end;" in Pascal. I.e., there is some kind of inline type definition, but it's not defined as a separate entity. The difference is that in DWARF you can also associate a name with such inline type definitions and you can refer multiple times to it (for debug info size reasons), but that in itself does not make them independent entities that stand on their own.

So we have to add the typedefs always, and not only for Darwin. Can you commit it and change the Darwin-essay a bit so that it still holds?

Joost.

Reply by email

Peter Popov
to Joost van der Sluis: I discovered that when you use a type in a program, and this type is not defined in a…

I have been testing lately fpc 2.2.4 on a linux powerpc5+. I am seeing some issues with threads. I use cthreads and a very simple test crashes with segmentation fault. Is anyone aware of known issues with threads on linux/powerpc? I am not posting this is a bug yet because the platform is weird (suse running on the front end node of an IBM Blue Gene/P supercomputer), and I am trying to debug some more.

Thanks
Peter

Reply by email