This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units
- From: Daniel Jacobowitz <drow at false dot org>
- To: Fred Fish <fnf at specifix dot com>
- Cc: Jim Blandy <jimb at red-bean dot com>, gdb-patches at sourceware dot org
- Date: Sat, 11 Feb 2006 13:35:00 -0500
- Subject: Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units
- References: <200601031517.50309.fnf@specifix.com> <200601231435.47790.fnf@specifix.com> <8f2776cb0601231245y6bc1e8a4yc80070284575e654@mail.gmail.com> <200602101935.06700.fnf@specifix.com>
On Fri, Feb 10, 2006 at 07:35:06PM -0500, Fred Fish wrote:
> On Monday 23 January 2006 15:45, Jim Blandy wrote:
> > On 1/23/06, Fred Fish <fnf@specifix.com> wrote:
> > > This is why I think the correct and complete solution is to allow the
> > > user to directly specify the context.
> >
> > Sure. That would entail extending the 'type_exp' non-terminal to have
> > a FILENAME COLONCOLON TYPE production. Sounds like the right thing.
>
> The below patch seems to fix ptype and whatis to allow the
> 'file'::typename syntax, without breaking anything else and also
> simplifying ptype_command.
>
> Comments?
Don't you get a warning compiling this? It looks to me like, with
objectprint set, ptype and whatis will now blow up; they call
value_rtti_target_type without initializing val.
Also ptype will now do the RTTI lookup; I'm not sure whether it should
or not. The documentation for whatis and ptype leaves me way
unenlightened about what the difference between them is supposed to
be; perhaps we should eliminate the difference.
--
Daniel Jacobowitz
CodeSourcery