Re: [RFA] Fix frame argument printing when using auto language mode

[Xavier Roirand <roirand@adacore.com>]

Hello,

This is a doable fix, I don't see any issue with it and hope that it 
will not add any side effect. I'll propose an RFA soon. Thx

Regards

Le 2/20/18 à 5:48 PM, Yao Qi a écrit :
> On Tue, Feb 20, 2018 at 4:28 PM, Xavier Roirand <roirand@adacore.com> wrote:
>>
>> It was my first idea, but it would imply a consequent amount of work because
>> when ada_val_print_1 is called, the stack is the following one:
>>
>> #0  ada_val_print_1
>> #1  ada_val_print
>> #2  val_print (got the language of the frame arg)
>>
>> So if we want to pass the per-frame language down to ada_val_print_1 then in
>> the generic val_print function, we have to change:
>>
>>        language->la_val_print (type, embedded_offset, address,
>>                                stream, recurse, val,
>>                                &local_opts);
>> to something like:
>>
>>        language->la_val_print (type, embedded_offset, address,
>>                                stream, recurse, val,
>>                                &local_opts, language);
>>                                             ^^^^^^^^
>>
> 
> We don't have to do that.  ada_val_print_1 is called in ada_val_print,
> 
>        ada_val_print_1 (type, embedded_offset, address,
>         stream, recurse, val, options,
>         current_language);
> 
> and ada_val_print is language->la_val_print in effect, so "language"
> is ada_language_defn, and we can rewrite the code above like this,
> 
>        ada_val_print_1 (type, embedded_offset, address,
>         stream, recurse, val, options,
>         &ada_language_defn);
> 
> This change may break existing behaviour.  Printing for ada (or other
> languages) shouldn't depend on current_language, IMO.
> 
>> Fix me if I'm wrong but it means that <language>_val_print functions for all
>> the supported GDB languages have to be modified in order to support the
>> language parameter.
>>
>