From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Sami Wagiaalla <swagiaal@redhat.com>
Subject: Re: [patch 2/2] ptype should list also class's typedefs
Date: Mon, 28 Jun 2010 18:22:00 -0000 [thread overview]
Message-ID: <m3sk47xbih.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20100625212929.GB14185@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Fri, 25 Jun 2010 23:29:29 +0200")
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Tom> It is customary to make new wrapper macros for new fields here.
Tom> I'm not sure that adds much benefit, but maybe just consistency is a
Tom> good enough reason.
Jan> Asked about, no response so I have implemented it as you say, not
Jan> agreed upon. gdbtypes.h #defined field accessors
Jan> http://sourceware.org/ml/gdb/2010-06/msg00121.html
Sorry about the lack of a response.
I will reply to this separately.
Tom> Access permissions are also dropped, that seems maybe a little more
Tom> useful.
Jan> I was not aware they apply. Filed GCC PR debug/44668 and GDB PR
Jan> c++/11757.
Thanks.
Jan> There is no memory difference as read_type_die is used by both and
Jan> the same TYPE_CODE_TYPEDEF type gets shared by
Jan> get_die_type->htab_find_with_hash.
Thanks.
Jan> GDB now displays:
Jan> (gdb) ptype C
Jan> type = class C {
Jan> private:
Jan> C::t g(C::t);
Jan> typedef int t;
Jan> }
Jan> As `g' is printed without `C::' I believe even ` t;' should not be
Jan> ` C::t;'.
Yeah, I agree. This output looks reasonable, I think I misunderstood
what would be printed here.
Jan> GDB currently does not try to shorten some common namespaces and it always
Jan> uses fully qualified names. It could probably shorten at least `std::':
Jan> Do you suggest to already implement some form of such namespaces
Jan> shortening? I have no clue how it fits into some general GDB
Jan> namespaces shortening plan.
I don't think we have any actual plan here.
Originally we had talked about making gdb print "whatever the user
wrote". There's at least one GCC PR on this topic; the issue is that
GCC doesn't preserve the needed information in the DWARF, and arguably
it should not.
Roland had a couple of ideas in this area that seemed quite nice to me:
http://sourceware.org/ml/archer/2009-q3/msg00011.html
http://sourceware.org/ml/archer/2009-q3/msg00012.html
But AFAIK nobody is working on these yet.
Jan> 2010-06-25 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> * c-typeprint.c (c_type_print_base): For no fields check include also
Jan> TYPE_TYPEDEF_FIELD_COUNT. Print new typedefs section.
Jan> * dwarf2read.c (struct typedef_field_list)
Jan> (struct field_info) <typedef_field_list, typedef_field_list_count>: New.
Jan> (dwarf2_add_typedef): New.
Jan> (read_structure_type): Call dwarf2_add_typedef for DW_TAG_typedef.
Jan> Copy also FI.TYPEDEF_FIELD_LIST.
Jan> * gdbtypes.h (struct typedef_field)
Jan> (struct cplus_struct_type) <typedef_field, typedef_field_count>
Jan> (TYPE_TYPEDEF_FIELD_ARRAY, TYPE_TYPEDEF_FIELD, TYPE_TYPEDEF_FIELD_NAME)
Jan> (TYPE_TYPEDEF_FIELD_TYPE, TYPE_TYPEDEF_FIELD_COUNT): New.
Jan> 2010-06-25 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> * gdb.cp/namespace.exp (ptype OtherFileClass typedefs)
Jan> (ptype ::C::OtherFileClass typedefs): New.
Jan> * gdb.cp/namespace1.cc (C::OtherFileClass::cOtherFileClassType2)
Jan> (C::OtherFileClass::cOtherFileClassVar2): New.
Jan> (C::OtherFileClass::cOtherFileClassVar_use): Use also
Jan> cOtherFileClassVar2.
Jan> (C::cOtherFileType2, C::cOtherFileVar2): New.
Jan> (C::cOtherFileVar_use): use also cOtherFileVar2.
Jan> * gdb.cp/userdef.exp (ptype &*c): Permit arbitrary trailing text.
This is ok. Thanks.
Tom
next prev parent reply other threads:[~2010-06-28 18:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-14 15:59 Jan Kratochvil
2010-06-17 2:32 ` Tom Tromey
2010-06-25 21:29 ` Jan Kratochvil
2010-06-28 18:22 ` Tom Tromey [this message]
2010-06-28 20:42 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3sk47xbih.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=swagiaal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox