We observed on x86-windows that trying to call a function from
GDB leads to a mysterious "Invalid cast" error. This can be
observed in gdb.ada/float_param.exp:
(gdb) call set_long_double(1, global_small_struct, 4.0)
Invalid cast.
This happens because the 3rd parameter, a Long_Long_Float, is
actually passed wrapped inside a PAD structure. As documented
in GNAT's exp_dbug.ads, PAD types are simple wrappers that GNAT
uses to handle types with size or alignment constraints.
We already support those when printing an object encapsulated
in a PAD type, but not when trying to pass an argument that
is wrapped inside a PAD type. As a result, what happens is that
call_function_by_hand ends up with an argument with a type
that looks incompatible with the expected type of the argument.
The error comes when trying to push the arguments in inferior
memory, while trying to coerce each one of them to their expected
types (in value_arg_coerce).
Note that the problem is not specific to Windows, but so far, this is
the only platform where we've seen this happen.
gdb/ChangeLog:
* ada-lang.c (ada_convert_actual): Add handling of formals
passed inside an aligner type.
Tested on x86-windows (AdaCore testsuite) and x86_64-linux (official
testsuite as well as AdaCore's testsuite).
+2015-05-08 Joel Brobecker <brobecker@adacore.com>
+
+ * ada-lang.c (ada_convert_actual): Add handling of formals
+ passed inside an aligner type.
+
2015-05-08 Joel Brobecker <brobecker@adacore.com>
* copyright.py (NOT_FSF_LIST): Remove sim/erc32 entries.
}
else if (TYPE_CODE (actual_type) == TYPE_CODE_PTR)
return ada_value_ind (actual);
+ else if (ada_is_aligner_type (formal_type))
+ {
+ /* We need to turn this parameter into an aligner type
+ as well. */
+ struct value *aligner = allocate_value (formal_type);
+ struct value *component = ada_value_struct_elt (aligner, "F", 0);
+
+ value_assign_to_component (aligner, component, actual);
+ return aligner;
+ }
return actual;
}