public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Best way to work with settings that apply to a file (or dwarf cu)
@ 2011-10-12  9:09 Joost van der Sluis
  2011-10-16 22:12 ` Daniel Jacobowitz
  0 siblings, 1 reply; 2+ messages in thread
From: Joost van der Sluis @ 2011-10-12  9:09 UTC (permalink / raw)
  To: gdb

Hi all,

I'm wondering how to deal with some setting/flag that is bound to a
source-file, or Dwarf-compilation unit.

The problem: older Pascal compilers did use DW_TAG_structure_type for
classes instead of DW_TAG_class_type. To distinguish between classes and
records, gdb checks if HAVE_CPLUS_STRUCT is true. But this gives some
false positives. So the records are reported as classes.

If the compiler generates DW_TAG_class_type for classes, the
TYPE_DECLARED_CLASS macro can be used. But I need some way to determine
if the compiler supports that. This is doable, but where do I store this
information. The problem is that for each compiled file (Pascal unit)
this can differ. Speaking in Dwarf-terms, it could differ for each
compilation-unit. 

So I thought I could add a uses_DW_TAG_CLASS flag to a Pascal-specific
section of stuct block.

Then, in p-typeprint.c (pascal_type_print_base) I tried something like
this: 

struct block *blockvector = TYPE_OBJFILE(type)->symtabs->blockvector->block[0];
if ((!(blockvector->language_specific.free_pascal_specific.uses_DW_TAG_class) && (HAVE_CPLUS_STRUCT (type))) ||
         (TYPE_DECLARED_CLASS (type)))

This does not work. Storing the flag within the proper symtab works. But
the line above does not resolve to the correct symtab. That's because
each objfile has more then one symtabs in it's list. I assumed that
these symtabs were only for that specific file, but apperently that's
not the case.

So my question is: how do I obtain the symtab from a type?

On the other hand, I saw that this same problem also applies to the
language of a symbol. But instead of querying the symtab for the
language, the symbol has a field called language, which is set for each
symbol within a compilation-unit. (For Dwarf)

ie: all symbols do have a language setting. But for all symbols within
one symtab this setting is the same. Wouldn't it be easier to add a link
in each symbol to it's symtab, and store the language there? (This is
what I tried to do for this specific pascal-flag)

Is my reasoning right, or did I miss some crucial things in gdb's
design?

Regards,

Joost van der Sluis





^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Best way to work with settings that apply to a file (or dwarf cu)
  2011-10-12  9:09 Best way to work with settings that apply to a file (or dwarf cu) Joost van der Sluis
@ 2011-10-16 22:12 ` Daniel Jacobowitz
  0 siblings, 0 replies; 2+ messages in thread
From: Daniel Jacobowitz @ 2011-10-16 22:12 UTC (permalink / raw)
  To: Joost van der Sluis; +Cc: gdb

On Wed, Oct 12, 2011 at 5:09 AM, Joost van der Sluis <joost@cnoc.nl> wrote:
> On the other hand, I saw that this same problem also applies to the
> language of a symbol. But instead of querying the symtab for the
> language, the symbol has a field called language, which is set for each
> symbol within a compilation-unit. (For Dwarf)
>
> ie: all symbols do have a language setting. But for all symbols within
> one symtab this setting is the same. Wouldn't it be easier to add a link
> in each symbol to it's symtab, and store the language there? (This is
> what I tried to do for this specific pascal-flag)

IMO, it's going to be a lot easier if you make all you need available
in the type.  There's precedent for that in GDB.

There are a couple of reasons you don't want a type to symtab link -
for instance, handling of types which are duplicated across multiple
input files.  We don't do that very well today, but we should.

-- 
Thanks,
Daniel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-10-16 15:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-12  9:09 Best way to work with settings that apply to a file (or dwarf cu) Joost van der Sluis
2011-10-16 22:12 ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).