This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] The parameter in value_entirely_optimized_out is NULL


On 05/17/2016 03:45 PM, 建明 乔 wrote:
> Hi:
> 

FYI, something is odd with your emails -- lots of seemingly spurious empty lines:

 https://sourceware.org/ml/gdb-patches/2016-05/msg00259.html

Also, the follow up reply you sent was quite garbled, and it doesn't look
like it managed to reach the list.

> 
> 
> The GDB(v7.7 onwards) will crash at value_entirely_optimized_out (value=0x0) in some cases.
> 
> 
> 
> These cases are reported in GDB Database as Bug 20020,17076,17685 in X86 platform
> 
> 
> 
> and other reports that use cross-compiled GDB host(ARM & MIPS) from our side. 

I tried a couple tests from those bug reports, and I couldn't reproduce the problem
with current master.  Can you reproduce it reliably?  It'd be great to have a testcase
in the testsuite for this.  Best would probably be to write it using the Dwarf::assemble
mechanism (gdb/testsuite/gdb.dwarf2/).


> 
> 
> 
> 
> This bug is introduced when the patch https://sourceware.org/ml/gdb-patches/2013-10/msg00353.html  is added.
> 
> 
> 
> The code from this patch that caused the regression is listed below:
> 
> 
> 
> 
> diff --git a/gdb/cp-valprint.c b/gdb/cp-valprint.c
> index 1d7147c..4b625d1 100644
> --- a/gdb/cp-valprint.c
> +++ b/gdb/cp-valprint.c
> @@ -333,12 +333,9 @@ cp_print_value_fields (struct type *type, struct type *real_type,
>        fprintf_filtered (stream,
>            _("<error reading variable: %s>"),
>            ex.message);
> -    else if (v == NULL)
> -      val_print_optimized_out (NULL, stream);
> -    else
> -      cp_print_static_field (TYPE_FIELD_TYPE (type, i),
> -        v, stream, recurse + 1,
> -        options);
> +    cp_print_static_field (TYPE_FIELD_TYPE (type, i),
> +      v, stream, recurse + 1,
> +      options);
>    }
> 
> 
> 
> 
> Therefore, I propose to partly revert the previous patch and apply the change below.
> 
> 
> 
> 
> Is it acceptable ?

Can't tell without a more expanded rationale for the change.  E.g.,:

- Why is 'v' NULL here?

- Why is it OK for 'v' to be NULL here?

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]