This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Removing DW_AT_MIPS_linkage_name from dwarf2read.c



> Yes.  The C++ One Definition Rule basically says that classes with the same
> name in different translation units must be equivalent.  See
> 
>   http://www.cygnus.com/iso/wp/html/fdis/basic.html#basic.def.odr
> 
> for the (rather legalistic) details.

Okay, that's very convenient.

So, here's my understanding of the status quo:

If you define a class in a header file, and #include that file into
several compilation units, GDB will create a separate type structure
describing that class for each compilation unit.

Suppose this class has a static field.  In order to find the static
field's physical address, each GDB type object records the field's
physical (mangled) name, and then looks it up when the field is
referenced.  So the physical address fields of the type objects get
filled in as they are used.  The function value_static_field takes
care of this.

(In stabs, the definition doesn't tell us anything about the class it
belongs to, so the linkage name is the only method we have to find the
physical address.)

According to C++'s rules, it would not be incorrect to have the Dwarf2
reader check for extant definitions for types, and re-use their type
objects.  (It should check that the two declarations match, which is
hard, but that's a separate issue.)  Thus, there would be only one GDB
type object for each class.  Then, as you say, when we find the
definition for the static member, we could set the PHYSADDR field and
all of GDB would be able to find it easily.

This change would only cause problems in programs which are incorrect
anyway: programs that have different definitions of a class of the
same name in different files.

This still bothers me, though.  You're throwing away information about
how the program was actually compiled, in favor of assumptions about
how it *should* have been compiled.

What's the immediate problem you're trying to solve?  You say the
DW_AT_MIPS_linkage_name attributes take up a lot of space; are there
really that many static class members flying around?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]