Re: [PATCH 2 PR gdb/16959] gdb hangs in infinite recursion

[Wei-min Pan <weimin.pan@oracle.com>]

On 3/22/2018 1:27 PM, Simon Marchi wrote:
> On 2018-03-22 01:41 PM, Weimin Pan wrote:
>> The original problem was fixed (see related PR 22242). But using a typedef
>> as the declared type for a static member variable, as commented in this PR,
>> is still causing gdb to get into infinite loop when printing the static
>> member's value. This problem can be reproduced as follows:
>>
>> % cat t.cc
>> class A {
>>      typedef A type;
>> public:
>>      bool operator==(const type& other) { return true; }
>>
>>      static const type INSTANCE;
>> };
>>
>> const A A::INSTANCE;
>>
>> int main() {
>>      A a;
>>      if (a == A::INSTANCE) {
>>          return -1;
>>      }
>>      return 0;
>> }
>> % g++ -g t.cc
>> % gdb -ex "start" -ex "p a" a.out
>>
>> The fix is rather trivial - in cp_print_static_field(), should call
>> check_typedef() to get the static member's real type and use it to
>> check whether it's a struct or an array.
>>
>> Added a new test case to the testsuite as Simon suggested.
>>
>> Tested on both aarch64-linux-gnu and amd64-linux-gnu. No regressions.
>> ---
>> ---
>>   gdb/ChangeLog                                 |    7 ++++
>>   gdb/cp-valprint.c                             |    2 +-
>>   gdb/testsuite/ChangeLog                       |    5 +++
>>   gdb/testsuite/gdb.cp/static-typedef-print.cc  |   35 +++++++++++++++++++++
>>   gdb/testsuite/gdb.cp/static-typedef-print.exp |   40 +++++++++++++++++++++++++
>>   5 files changed, 88 insertions(+), 1 deletions(-)
>>   create mode 100644 gdb/testsuite/gdb.cp/static-typedef-print.cc
>>   create mode 100644 gdb/testsuite/gdb.cp/static-typedef-print.exp
>>
>> diff --git a/gdb/ChangeLog b/gdb/ChangeLog
>> index d0a8dfd..6fd43de 100644
>> --- a/gdb/ChangeLog
>> +++ b/gdb/ChangeLog
>> @@ -1,3 +1,10 @@
>> +2018-02-07  Weimin Pan  <weimin.pan@oracle.com>
>> +
>> +	PR gdb/16959
>> +	* cp-valprint.c: (cp_print_static_field) Use check_typedef() to get
>> +	static member's real type for TYPE_CODE_STRUCT and TYPE_CODE_ARRAY
>> +	comparisons.
>> +
>>   2018-01-24  Pedro Alves  <palves@redhat.com>
>>   
>>   	GCC PR libstdc++/83906
>> diff --git a/gdb/cp-valprint.c b/gdb/cp-valprint.c
>> index 486653f..0370b56 100644
>> --- a/gdb/cp-valprint.c
>> +++ b/gdb/cp-valprint.c
>> @@ -633,6 +633,7 @@ cp_print_static_field (struct type *type,
>>         return;
>>       }
>>   
>> +  type = check_typedef (type);
>>     if (TYPE_CODE (type) == TYPE_CODE_STRUCT)
>>       {
>>         CORE_ADDR *first_dont_print;
>> @@ -658,7 +659,6 @@ cp_print_static_field (struct type *type,
>>         addr = value_address (val);
>>         obstack_grow (&dont_print_statmem_obstack, (char *) &addr,
>>   		    sizeof (CORE_ADDR));
>> -      type = check_typedef (type);
>>         cp_print_value_fields (type, value_enclosing_type (val),
>>   			     value_embedded_offset (val), addr,
>>   			     stream, recurse, val,
> I pointed this out in my previous mail:
>
> type is passed below to val_print.  I think it would be better to continue
> passing the original type to that function instead of the resolved type.  It
> could affect how things are printed (if the type name is printed somewhere,
> or if pretty printers are involved).  Many functions use a variable "real_type"
> to hold the result from check_typedef, you could follow that pattern.
>
> Did you have a chance to take a look?
>
> Simon

Sorry, I missed it. Will take a look.

Thanks,
Weimin