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.