* read_structure_type and virtual base types
@ 2005-07-13 20:04 Thomson, Patrick S
2005-07-15 16:03 ` Kris Warkentin
0 siblings, 1 reply; 2+ messages in thread
From: Thomson, Patrick S @ 2005-07-13 20:04 UTC (permalink / raw)
To: gdb
Howdy Folks,
I'm attempting to use gdb 6.3 on an executable generated from the
latest intel c++ compiler (9.0). That particular compiler does not
generate child DIE information for member functions which are
declared but not implemented. If the class is a derived class and I
try to print an instantiated object of that class, gdb crashes.
I tracked what I think is the issue to
dwarf2read.c::read_structure_type().
At line read_structure_type()+119 we set TYPE_VPTR_BASETYPE(type),
but only if we have 1 or more member functions (see line
read_structure_type()+107 for fi.nfnfields test, this field is set at
line read_structure_type()+94).
Because I have no child DIEs for member functions, TYPE_VPTR_BASETYPE
remains 0, and I crash later on because this is eventually
dereferenced. Enough other data remains in the type structure to
indicate that the class is a derived class, so gdb expects
TYPE_VPTR_BASETYPE(type) to be set.
Since g++ does output the child die, this isn't generally a problem.
Ultimately my question is this: Is there a reason why the logic is
structured the way it is, and what is it? I can fix it easily enough
in my local copy by moving the closing brace for the
'if(fi.nfnfields){}' block so that it doesn't encompass the
DW_AT_containing_type attribute test a few lines later, but I'm not
sure what the consequences would be.
Thanks!
Pat Thomson
Intel Corporation
p.s. example class with associated DWARF DIE
class A : virtual public V{
int a;
int aa;
public:
void af(int); // declared, not implmented
};
Has the following DIE
<1><b64>: Abbrev Number: 17 (DW_TAG_class_type)
DW_AT_decl_line : 11
DW_AT_decl_column : 7
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_byte_size : 20
DW_AT_name : A
DW_AT_containing_type: <b64>
<2><b70>: Abbrev Number: 18 (DW_TAG_inheritance)
DW_AT_decl_line : 11
DW_AT_decl_column : 26
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_data_member_location: 7 byte block: 12 6 10 c 1c 6 22
(DW_OP_dup; DW_OP_deref; DW_OP_constu: 12; DW_OP_minus; DW_OP_deref;
DW_OP_plus)
DW_AT_type : <a75>
DW_AT_virtuality : 1 (virtual)
<2><b82>: Abbrev Number: 19 (DW_TAG_member)
DW_AT_name : _vptr.A
DW_AT_data_member_location: 2 byte block: 23 0
(DW_OP_plus_uconst: 0)
DW_AT_artificial : 1
DW_AT_type : <baf>
<2><b93>: Abbrev Number: 3 (DW_TAG_member)
DW_AT_decl_line : 12
DW_AT_decl_column : 9
DW_AT_decl_file : 1
DW_AT_data_member_location: 2 byte block: 23 4
(DW_OP_plus_uconst: 4)
DW_AT_name : a
DW_AT_type : <ab0>
<2><ba0>: Abbrev Number: 3 (DW_TAG_member)
DW_AT_decl_line : 13
DW_AT_decl_column : 9
DW_AT_decl_file : 1
DW_AT_data_member_location: 2 byte block: 23 8
(DW_OP_plus_uconst: 8)
DW_AT_name : aa
DW_AT_type : <ab0>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: read_structure_type and virtual base types
2005-07-13 20:04 read_structure_type and virtual base types Thomson, Patrick S
@ 2005-07-15 16:03 ` Kris Warkentin
0 siblings, 0 replies; 2+ messages in thread
From: Kris Warkentin @ 2005-07-15 16:03 UTC (permalink / raw)
To: Thomson, Patrick S; +Cc: gdb
I've actually run into the same problem:
http://sources.redhat.com/ml/gdb/2004-12/msg00074.html
You should probably talk to David Moore since you work for Intel as
well. I ran into him at the gcc summit and he asked me to follow up on
it with him. I've got a PR submitted about this since icc is supposed
to be gcc compatable. It's Intel issue #281637.
For what it's worth, I just worked around it by checking for null and
just skipping the dereference. All that happens is you see a little
less info about the class than you would otherwise.
cheers,
Kris
Thomson, Patrick S wrote:
>Howdy Folks,
>
>I'm attempting to use gdb 6.3 on an executable generated from the
>latest intel c++ compiler (9.0). That particular compiler does not
>generate child DIE information for member functions which are
>declared but not implemented. If the class is a derived class and I
>try to print an instantiated object of that class, gdb crashes.
>
>I tracked what I think is the issue to
>dwarf2read.c::read_structure_type().
>
>At line read_structure_type()+119 we set TYPE_VPTR_BASETYPE(type),
>but only if we have 1 or more member functions (see line
>read_structure_type()+107 for fi.nfnfields test, this field is set at
>line read_structure_type()+94).
>
>Because I have no child DIEs for member functions, TYPE_VPTR_BASETYPE
>remains 0, and I crash later on because this is eventually
>dereferenced. Enough other data remains in the type structure to
>indicate that the class is a derived class, so gdb expects
>TYPE_VPTR_BASETYPE(type) to be set.
>
>Since g++ does output the child die, this isn't generally a problem.
>Ultimately my question is this: Is there a reason why the logic is
>structured the way it is, and what is it? I can fix it easily enough
>in my local copy by moving the closing brace for the
>'if(fi.nfnfields){}' block so that it doesn't encompass the
>DW_AT_containing_type attribute test a few lines later, but I'm not
>sure what the consequences would be.
>
>Thanks!
>Pat Thomson
>Intel Corporation
>
>p.s. example class with associated DWARF DIE
>
>class A : virtual public V{
> int a;
> int aa;
>public:
> void af(int); // declared, not implmented
>};
>
>Has the following DIE
><1><b64>: Abbrev Number: 17 (DW_TAG_class_type)
> DW_AT_decl_line : 11
> DW_AT_decl_column : 7
> DW_AT_decl_file : 1
> DW_AT_accessibility: 1 (public)
> DW_AT_byte_size : 20
> DW_AT_name : A
> DW_AT_containing_type: <b64>
> <2><b70>: Abbrev Number: 18 (DW_TAG_inheritance)
> DW_AT_decl_line : 11
> DW_AT_decl_column : 26
> DW_AT_decl_file : 1
> DW_AT_accessibility: 1 (public)
> DW_AT_data_member_location: 7 byte block: 12 6 10 c 1c 6 22
>(DW_OP_dup; DW_OP_deref; DW_OP_constu: 12; DW_OP_minus; DW_OP_deref;
>DW_OP_plus)
> DW_AT_type : <a75>
> DW_AT_virtuality : 1 (virtual)
> <2><b82>: Abbrev Number: 19 (DW_TAG_member)
> DW_AT_name : _vptr.A
> DW_AT_data_member_location: 2 byte block: 23 0
>(DW_OP_plus_uconst: 0)
> DW_AT_artificial : 1
> DW_AT_type : <baf>
> <2><b93>: Abbrev Number: 3 (DW_TAG_member)
> DW_AT_decl_line : 12
> DW_AT_decl_column : 9
> DW_AT_decl_file : 1
> DW_AT_data_member_location: 2 byte block: 23 4
>(DW_OP_plus_uconst: 4)
> DW_AT_name : a
> DW_AT_type : <ab0>
> <2><ba0>: Abbrev Number: 3 (DW_TAG_member)
> DW_AT_decl_line : 13
> DW_AT_decl_column : 9
> DW_AT_decl_file : 1
> DW_AT_data_member_location: 2 byte block: 23 8
>(DW_OP_plus_uconst: 8)
> DW_AT_name : aa
> DW_AT_type : <ab0>
>
>
--
Stay up-to-date on all the QNX news! Register at
http://www.qnx.com/news/forms/newsletter.html to
receive our newsletter.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-07-15 16:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-07-13 20:04 read_structure_type and virtual base types Thomson, Patrick S
2005-07-15 16:03 ` Kris Warkentin
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).