This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 8/9] class-local typedef substitutions
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 31 Oct 2012 19:17:47 +0000
- Subject: Re: [PATCH 8/9] class-local typedef substitutions
- References: <87vcfphdl8.fsf@fleche.redhat.com> <87sjabrx4g.fsf@fleche.redhat.com>
On 09/21/2012 08:31 PM, Tom Tromey wrote:
> Tom> This patch implements class-local typedef substitutions for the C++
> Tom> type printer. That is, when printing a type, gdb will now look at
> Tom> template argument names (if any) and typedefs defined in the class
> Tom> body, and substitute those names when printing type names.
>
> More testing revealed an oddity in this code (a latent bug exposed by
> the subsequent Python patch); and the fix I chose required some changes
> to some MI test cases as well. The particular change was that
> previously gdb could emit "long int" but now it will emit just "long" --
> I consider this to be an ok (perhaps even preferable) change.
I'm confused and curious at why such a change would be necessary. I
couldn't find it from a quick look over the patch.
Can you expand a little? Does this also affect the CLI?
Why expect both long and "long int"? Is this compiler / debug format
dependent, perhaps?
> mi_list_varobj_children {struct_declarations.long_array --all-values} {
> - {struct_declarations.long_array.0 0 0 "long int" 1234}
> - {struct_declarations.long_array.1 1 0 "long int" 2345}
> - {struct_declarations.long_array.2 2 0 "long int" 3456}
> - {struct_declarations.long_array.3 3 0 "long int" 4567}
> - {struct_declarations.long_array.4 4 0 "long int" 5678}
> - {struct_declarations.long_array.5 5 0 "long int" 6789}
> - {struct_declarations.long_array.6 6 0 "long int" 7890}
> - {struct_declarations.long_array.7 7 0 "long int" 8901}
> - {struct_declarations.long_array.8 8 0 "long int" 9012}
> - {struct_declarations.long_array.9 9 0 "long int" 1234}
> - {struct_declarations.long_array.10 10 0 "long int" 3456}
> - {struct_declarations.long_array.11 11 0 "long int" 5678}
> + {struct_declarations.long_array.0 0 0 "long( int)?" 1234}
> + {struct_declarations.long_array.1 1 0 "long( int)?" 2345}
> + {struct_declarations.long_array.2 2 0 "long( int)?" 3456}
> + {struct_declarations.long_array.3 3 0 "long( int)?" 4567}
> + {struct_declarations.long_array.4 4 0 "long( int)?" 5678}
> + {struct_declarations.long_array.5 5 0 "long( int)?" 6789}
> + {struct_declarations.long_array.6 6 0 "long( int)?" 7890}
> + {struct_declarations.long_array.7 7 0 "long( int)?" 8901}
> + {struct_declarations.long_array.8 8 0 "long( int)?" 9012}
> + {struct_declarations.long_array.9 9 0 "long( int)?" 1234}
> + {struct_declarations.long_array.10 10 0 "long( int)?" 3456}
> + {struct_declarations.long_array.11 11 0 "long( int)?" 5678}
> } "listing of names and values of children"
> mi_list_varobj_children "psnp->long_ptr" {
> - {{psnp->long_ptr.\*psnp->long_ptr} {\*psnp->long_ptr} 1 {long int \*\*\*}}
> + {{psnp->long_ptr.\*psnp->long_ptr} {\*psnp->long_ptr} 1 {long( int)? \*\*\*}}
> } "get children of psnp->long_ptr"
>
--
Pedro Alves