For displaying the full view of a class-wide object, GDB relies on
the assumption that this view will have the same address as the
address of the object. In the case of simple inheritance, this
assumption is correct; the proper type is deduced by decoding
the tag of the object and converting the result to this full-view
type.
Consider for example an abstract class Shape, a child Circle
which implements an interface Drawable, and the corresponding
following objects:
My_Circle : Circle := ((1, 2), 3);
My_Shape : Shape'Class := Shape'Class (My_Circle);
My_Drawable : Drawable'Class := Drawable'Class (My_Circle);
To display My_Shape, the debugger first extracts the tag (an internal
field, usually the first one of the record):
(gdb) p my_shape'address
$2 = (system.address) 0x8063e28
(gdb) x/x my_shape'address
0x8063e28 <classes__my_shape>: 0x08059ec4
Then the type specific data and the expanded name of the tag is read
from there:
(gdb) p my_shape'tag
$3 = (access ada.tags.dispatch_table) 0x8059ec4 (classes.circle)
To get the full view, the debugger converts to the corresponding type:
(gdb) p {classes.circle}0x8063e28
$4 = (center => (x => 1, y => 2), radius => 3)
Now, in the case of multiple inheritance, the assumption does not hold
anymore. The address that we have usually points to some
place lower. The offset to the original address is saved in the field
Offset_To_Top of the metadata that are above the tag, at address
obj'tag - 8. In the case of my_shape, this offset is 0:
(gdb) x/x my_shape'tag - 8
0x8059ebc <classes__circleT+12>: 0x00000000
...but in the case of an interface-wide object, it is not null:
(gdb) x/x my_drawable'tag - 8
0x8063b28 <classes__classes__circle_classes__drawable1T56s+12>: 0x00000004
(gdb) p {classes.circle}(my_drawable'address - 4)
$7 = (center => (x => 1, y => 2), radius => 3)
The following change handles this relocation in the most common cases.
Remaining cases that are still to be investigated are signaled by
comments.
gdb/ChangeLog:
* ada-lang.h (ada_tag_value_at_base_address): New function
declaration.
* ada-lang.c (is_ada95_tag, ada_tag_value_at_base_address):
New functions.
(ada_to_fixed_type_1, ada_evaluate_subexp): Let ada_tag_base_address
relocate the class-wide value if need be.
(ada_value_struct_elt, ada_value_ind, ada_coerce_ref):
Let ada_tag_value_at_base_address relocate the class-wide access/ref
before dereferencing it.
* ada-valprint.c (ada_val_print_1): Relocate to base address
before displaying the content of an interface-wide ref.
gdb/testsuite/ChangeLog:
* gdb.ada/ptype_tagged_param.exp: Adjust expected output in
ptype test.
Given the following variable declaration...
Www : Wide_String := "12345";
... this patch allows the following assignment to work:
(gdb) set variable www := "qwert"
Without this patch, the debugger rejects the assignment because
the size of the array elements are different:
(gdb) set www := "asdfg"
Incompatible types in assignment
(on the lhs, we have an array of 2-bytes elements, and on the rhs,
we have a standard 1-byte string).
gdb/ChangeLog:
* ada-lang.c (ada_same_array_size_p): New function.
(ada_promote_array_of_integrals): New function.
(coerce_for_assign): Add handling of arrays where the elements
are integrals of a smaller size than the size of the target
array element type.
gdb/testsuite/ChangeLog:
* gdb.ada/set_wstr: New testcase.
gdb/ChangeLog:
* ada-lang.c (ada_template_to_fixed_record_type_1): Do not
strip typedef layer when computing the fixed type's field type,
only when computing its size.
gdb/testsuite/ChangeLog:
* gdb.ada/unc_arr_ptr_in_var_rec: New testcase.
The debugger sometimes fails to re-set a breakpoint as follow,
causing it to become disabled:
(gdb) b nested_sub
Breakpoint 1 at 0x401cec: file foo.adb, line 7.
(gdb) b do_nothing
Breakpoint 2 at 0x401cdc: file pck.adb, line 4.
(gdb) run
Starting program: /[...]/foo
Error in re-setting breakpoint 1: Function "nested_sub" not defined.
Breakpoint 2, pck.do_nothing () at pck.adb:4
4 null;
This only happens on machines where the debug-file-directory is
a valid directory name.
The reason behind the error is that the linespec code that re-sets
the breakpoints uses the current_language global when iterating
over a symtab's symbols. However, the that global gets switched from
Ada to C during the startup phase, probably as a side-effect of stopping
in some system code for which debugging info is available. The fix
is to make sure that we use the correct language.
gdb/ChangeLog:
* linespec.c (iterate_over_all_matching_symtabs): Use the correct
language when iterating over symbols.
gdb/testsuite/ChangeLog:
* gdb.ada/bp_reset: New testcase.
Assuming the following declarations:
type Discriminants_Record (A : Integer; B : Boolean) is record
C : Float;
end record;
Z : Discriminants_Record := (A => 1, B => False, C => 2.0);
If variable Z is not used, and the compiler optimizes it out,
GDB would crash as follow:
(gdb) print Z
/[...]/gdb/valops.c:1121: internal-error: Unexpected lazy value type.
This is because the ada-lang module forgot to set the optimized_out
flag in the value returned by ada_evaluate_subexp during the value's
"fixing" process. Later on, when trying to print the resulting value,
GDB finds that the value is still lazily allocated, and thus tries to
fetch it. But this is not allowed for not_lval values, hence the internal
error.
gdb/ChangeLog:
* ada-lang.c (coerce_unspec_val_to_type): Make sure that
the optimized_out flag is preserved.
gdb/testsuite/ChangeLog:
* gdb.ada/optim_drec: New testcase.
* gdb.ada/rdv_wait.exp (set debug-file-directory): New command.
* gdb.arch/i386-cfi-notcurrent.S: New file.
* gdb.arch/i386-cfi-notcurrent.exp: New file.
The problem is trying to unwind from a function where %ebp is NOT
used as the frame pointer, and the size of the frame changes over
the lifetime of that function.
For instance, trying to unwind past the GNAT runtime function
called system.tasking.rendezvous.timed_selective_wait on x86-linux,
one can get:
(gdb) bt
[...]
#3 0x0805364b in system.tasking.rendezvous.timed_selective_wait ()
#4 0xb7fe5068 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Looking at the CFI, we find the following initial instructions...
> DW_CFA_def_cfa: %esp+4 (r4 ofs 4)
> DW_CFA_offset: %eip at cfa-4 (r8 = %eip)
... and the associated FDE:
> 00001be4 00000054 00001be8 FDE cie=00000000 pc=08053310..08053951
[...]
> DW_CFA_advance_loc: 8 to 080534ad
> DW_CFA_def_cfa_offset: 112
> DW_CFA_advance_loc2: 414 to 0805364b
> DW_CFA_def_cfa_offset: 108
[...]
The problem is that the DWARF frame unwinder executed the FDE until
the row for PC == 0x0805364b. But in reality, our program hasn't
executed the instruction at that address yet (it is the return address).
So GDB executed a little too much of the FDE, giving us the wrong
offset for the frame base, and thus the wrong address where %eip
got saved.
This patch fixes the problem by using a more correct PC as the bound
for executing the FDE.
gdb/ChangeLog:
* dwarf2-frame.c (dwarf2_frame_cache): Use
get_frame_address_in_block instead of get_frame_pc as
the bound for executing the frame's FDE.
gdb/testsuite/ChangeLog:
* gdb.ada/rdv_wait: New testcase.
* gdb.ada/aliased_array.exp: Use standard_ada_testfile.
* gdb.ada/array_bounds.exp: Use standard_ada_testfile.
* gdb.ada/array_return.exp: Use standard_ada_testfile.
* gdb.ada/array_subscript_addr.exp: Use standard_ada_testfile.
* gdb.ada/arrayidx.exp: Use standard_ada_testfile.
* gdb.ada/arrayparam.exp: Use standard_ada_testfile.
* gdb.ada/arrayptr.exp: Use standard_ada_testfile.
* gdb.ada/atomic_enum.exp: Use standard_ada_testfile.
* gdb.ada/bad-task-bp-keyword.exp: Use standard_ada_testfile.
* gdb.ada/bp_enum_homonym.exp: Use standard_ada_testfile.
* gdb.ada/bp_on_var.exp: Use standard_ada_testfile.
* gdb.ada/bp_range_type.exp: Use standard_ada_testfile.
* gdb.ada/call_pn.exp: Use standard_ada_testfile.
* gdb.ada/catch_ex.exp: Use standard_ada_testfile.
* gdb.ada/char_enum.exp: Use standard_ada_testfile.
* gdb.ada/char_param.exp: Use standard_ada_testfile.
* gdb.ada/complete.exp: Use standard_ada_testfile.
* gdb.ada/cond_lang.exp: Use standard_ada_testfile,
standard_output_file.
* gdb.ada/dyn_loc.exp: Use standard_ada_testfile.
* gdb.ada/enum_idx_packed.exp: Use standard_ada_testfile.
* gdb.ada/exec_changed.exp: Use standard_ada_testfile,
standard_output_file.
* gdb.ada/exprs.exp: Use standard_ada_testfile.
* gdb.ada/fixed_cmp.exp: Use standard_ada_testfile.
* gdb.ada/fixed_points.exp: Use standard_ada_testfile.
* gdb.ada/formatted_ref.exp: Use standard_ada_testfile.
* gdb.ada/frame_args.exp: Use standard_ada_testfile.
* gdb.ada/fullname_bp.exp: Use standard_ada_testfile.
* gdb.ada/fun_addr.exp: Use standard_ada_testfile.
* gdb.ada/fun_in_declare.exp: Use standard_ada_testfile.
* gdb.ada/funcall_param.exp: Use standard_ada_testfile.
* gdb.ada/homonym.exp: Use standard_ada_testfile.
* gdb.ada/info_locals_renaming.exp: Use standard_ada_testfile.
* gdb.ada/int_deref.exp: Use standard_ada_testfile.
* gdb.ada/interface.exp: Use standard_ada_testfile.
* gdb.ada/lang_switch.exp: Use standard_ada_testfile,
standard_output_file
* gdb.ada/mi_catch_ex.exp: Use standard_ada_testfile.
* gdb.ada/mi_task_arg.exp: Use standard_ada_testfile.
* gdb.ada/mi_task_info.exp: Use standard_ada_testfile.
* gdb.ada/mod_from_name.exp: Use standard_ada_testfile.
* gdb.ada/nested.exp: Use standard_ada_testfile.
* gdb.ada/null_array.exp: Use standard_ada_testfile.
* gdb.ada/null_record.exp: Use standard_ada_testfile.
* gdb.ada/operator_bp.exp: Use standard_ada_testfile.
* gdb.ada/packed_array.exp: Use standard_ada_testfile.
* gdb.ada/packed_tagged.exp: Use standard_ada_testfile.
* gdb.ada/print_chars.exp: Use standard_ada_testfile.
* gdb.ada/print_pc.exp: Use standard_ada_testfile.
* gdb.ada/ptr_typedef.exp: Use standard_ada_testfile.
* gdb.ada/ptype_field.exp: Use standard_ada_testfile.
* gdb.ada/ptype_tagged_param.exp: Use standard_ada_testfile.
* gdb.ada/rec_return.exp: Use standard_ada_testfile.
* gdb.ada/ref_param.exp: Use standard_ada_testfile.
* gdb.ada/ref_tick_size.exp: Use standard_ada_testfile.
* gdb.ada/same_enum.exp: Use standard_ada_testfile.
* gdb.ada/set_pckd_arr_elt.exp: Use standard_ada_testfile.
* gdb.ada/small_reg_param.exp: Use standard_ada_testfile.
* gdb.ada/start.exp: Use standard_ada_testfile.
* gdb.ada/str_ref_cmp.exp: Use standard_ada_testfile.
* gdb.ada/sym_print_name.exp: Use standard_ada_testfile.
* gdb.ada/taft_type.exp: Use standard_ada_testfile.
* gdb.ada/tagged.exp: Use standard_ada_testfile.
* gdb.ada/tagged_not_init.exp: Use standard_ada_testfile.
* gdb.ada/task_bp.exp: Use standard_ada_testfile.
* gdb.ada/tasks.exp: Use standard_ada_testfile.
* gdb.ada/tick_last_segv.exp: Use standard_ada_testfile.
* gdb.ada/type_coercion.exp: Use standard_ada_testfile.
* gdb.ada/uninitialized_vars.exp: Use standard_ada_testfile.
* gdb.ada/variant_record_packed_array.exp: Use standard_ada_testfile.
* gdb.ada/watch_arg.exp: Use standard_ada_testfile.
* gdb.ada/whatis_array_val.exp: Use standard_ada_testfile.
* gdb.ada/widewide.exp: Use standard_ada_testfile.
With an Ada program, trying to break on a specific Ada task, but
with the wrong capitalization of the `task' keyword, we currently
get only pieces of the "garbage" that caused the error:
(gdb) b *rendez_vous'address TASK 2
Garbage 2 at end of command
Pushing this a little further:
(gdb) b *rendez_vous'address TASK Task TaSK 2
Garbage 2 at end of command
Another interesting failure mode:
(gdb) b *rendez_vous'address TASK if
Argument required (expression to compute).
The parser skipped `TASK', then found the `if' keyword, and thus
started looking for a condition.
This patch fixes the problem by aborting the parsing as soon as
an invalid keyword is found. This makes it consistent with the
case where the REST parameter is passed as NULL (where an error
is raised immediately after seeing the first invalid keyword).
It also introduces a new testcase that reproduces all above scenarios.
gdb/ChangeLog:
* breakpoint.c (find_condition_and_thread): Stop parsing
as soon as the first invalid keyword is found.
gdb/testsuite/ChangeLog:
* gdb.ada/bad-task-bp-keyword: New testcase.
Consider the following declaration:
type Small is new Integer range 0 .. 2 ** 4 - 1;
type Simple_Array is array (1 .. 4) of Small;
pragma Pack (Simple_Array);
SA : Simple_Array := (1, 2, 3, 4);
Trying to change the value of one of the elements in the packed array
causes the debugger to crash:
(gdb) set sa(3) := 9
[1] 4880 segmentation fault gdb -q foo
The circumstances leading to the crash are as follow:
. ada_evaluate_subexp creates a value corresponding to "sa(3)".
. ada_evaluate_subexp then tries to assign 9 to this value, and
for this calls value_assign (via ada_value_assign).
. Because the array is packed, the destination value is 3 bits long,
and as a result, value_assign uses the parent to determine that
element byte address and offset:
| if (value_bitsize (toval))
| {
| struct value *parent = value_parent (toval);
|
| changed_addr = value_address (parent) + value_offset (toval);
The destination value (corresponding to "sa(3)") was incorrectly created
by ada-lang.c:ada_value_primitive_packed_val, because the "parent" was
left as NULL. So, when we try to dereference it to get the parent address,
GDB crashed.
The first part of the fix therefore consists in setting that field.
This required the addition of a new "setter" in value.[hc]. It fixes
the crash, but is still not sufficient for the assignment to actually
work.
The second part of the problem came from the fact that value_assign
seems to expect the "child"'s address to be equal to the parent's address,
with the difference being the offset. Unfortunately, this requirement was
not followed by ada_value_primitive_packed_val, so the second part of
the fix consisted in fixing that.
Still, this was not sufficient, because it caused a regression when
trying to perform an aggregate assignment of a packed array of packed
record. The key element here is the nesting of packed entities.
Looking at the way ada_value_primitive_packed_val creates the value
of each sub-component, one can see that the value's offset is set
to the offset compared to the start of the parent. This was meant to
match what value_primitive_field does as well.
So, with our array of records, if the record offset was 2, and if
the field we're interested in that record is at offset 1, the record
value's offset would be set to 2, and the field value's offset would
be set to 1. But the address for both values would be left to the
array's address. This is where things start breaking down, because
the value_address function for our field value would return the
address of the array + 1, instead of + 3.
This is what causes the final issue, here, because ada-lang.c's
value_assign_to_component needs to compute the offset of the
subcomponent compared to the top-level aggregate's start address
(the array in our case). And it does so by subtracting the array's
address from the sub-component's address. When you have two levels
of packed components, and the mid-level component is at an offset of
the top-level component, things didn't work, because the component's
address was miscomputed (the parent's offset is missing).
The fix consists is fixing value_address to match the work done by
value_primitive_field (where we ignore the parent's offset).
gdb/ChangeLog:
* value.h (set_value_parent): Add declaration.
* value.c (set_value_parent): New function.
(value_address): If VALUE->PARENT is not NULL, then use it as
the base address instead of VALUE->LOCATION.address.
* ada-lang.c (ada_value_primitive_packed_val): Keep V's address
the same as OBJ's address. Adjust V's offset accordingly.
Set V's parent.
gdb/testsuite/ChangeLog:
* gdb.ada/set_pckd_arr_elt: New testcase.
Consider the following function...
3 procedure Foo is
4 I : Integer := Ident (10);
5 Obj : Base;
6 begin
7 Obj.X := I;
8 Do_Nothing (Obj.X'Address);
9 end Foo;
... where type "Base" is defined as a plain tagged record. If the user
stops execution before "Obj" gets initialized (for example, by inserting
a breakpoint "on" the function - or in other words, by inserting a
breakpoint using the function name as the location), one might get
the following of output if you try printing the value of obj:
(gdb) p obj
object size is larger than varsize-limit
object size is larger than varsize-limit
object size is larger than varsize-limit
$1 = object size is larger than varsize-limit
(x => 4204154)
Same thing with "info locals":
(gdb) info locals
i = 0
obj = object size is larger than varsize-limit
(x => 4204154)
We have also seen different error messages such as "Cannot read
memory at 0x...".
The error happens because we are trying to read the dispatch table
of a tagged type variable before it gets initialized. So the errors
might legitimately occur, and are supposed to be be contained.
However, the way things are written in ada-lang.c:ada_tag_name,
although the exception is in fact contained, the error message still
gets to be printed out.
This patch prevents this from happening by eliminating the use of
catch_errors, and using a TRY_CATCH block instead. Doing this removed
the need to use functions specifically fitted for catch_errors, and
thus some other simplifications could me made. In the end, the code
got reorganized a bit to better show the logic behind it, as well as
the common patterns.
gdb/ChangeLog:
* ada-lang.c (struct tag_args): Delete.
(ada_get_tsd_type): Function body moved up in source file.
(ada_tag_name_1, ada_tag_name_2): Delete.
(ada_get_tsd_from_tag): New function.
(ada_tag_name_from_tsd): New function.
(ada_tag_name): Use a TRY_CATCH block instead of catch_errors
to determine the tag name.
gdb/testsuite/ChangeLog:
* gdb.ada/tagged_not_init: New testcase.
Consider the following declarations (a packed array indexed by an
enumerated type):
type Color is (Black, Red, Green, Blue, White);
type Full_Table is array (Color) of Boolean;
pragma Pack (Full_Table);
Full : Full_Table := (False, True, False, True, False);
GDB is unable to print the index values correctly. It prints the
enumeration's underlying value instead of the enumeration name:
(gdb) p full
$1 = (0 => false, true, false, true, false)
(gdb) p full'first
$2 = 0
And yet, it is capable of printing the correct type description:
(gdb) ptype full
type = array (black .. white) of boolean <packed: 1-bit elements>
To get to the real index type, one has to follow the parallel XA type.
We already do this for normal arrays. We can do it for this packed
array as well.
gdb/ChangeLog:
* ada-lang.c (constrained_packed_array_type): If there is a
parallel XA type, use it to determine the array index type.
gdb/testsuite/ChangeLog:
* gdb.ada/arrayidx.exp: Adjust expected output for p_one_two_three.
* gdb.ada/enum_idx_packed: New testcase.
This patch is to help handle aliased array variables, such as:
type Bounded is array (Integer range <>) of Integer;
function New_Bounded (Low, High : Integer) return Bounded;
BT : aliased Bounded := New_Bounded (Low => 1, High => 3);
In that case, the compiler describes variable "BT" as a reference
to a thin pointer, and GDB is unable to print its value:
(gdb) p bt
$1 =
The problems starts when ada_value_print deconstructs the struct
value into contents and address in order to call val_print. It
turns out in this case that "bt" is not an lval. In the debug
information, this variable's location is described as:
.uleb128 0xd # (DIE (0xe0) DW_TAG_variable)
.ascii "bt\0" # DW_AT_name
[...]
.byte 0x6 # DW_AT_location
.byte 0x91 # DW_OP_fbreg
.sleb128 -56
.byte 0x6 # DW_OP_deref
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x8
.byte 0x9f # DW_OP_stack_value
So, when ada_value_print passes the bt's (value) address, it passes
in effect a meaningless address. The problem continues shortly after
when ada_val_print_1 re-creates the value from the contents and address.
The value has become an lval_memory, with a null address.
As a result, we trigger a memory error later on, while trying to
read the array bounds in order to transform our value into a simple
array.
To avoid the problem entirely, the fix is to coerce references before
transforming array descriptors into simple arrays.
gdb/ChangeLog:
* ada-valprint.c (ada_val_print_1): If our value is a reference
to an array descriptor, dereference it before converting it
to a simple array.
gdb/testsuite/ChangeLog:
* gdb.ada/aliased_array: New testcase.
Consider the following declaration:
type Full_Table is array (Color) of Integer;
Full : Full_Table := (144, 233, 377, 610, 987);
The debugger correctly prints the type name of variable "full":
(gdb) whatis full
type = pck.full_table
But is unable to do so when using the value history:
(gdb) print full
$1 = (144, 233, 377, 610, 987)
(gdb) whatis $
!!! -> type = array (black .. white) of integer
This is because the evaluation creates a "fixed" version of
the array type, and that "fixed" version is missing a type name.
As a result, whatis falls back to describing the type (a la ptype)
instead of printing the type name.
gdb/ChangeLog:
* ada-lang.c (to_fixed_array_type): Set result's type name.
gdb/testsuite/ChangeLog:
* gdb.ada/whatis_array_val: New testcase.
In GDB/MI mode, trying to print the arguments of the frame corresponding
to the body of a task ("-stack-list-arguments 1") causes the debugger to
crash.
This is because the compiler adds an implicit argument to that task body
called "_task". mi/mi-cmd-stack.c:list_args_or_locals, which is
responsible for printing the value of our arguments, finds that our
"_task" symbol is an argument, and thus tries to fing the non-argument
equivalent:
if (SYMBOL_IS_ARGUMENT (sym))
sym2 = lookup_symbol (SYMBOL_NATURAL_NAME (sym),
block, VAR_DOMAIN,
(int *) NULL);
Unfortunately, it tries using the natural name, which doesn't always
work for Ada parameters, in particular those who are internally-
generated. In our case, The "_task" parameter's natural name is
"<_task>", and that symbol does not exist. So sym2 is NULL, thus
causing the crash a little later on when trying to dereference it.
We should be using the symbol linkage name in this case, the same
way iterate_over_block_arg_vars already does.
gdb/ChangeLog:
* mi/mi-cmd-stack.c (list_args_or_locals): For argument symbols,
use SYMBOL_LINKAGE_NAME to find the corresponding non-argument
symbol. Add assertion that sym2 is never NULL.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_task_arg: New testcase.
Consider the following declaration:
package Pck is
task Dummy_Task is
entry Start;
end Dummy_Task;
end Pck;
Inserting a breakpoint on the body of that task does not currently
work:
(gdb) b pck.dummy_task
"pck.dummy_task" is not a function
Make breakpoint pending on future shared library load? (y or [n]) n
What happens here is that the compiler generates two symbols:
(a) Symbol `pck__dummy_task' which is a *variable* referencing
the task;
(b) Symbol `pck__dummy_taskTKB' which is the subprogram implementing
the body of the task.
The symbol lookup only finds the variable before of the TKB suffix in
the subprogram name. This patch fixes the problem by adjusting the
ada-lang.c:is_name_suffix routine to recognize "TKB" suffixes. But
that's not enough, because the search in the symtab is performed via
the block dictionary, using a hashing algorithm. So, for the search
to find `pck__dummy_taskTKB', I had to modify the hashing function
to ignore TKB suffixes as well.
gdb/ChangeLog:
* ada-lang.c (is_name_suffix): Add handling of "TKB" suffixes.
Update function documentation.
* dictionary.c (dict_hash): Ignore "TKB" suffixes in hash
computation.
gdb/testsuite/ChangeLog:
* gdb.ada/task_bp: New testcase.
This patch should help the user understand why the debugger is not
able to insert Ada exception catchpoints when the Ada runtime was
stripped of debugging info, as is often the case on many GNU/Linux
distros:
(gdb) catch exception
Your Ada runtime appears to be missing some debugging information.
Cannot insert Ada exception catchpoint in this configuration.
gdb/ChangeLog:
* ada-lang.c (ada_has_this_exception_support): Raise an error
if we could find the Ada exception hook in the Ada runtime,
but no debugging info for that hook.
gdb/testsuite/ChangeLog:
* gdb.ada/catch_ex.exp, gdb.ada/mi_catch_ex.exp: Adjust
expected output for unsupported case.
* gdb.ada/catch_ex.exp: Skip as unsupported if "catch exception"
throws "Cannot insert catchpoints in this configuration".
* gdb.ada/mi_catch_ex.exp: Likewise.
The testcase is assuming that the parameter being watched isn't being
modified. But the way the test program is written, this is not true
at all. So this changes fixes the code to still reference the variable,
but in a way that does not modify its value.
gdb/testsuite:
* gdb.ada/watch_arg/pck.ads, gdb.ada/watch_arg/pck.adb: New files.
* gdb.ada/watch_arg/watch.adb: Adjust code to avoid modification
of parameter X in procedure Foo.
Otherwise, the compiler does not generate any debug info for them.
This fixes 3 FAILs:
FAIL: gdb.ada/homonym.exp: ptype local_type_subtype at BREAK_1
FAIL: gdb.ada/homonym.exp: ptype int_type at BREAK_1
FAIL: gdb.ada/homonym.exp: ptype local_type_subtype at BREAK_2
gdb/testsuite/ChangeLog:
* gdb.ada/homonym/pck.ads, gdb.ada/homonym/pck.adb: New files.
* gdb.ada/homonym/homonym.adb: For use of all types defined
locally inside both Get_Value subprograms.
The ada-lang.c:compare_names function returns the wrong value
when the first string starts with the same contents as the second
string, followed by '_' and then some characters that do not make
a symbol name suffix. For instance:
string1 = "generics__test_generics__instance__print"
string2 = "generics__test_generics"
In that case, compare_names (string1, string2) return -1, when
clearly, string1 is greater than string2.
A consequence of this problem is that GDB may fail to lookup
"generics.test_generics" from our partial symtabs, because
partial symbols are ordered by strcmp_iw_ordered:
(gdb) b generics.test_generics
Function "generics.test_generics" not defined.
Make breakpoint pending on future shared library load? (y or [n])
gdb/ChangeLog:
* ada-lang.c (compare_names): Fix wrong return value in case
string1 starts with the same contents as string2, followed
by an underscore that do not start a symbol name suffix.
gdb/testsuite/ChangeLog:
* gdb.ada/fullname_bp: New testcase.
The read_frame_register_value function as it was implemented introduced
a regression on big-endian targets. The problem appears when trying to
get the value of an entity stored inside a register, and when the size
of the entity is smaller than the size of the register. In that case,
we were always reading the first N bytes of the register, which is wrong
for big-endian architectures, where we need to read the last N bytes of
the register.
gdb/ChangeLog:
* findvar.c (read_frame_register_value): Read correct bytes from
register on big-endian architectures.
gdb/testsuite/ChangeLog:
* gdb.ada/small_reg_param: New testcase.
When using the new -ada-task-info command with an argument,
the output would say that there are N entries in the returned
table, (where N is the total number of tasks present in the inferior).
But, in fact, the table would only contain at most 1 entry.
This patch fixes this by properly computing the number of
tasks being displayed before giving it to the uiout.
gdb/ChangeLog:
* ada-tasks.c (print_ada_task_info): Fix computation of
number of tasks displayed in command output.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_task_info/task_switch.adb: New file.
* gdb.ada/mi_task_info.exp: New file.
This is in preparation for providing a GDB/MI equivalent of
the `info tasks' command. The previous implementation was using
various printf commands to generate the command output, which
does not work at all if we want to use that same code to generate
the result for that new GDB/MI command.
This patch thus re-implements the `info tasks' command (with no
arguments) in a way that makes it GDB/MI friendly.
There is an additional hicup, which is the fact that the `info tasks'
command displays a completely different type of output when a task
ID is given. For instance:
(gdb) info task 2
Ada Task: 0x644d20
Name: my_callee
Thread: 0
LWP: 0x5809
Parent: 1 (main_task)
Base Priority: 48
State: Blocked in accept or select with terminate
The above output is better when in CLI mode, but really not
what we want when in GDB/MI mode. In GDB/MI mode, we want to
follow what the `-thread-info' command does when a task-id
is given as an argument, which is to produce the same table,
but with only one element/task in it.
For compatibility as well as practical reasons, we do not want
to change the output of the `info task TASKNO' command when in
CLI mode. But it's easy to preserve this behavior while providing
the desirable output when in GDB/MI mode. For this, the function
used to generated the `info tasks' output has been enhanced to take
an argument interpreted as a string. The CLI command knows to never
provide that argument, while the GDB/MI command will pass one if
provided by the user.
gdb/ChangeLog:
* ada-tasks.c (print_ada_task_info): New function, merging
short_task_info and info_tasks together. Reimplement using
ui-out instead of printing to stdout directly. Move the code
building and checking the task list here, instead of leaving it
in info_tasks_command.
(info_task): Move the code building and checking the task
list here, instead of leaving it in info_tasks_command.
(info_tasks_command): Delete code building and checking
the task list - moved elsewhere. Update calls to info_tasks
and info_task.
One of the minor changes the switch caused is the introduction
of a space between the "current" column, and the task "ID"
column, which wasn't there before. This matches what we do
in the "info threads" command, so I kept that change. This
required an adjustment in the testsuite, however...
gdb/testsuite/ChangeLog:
* gdb.ada/tasks.exp: Make the expected output for
the `info tasks' tests more resilient to spacing
changes.
Temporary catchpoints on Ada exceptions are now displayed as "Temporary
catchpoint" as opposed to just "Catchpoint". This is cosmetic only, but
in line with what's done for other catchpoints as well as breakpoints.
gdb/ChangeLog:
* ada-lang.c (print_it_exception): Print temporary catchpoints
as "Temporary catchpoint".
(print_mention_exception): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/catch_ex.exp: Add temporary catchpoint tests.
When trying to print the address of a non-packed array, GDB
correctly prints the type name and address:
(gdb) print &var
$2 = (access pa.var) 0xbffff1d8
However, it is behaving differently when dealing with a packed
array:
(gdb) p &var
(access array (4 .. 8) of boolean <packed: 1-bit elements>) (4 =>
false, false, false, true, false)
The type description isn't all that bad, but GDB shouldn't be
printing the array value!
This patch fixes the `print` and `ptype` command on packed and
non-packed array. It also fixes a gdb.ada test to match with
the new ouput.
gdb/ChangeLog (Jean-Charles Delay):
* ada-typeprint.c (ada_print_type): Fix both PAD type and
pointer to constrained packed array type output.
* ada-valprint.c (ada_val_print_1): Fix pointer to constrained
packed array output.
gdb/testsuite/ChangeLog (Jean-Charles Delay):
* gdb.ada/packed_array.exp: Fix expected outout.
Array bounds were not correctly displayed when the SHOW parameter of
print_type functions is set to -1. This shows up in the following
type of situation, where we have a declaration as follow:
Anon_Array_Int_Obj : array (1..10) of Integer := (others => 8);
In GDB/MI mode, trying to print the type info for our array object
yields:
(gdb) -var-create ai 0 Anon_Array_Int_Obj
(gdb) -var-info-type ai
^done,type="array (...) of integer"
The actual bounds are missing. Contrast this with what happens
when in GDB/CLI mode:
(gdb) ptype Anon_Array_Int_Obj
type = array (1 .. 10) of integer
This patch fixes array type printing accordingly. And as it turns
out, it also improves the output for one of the tests already present,
so it shows that it's not just the GDB/MI mode that's affected.
gdb/ChangeLog (Jean-Charles Delay):
* ada-typeprint.c (print_array_type): removed if condition on show
being negative for bounds printing.
gdb/testsuite/ChangeLog (Jean-Charles Delay):
* gdb.ada/packed_array.exp: fixed expected output.
This is to avoid an unnecessary multiple-choice menu for an
expression involving an enumeral declared in two types, when
the second type is an identical copy of the first type. This
happens in the following situation:
type Color is (Black, Red, Green, Blue, White);
type RGB_Color is new Color range Red .. Blue;
In that case, an implict type is created, and is used as the base
type for type RGB_Color. This base type is a copy of type Color.
We've added some extensive comments explaining the situation and
our approach further.
gdb/ChangeLog:
* ada-lang.c (ada_identical_enum_types_p): New function.
(symbols_are_identical_enums): New function.
(remove_extra_symbols): Do nothing if NSYMS < 2.
Use symbols_are_identical_enums.
gdb/testsuite/ChangeLog:
* gdb.ada/same_enum: New testcase.
If we evaluate an expression that results in a value that is a typedef
to pointer, then the debugger fails to print the type description
before printing the actual value:
(gdb) print e.plan(1)
$1 = 0x0
The expected output is:
(gdb) print e.plan(1)
$1 = (access integer) 0x0
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Handle typedefs.
gdb/testsuite/ChangeLog:
* gdb.ada/ptr_typedef: New testcase.
If we declare a type as being an access to array type, and then
declare a variable of that type, for instance:
type Some_Array is array [...];
type Array_Access is access all Some_Array;
Table : Array_Access := [...];
The variable "Table" may be defined in the debugging information
as being a typedef to the array pointer type. In the past, it was
defined directly as the array pointer type, but this has been changed
to make sure that the typedef type gets used.
If the typedef type wasn't used, it would allow the compiler to stop
emitting that typedef type when compiling with
-feliminate-unused-debug-types. The removal of this typedef would
be a problem, because GDB relies on the typedef to create symbols
for pointer types, and without it, we would no longer be able to
do "ptype array_access".
This patch helps prevent incorrect output or even crashes when that
extra typedef layer is used.
The testing is already mostly covered by arrayptr.exp, but I still
added a 'ptype' test, just for good measure.
gdb/ChangeLog: (Eric Botcazou)
* ada-lang.c (thin_descriptor_type): Deal with typedefs.
(decode_constrained_packed_array): Likewise.
(ada_evaluate_subexp) <TERNOP_SLICE>: Likewise.
gdb/testsuite/ChangeLog (Joel Brobecker):
* gdb.ada/arrayptr.exp: Add ptype test.
Consider the following type:
type Char_Enum_Type is ('A', 'B', 'C', 'D');
If the compiler generates a Char_Enum_Type typedef in the debugging
information, the debugger fails in the following case:
(gdb) p Char_Enum_Type'('B')
$1 = 66
For our type, the underlying value of 'B' is actually 1, not 66
(ASCII 'B'). We are failing this case because we were not handling
typedef to enum types before. This patch fixes this.
gdb/ChangeLog:
* ada-exp.y (convert_char_literal): Handle typedef types.
gdb/testsuite/ChangeLog:
* gdb.ada/char_enum: New testcase.
