The current approach when building Ada programs for testing is
based on the use of a project file (testsuite/gdb.ada/gnat_ada.gpr).
To do that, we pass a number of additional arguments to target_compile,
one of them being the project file (via "-P/path/to/gnat_ada.gpr").
This used to work well-enough, but AdaCore is currently working towards
removing project-file support from gnatmake (the prefered tool for
using project files is gprbuild). So, we need to either switch
the compilation to gprbuild, or stop using project files.
First, using gprbuild is not always what users will be using to
build their applications. So having the option of using gnatmake
provides more flexibility towards exactly reproducing past bugs.
If we ever need a testcase that requires the use of gprbuild, then
I believe support for a new target needs to be added to dejagnu's
target_compile.
Also, the only real reason behind using a project file in the first
place is that we wanted to make it easy to specify the directory
where all compilation artifacts get stored. This is a consequence
of the organization choice we made for gdb.ada to keep each testcase
well organized. It is very easy to achieve that goal without using
project files.
This is therefore what this patch does: It change gdb_compile_ada
to build any program using gnatmake without using a project file
(by temporarily changing the current working directory).
There is a small (beneficial) side-effect; in the situation where
GDB is built in-tree, gnatmake is called as...
% gnatmake [...] unit.adb
... which means that the debugging info in unit.o will say contain
a filename whose name is 'unit.adb', rather than '/path/to/unit.adb'.
This also better matches what users might typically do. But the side-
effect is that the unit name in the GDB output is not always a full
path. This patch tweaks a couple of testcases to make the path part
optional.
gdb/testsuite:
* lib/ada.exp (target_compile_ada_from_dir): New function.
(gdb_compile_ada): Reimplement avoiding the use of project files.
* gdb.ada/gnat_ada.gpr: Delete.
* gdb.ada/cond_lang.exp: Adjust test to make path before
filename optional.
* gdb.ada/small_reg_param.exp: Likewise.
Tested on x86_64-linux, with both in-tree and out-of-tree builds.
So far, trying to evaluate an expression involving a function call for
which GDB could find multiple function candidates outputs a menu so that
the user can select the one to run. For instance, with the two
following functions:
type New_Integer is new Integer;
function F (I : Integer) return Boolean;
function F (I : New_Integer) return Boolean;
Then we get the following GDB session:
(gdb) print f(1)
Multiple matches for f
[0] cancel
[1] foo.f at foo.adb:23
[2] foo.f at foo.adb.28
>
While the source location information is sufficient in order to
determine which one to select, one has to look for them in source files,
which is not convenient.
This commit tunes this menu in order to also include the list of formal
and return types (if any) in each entry. The above then becomes:
(gdb) print f(1)
Multiple matches for f
[0] cancel
[1] foo.f (integer) return boolean at foo.adb:23
[2] foo.f (foo.new_integer) return boolean at foo.adb.28
>
Since this output is more verbose than previously, this change also
introduces an option (set/show ada print-signatures) to get the original
output.
gdb/ChangeLog:
* ada-lang.c (print_signatures): New.
(ada_print_symbol_signature): New.
(user_select_syms): Add signatures to the output of candidate
symbols using ada_print_symbol_signature.
(_initialize_ada_language): Add a "set/show ada
print-signatures" boolean option.
gdb/testsuite/ChangeLog:
* gdb.ada/fun_overload_menu.exp: New testcase.
* gdb.ada/fun_overload_menu/foo.adb: New testcase.
Tested on x86_64-linux, no regression.
Using the gdb.ada/var_rec_arr.exp test, where the program declares
an array of variant records...
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
... and then a variable A1 of type Array_Type, the following command
ocassionally trigger an internal error trying to allocate more memory
than we have left:
(gdb) ptype a1(1)
[...]/utils.c:1089: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
[...]
What happens is that recent versions of GNAT are able to generate
DWARF expressions for type Record_Type, and therefore the record's
DW_AT_byte_size is not a constant, which unfortunately breaks
an assumption made by dwarf2read.c:read_structure_type when it does:
attr = dwarf2_attr (die, DW_AT_byte_size, cu);
if (attr)
{
TYPE_LENGTH (type) = DW_UNSND (attr);
}
As a result of this, when ada_evaluate_subexp tries to create
a value_zero for a1(1) while processing the OP_FUNCALL operator
as part of evaluating the subscripting operation in no-side-effect
mode, we try to allocate a value with a bogus size, potentially
triggering the out-of-memory internal error.
This patch avoids this issue by setting the length to zero in
this case. Until we decide to start supporting dynamic type
lengths in GDB's type struct, and it's not clear yet that
this is worth the effort (see added comment), that's probably
the best we can do.
gdb/ChangeLog:
* dwarf2read.c (read_structure_type): Set the type's length
to zero if it has a DW_AT_byte_size attribute which is not
a constant.
gdb/testsuite/ChangeLog:
* testsuite/gdb.ada/var_rec_arr.exp: Add "ptype a1(1)" test.
Consider a function with the following signature...
function F (R : out Rec_Type) return Enum_Type;
... where Rec_Type is a simple record:
type Rec_Type is record
Cur : Integer;
end record;
Trying to "finish" from that function causes GDB to SEGV:
(gdb) fin
Run till exit from #0 bar.f (r=...) at bar.adb:5
0x00000000004022fe in foo () at foo.adb:5
5 I : Enum_Type := F (R);
[1] 18949 segmentation fault (core dumped) /[..]/gdb
This is related to the fact that funtion F has a parameter (R)
which is an "out" parameter being passed by copy. For those,
GNAT transforms the return value to be a record with multiple
fields: The first one is called "RETVAL" and contains the return
value shown in the source, and the remaining fields have the same
name as the "out" or "in out" parameters which are passed by copy.
So, in the example above, function F returns a struct that has
one field who name is "r".
Because "RETVAL" starts with "R", GDB thinks it's a wrapper field,
because it looks like the encoding used for variant records:
-- member_name ::= {choice} | others_choice
-- choice ::= simple_choice | range_choice
-- simple_choice ::= S number
-- range_choice ::= R number T number <<<<<----- here
-- number ::= {decimal_digit} [m]
-- others_choice ::= O (upper case letter O)
See ada_is_wrapper_field:
return (name != NULL
&& (startswith (name, "PARENT")
|| strcmp (name, "REP") == 0
|| startswith (name, "_parent")
|| name[0] == 'S' || name[0] == 'R' || name[0] == 'O'));
As a result of this, when trying to print the RETURN value,
we think that RETVAL is a wrapper, and thus recurse into
print_field_values...
if (ada_is_wrapper_field (type, i))
{
comma_needed =
print_field_values (TYPE_FIELD_TYPE (type, i),
valaddr,
(offset
+ TYPE_FIELD_BITPOS (type, i) / HOST_CHAR_BIT),
stream, recurse, val, options,
comma_needed, type, offset, language);
... which is a problem since print_field_values assumes that
the type it is given ("TYPE_FIELD_TYPE (type, i)" here), is also
a record type. However, that's not the case, since RETVAL is
an enum. That eventually leads GDB to a NULL type when trying to
extract fields out of the enum, which then leads to a SEGV when
trying to dereference it.
Ideally, we'd want to be a little more careful in identifying
wrapper fields, by enhancing ada_is_wrapper_field to be a little
more complete in its analysis of the field name before declaring
it a variant record wrapper. However, it's not super easy to do
so, considering that the choices can be combined together when
complex choices are used. Eg:
-- [...] the choice 1 .. 4 | 7 | -10 would be represented by
-- R1T4S7S10m
Given that we are working towards getting rid of GNAT encodings,
which means that the above will eventually disappear, we took
the more pragmatic approach is just treating RETVAL as a special
case.
gdb/ChangeLog:
* ada-lang.c (ada_is_wrapper_field): Add special handling
for fields called "RETVAL".
gdb/testsuite/ChangeLog:
* gdb.ada/fin_fun_out: New testcase.
Running ./gdb.ada/access_to_packed_array.exp ...
ERROR: tcl error sourcing ./gdb.ada/access_to_packed_array.exp.
ERROR: extra characters after close-quote
while executing
"gdb_test "print pack.a" "\\(0 => 1, 2, 3, 4, 5, 6, 7, 8, 9, 10\\)")"
(file "./gdb.ada/access_to_packed_array.exp" line 29)
invoked from within
"source ./gdb.ada/access_to_packed_array.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source ./gdb.ada/access_to_packed_array.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Unrelated to the typos I have changed the print expectations s/"x"/" = x"/
as for example expectation "3" should not match " = 43".
2015-10-27 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.ada/access_to_packed_array.exp: Fix typos erroring the testfile.
Compilers can materialize renamings of arrays (or of accesses to arrays)
in Ada into variables whose types are references to the actual array
types. Before this change, trying to use such an array renaming yielded
an error in GDB:
(gdb) print my_array(1)
cannot subscript or call a record
(gdb) print my_array_ptr(1)
cannot subscript or call something of type `(null)'
This behavior comes from bad handling for array renamings, in particular
the OP_FUNCALL expression operator handling from ada-lang.c
(ada_evaluate_subexp): in one place we turn the reference into a
pointer, but the code that follows expect the value to be an array.
This patch fixes how we handle references in call/subscript evaluation
so that we turn these references into the actual array values instead of
pointers to them.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <OP_FUNCALL>: When the input
value is a reference, actually dereference it in order to get
the underlying value.
gdb/testsuite/ChangeLog:
* gdb.ada/array_ptr_renaming.exp: New testcase.
* gdb.ada/array_ptr_renaming/foo.adb: New file.
* gdb.ada/array_ptr_renaming/pack.ads: New file.
Tested on x86_64-linux, no regression.
This change is relevant only for standard DWARF (as opposed to the GNAT
encodings extensions): at the time of writing it only makes a difference
with GCC patches that are to be integrated: see the patch series
submission at
<https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01353.html>.
Given the following Ada declarations:
subtype Small_Int is Natural range 0 .. 100;
type R_Type (L : Small_Int := 0) is record
S : String (1 .. L);
end record;
type A_Type is array (Natural range <>) of R_Type;
A : A_Type := (1 => (L => 0, S => ""),
2 => (L => 2, S => "ab"));
Before this change, we would get the following GDB session:
(gdb) ptype a
type = array (1 .. 2) of foo.r_type <packed: 838-bit elements>
This is wrong: "a" is not a packed array. This output comes from the
fact that, because R_Type has a dynamic size (with a maximum), the
compiler has to describe in the debugging information the size allocated
for each array element (i.e. the stride, in DWARF parlance: see
DW_AT_byte_stride). Ada type printing currently assumes that arrays
with a stride are packed, hence the above output.
In practice, GNAT never performs bit-packing for arrays that contain
variable-sized elements. Leveraging this fact, this patch enhances type
printing so that ptype does not pretend that arrays are packed when they
have a stride and they contain dynamic elements. After this change, we
get the following expected output:
(gdb) ptype a
type = array (1 .. 2) of foo.r_type
gdb/ChangeLog:
* ada-typeprint.c (print_array_type): Do not describe arrays as
packed when they embed dynamic elements.
gdb/testsuite/ChangeLog:
* gdb.ada/array_of_variable_length.exp: New testcase.
* gdb.ada/array_of_variable_length/foo.adb: New file.
* gdb.ada/array_of_variable_length/pck.adb: New file.
* gdb.ada/array_of_variable_length/pck.ads: New file.
Tested on x86_64-linux, no regression.
This change is relevant only for standard DWARF (as opposed to the GNAT
encodings extensions): at the time of writing it only makes a difference
with GCC patches that are to be integrated: see in particular
<https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01364.html>.
Given the following Ada declarations:
type Small is mod 2 ** 6;
type Array_Type is array (0 .. 9) of Small
with Pack;
type Array_Access is access all Array_Type;
A : aliased Array_Type := (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
AA : constant Array_Type := A'Access;
Before this change, we would get the following GDB session:
(gdb) print aa.all(2)
$1 = 3
(gdb) print aa(2)
$2 = 16
This is wrong: both expression should yield the same value: 3. The
problem is simply that the routine which handles accesses to arrays lack
general handling for packed arrays. After this patch, we have the
expected output:
(gdb) print aa.all(2)
$1 = 3
(gdb) print aa(2)
$2 = 3
gdb/ChangeLog:
* ada-lang.c (ada_value_ptr_subscript): Update the heading
comment. Handle packed arrays.
gdb/testsuite/ChangeLog:
* gdb.ada/access_to_packed_array.exp: New testcase.
* gdb.ada/access_to_packed_array/foo.adb: New file.
* gdb.ada/access_to_packed_array/pack.adb: New file.
* gdb.ada/access_to_packed_array/pack.ads: New file.
Tested on x86_64-linux, no regression.
Before this change, trying to call an overloaded function with at least
one character literal in argument would fail. For instance, given these
two functions:
function F (C : Character) return Integer is
begin
return Character'Pos (C);
end F;
function F (I : Integer) return Integer is
begin
return -I;
end F;
We would get the following GDB session:
(gdb) p f('A')
$1 = -65
(gdb) p f(1)
$1 = -1
This is wrong because the first call should select the first F function
and thus return 65.
The root problem is that ada-lang.c:ada_language_arch_info stores in
string_char_type a type whose code is TYPE_CODE_INT instead of
TYPE_CODE_CHAR. As a result, all parsed character literals are turned
into integer values and during overload matching, the TYPE_CODE_CHAR
formal rejects the TYPE_CODE_INT actual.
This change turns string_char_type into a true TYPE_CODE_CHAR type in
ada-lang.c so that we have instead the expected:
(gdb) p f('A')
$1 = 65
gdb/ChangeLog:
* ada-lang.c (ada_language_arch_info): Create a TYPE_CODE_CHAR
type instead of a TYPE_CODE_INT one for the string_char_type
and the ada_primitive_type_char types.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_char.exp: New testcase.
* gdb.ada/funcall_char/foo.adb: New file.
Tested on x86_64-linux, no regression.
Before this change, trying to complete an expression ending with an
ambiguous function name (i.e. for which there are multiple matches)
would display a menu with a prompt for the user to pick one. For
instance:
(gdb) p func<tab>Multiple matches for func
[0] cancel
[1] pack2.func at pack2.adb:5
[2] pack.func at pack.adb:5
>
This is not user friendly and actually triggered a segmentation fault
after the user did pick one. It is not clear whether the segmentation
fault needs a separate fix, but this is the only known case which
exhibits it at the moment, and this case must be fixed itself.
The problem lies in ada-lang.c (ada_resolve_function): when we got
multiple matches, we should not display the menu if we are in completion
mode. This patch adjusts the corresponding condition accordingly.
gdb/ChangeLog:
* ada-lang.c (ada_resolve_function): Do not ask the user what
match to use when in completion mode.
gdb/testsuite/ChangeLog:
* gdb.ada/complete.exp: Add "pck.ambiguous_func" to the relevant
expected outputs. Add two testcases for completing ambiguous
functions.
* gdb.ada/complete/aux_pck.adb: New file.
* gdb.ada/complete/aux_pck.ads: New file.
* gdb.ada/complete/foo.adb: Pull Aux_Pck and call the two
Ambiguous_Func functions.
* gdb.ada/complete/pck.ads: Add an Ambiguous_Func function.
* gdb.ada/complete/pck.adb: Likewise.
Tested on x86_64-linux, no regression.
Before this change, trying to evaluate the following Ada expression
yielded a syntax error, even though it's completely legal:
(gdb) p s'first = 'a'
Error in expression, near `'.
The problem lies in the lexer (gdb/ada-lex.l): at the point we reach "'a'",
we're still in the BEFORE_QUAL_QUOTE start condition (the mechanism to
distinguish character literals from other "tick" usages: qualified
expressions and attributes), so we consider that this quote is actually a
separate "tick".
This changes resets the start condition to INITIAL in the
{TICK}[a-zA-Z][a-zA-Z]+ rule (for attributes): attributes activate this
BEFORE_QUAL_QUOTE condition and in this case the above rule is always
executed rather than the <BEFORE_QUAL_QUOTE>"'" one (in flex, it's
always the longest match that is chosen). We now have instead:
(gdb) p s'first = 'a'
$1 = true
gdb/ChangeLog:
* ada-lex.l: Reset the start condition to INITIAL in the rule
that matches attributes.
gdb/testsuite/ChangeLog:
* gdb.ada/attr_ref_and_charlit.exp: New testcase.
* gdb.ada/attr_ref_and_charlit/foo.adb: New file.
Tested on x86_64-linux, no regression.
Consider the following declaration:
function Foo (I : Integer) return Integer renames Pack.Bar;
As Foo is not materialized as a routine whose name is derived from Foo,
GDB currently cannot use it:
(gdb) print foo(0)
No definition of "foo" in current context.
However, compilers can emit DW_TAG_imported_declaration in order to
materialize the fact that Foo is actually another name for Pack.Bar.
This commit enhances the DWARF reader to record global renamings (it
used to put global ones in a static block) and enhances the Ada engine
to leverage this information during symbol lookup.
gdb/ChangeLog:
* ada-lang.c: Include namespace.h
(aux_add_nonlocal_symbols): Fix a function name in comment.
(ada_add_block_renamings): New.
(add_nonlocal_symbols): Add global renamings handling.
(ada_lookup_symbol_list_worker): Move the symbol lookup part
to...
(ada_add_all_symbols): ... this new function.
(ada_add_block_symbols): Try to match the input name against the
"using directives list", perform a recursive symbol lookup on
the matched declarations.
* block.h (struct block): Move the_namespace to top-level as
namespace_info. Remove the language_specific field.
(BLOCK_NAMESPACE): Update access to the namespace_info field.
* buildsym.h (using_directives): Rename into...
(local_using_directives): ... this.
(global_using_directives): New.
(struct context_stack): Rename the using_directives field into
local_using_directives.
* buildsym.c (finish_block_internal): Deal with the proper
using directives repository (local or global).
(prepare_for_building): Reset local_using_directives. Assert
that there is no pending global using directive.
(reset_symtab_globals): Reset global_using_directives and
local_using_directives.
(end_symtab_get_static_block): Don't ignore symtabs that have
only using directives.
(push_context): Update references to local_using_directives.
(buildsym_init): Do not reset using_directives.
* cp-support.c: Include namespace.h.
* cp-support.h (struct using_direct): Move to namespace.h.
(cp_add_using_directives): Move to namespace.h.
* cp-namespace.c: Include namespace.h
(cp_add_using_directive): Move to namespace.c, rename it to
add_using_directive, add a "using_directives" argument and use
it as the pending using directives repository. All callers
updated.
* dwarf2read.c (using_directives): New.
(read_import_statement): Call using_directives.
(read_func_scope): Update references to local_using_directives.
(read_lexical_block_scope): Likewise.
(read_namespace): Update the heading comment, call
using_directives.
* namespace.h: New file.
* namespace.c: New file.
* Makefile.in (SFILES): Add namespace.c.
(COMMON_OBS): Add namespace.o
gdb/testsuite/ChangeLog:
* gdb.ada/fun_renaming.exp: New testcase.
* gdb.ada/fun_renaming/fun_renaming.adb: New file.
* gdb.ada/fun_renaming/pack.adb: New file.
* gdb.ada/fun_renaming/pack.ads: New file.
Tested on x86_64-linux. Support for this in GCC is in the pipeline: see
<https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02166.html>.
When a dynamic array type contains a typedef-wrapped array, an assertion
failure occurs during type resolution. This is what happens in the
following Ada case:
type Rec_Type is record
I : Integer;
B : Boolean;
end record;
type Vec_Type is array (1 .. 4) of Rec_Type;
type Array_Type is array (Positive range <>) of Vec_Type;
If users try to print or even pass to an inferior call a variable A of
type Array_Type, GDB will raise an error:
(gdb) print a
../../src/gdb/gdbtypes.c:1807: internal-error:
resolve_dynamic_array: Assertion `TYPE_CODE (type) ==
TYPE_CODE_ARRAY' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
What happens is that during dynamic array type resolution, we first peel
TYPE_CODE_TYPEDEF layers wrapping the array element type and check if
its type is itself TYPE_CODE_ARRAY. If it is, we pass the
typedef-wrapped type to a recursive call to resolve_dynamic_array
whereas this function expects only TYPE_CODE_ARRAY types.
This patch makes it pass the peeled type to the recursive call so that
type resolution can continue smoothly.
gdb/ChangeLog:
* gdbtypes.c (resolve_dynamic_array): Pass the peeled element
type to the recursive call instead of the original (maybe
TYPE_CODE_TYPEDEF) type.
gdb/testsuite/ChangeLog:
* gdb.ada/var_arr_typedef.exp: New testcase.
* gdb.ada/var_arr_typedef/pack.adb: New file.
* gdb.ada/var_arr_typedef/pack.ads: New file.
* gdb.ada/var_arr_typedef/var_arr_typedef.adb: New file.
Since multi_line was moved to gdb.exp in a slightly stricter form,
The gdb.ada/info_exc.exp:info exceptions test has been failing.
This is because it now expects a new-line sequence at the end of
each argument given to multi_line, including ".*". But the intent
when writing the test was to signify "could-be-nothing-at-all".
As a result, the test fails on x86_64-linux with a runtime built as
recommended, because of that
extra new-line sequence.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc.exp: Adjust "info exceptions" expected output.
In the case of non bit-packed arrays, GNAT does not generate its
traditional XP encoding; it is not needed. However, it still generates
the so-called "implementation type" with a P suffix. This
implementation type shall be skipped when looking for other
descriptive types such as XA encodings for variable-length
fields.
Note also that there may be an intermediate typedef between the
implementation type and its XA description. It shall be skipped
as well.
gdb/ChangeLog:
Jerome Guitton <guitton@adacore.com>
* ada-lang.c (find_parallel_type_by_descriptive_type):
Go through typedefs during lookup.
(to_fixed_array_type): Add support for non-bit packed arrays
as variable-length fields.
gdb/testsuite/ChangeLog:
* gdb.ada/byte_packed_arr: New testcase.
Consider the following declarations:
type Signed_Small is new Integer range - (2 ** 5) .. (2 ** 5 - 1);
type Signed_Simple_Array is array (1 .. 4) of Signed_Small;
pragma Pack (Signed_Simple_Array);
SSA : Signed_Simple_Array := (-1, 2, -3, 4);
GDB currently print its value incorrectly for the elements that
are negative:
(gdb) print ssa
$1 = (65535, 2, 1048573, 4)
(gdb) print ssa(1)
$2 = 65535
(gdb) print ssa(2)
$3 = 2
(gdb) print ssa(3)
$4 = 1048573
(gdb) print ssa(4)
$5 = 4
What happens is that the sign-extension is not working because
we're trying to do left shift with a negative count. In
ada_value_primitive_packed_val, we have a loop which populates
the extra bits of the target (unpacked) value, after extraction
of the data from the original (packed) value:
while (ntarg > 0)
{
accum |= sign << accumSize;
unpacked[targ] = accum & ~(~0L << HOST_CHAR_BIT);
!!! -> accumSize -= HOST_CHAR_BIT;
accum >>= HOST_CHAR_BIT;
ntarg -= 1;
targ += delta;
}
At each iteration, accumSize gets decremented by HOST_CHAR_BIT,
which can easily cause it to become negative, particularly on
little endian targets, where accumSize is at most HOST_CHAR_BIT - 1.
This causes us to perform a left-shift operation with a negative
accumSize at the next loop iteration, which is undefined, and
acutally does not produce the effect we wanted (value left untouched)
when the code is compiled with GCC.
This patch fixes the issue by simply setting accumSize to zero
if negative.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_packed_val): Make sure
accumSize is never negative.
gdb/testsuite/ChangeLog:
* gdb.ada/pckd_neg: New testcase.
This patch improves the handling of out-of-line functions nested
inside functions that have been inlined.
Consider for instance a situation where function Foo_O224_021
has a function Child1 declared in it, which itself has a function
Child2 nested inside Child1. After compiling the program with
optimization on, Child1 gets inlined, but not Child2.
After inserting a breakpoint on Child2, and running the program
until reaching that breakpoint, we get the following backtrace:
% gdb foo_o224_021
(gdb) break foo_o224_021.child1.child2
(gdb) run
[...]
Breakpoint 1, foo_o224_021 () at foo_o224_021.adb:28
28 Child1;
(gdb) bt
#0 0x0000000000402400 in foo_o224_021 () at foo_o224_021.adb:28
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
GDB reports the wrong function name for frame #0. We also get the same
kind of error in the "Breakpoint 1, foo_o224_021 () [...]" message.
In both cases, the function name should be foo_o224_021.child1.child2,
and the parameters should be "s=...".
What happens is that the inlined frame handling does not handle well
the case where an inlined function is calling an out-of-line function
which was declared inside the inlined function's scope.
In particular, looking first at the inlined-frame sniffer when applying
to frame #0:
/* Calculate DEPTH, the number of inlined functions at this
location. */
depth = 0;
cur_block = frame_block;
while (BLOCK_SUPERBLOCK (cur_block))
{
if (block_inlined_p (cur_block))
depth++;
cur_block = BLOCK_SUPERBLOCK (cur_block);
}
What happens is that cur_block starts as the block associated
to child2, which is not inlined. We shoud be stopping here, but
instead, we keep walking the superblock chain, which takes us
all the way to Foo_O224_021's block, via Child2's block. And
since Child1 was inlined, we end up with a depth count of 1,
wrongly making GDB think that frame #0 is an inlined frame.
Same kind of issue inside skip_inline_frames.
The fix is to stop checking for inlined frames as soon as we see
a block corresponding to a function which is not inlined. This is
the behavior we now obtain:
(gdb) run
[...]
Breakpoint 1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:9
9 function Child2 (S : String) return Boolean is
(gdb) bt
#0 0x0000000000402400 in foo_o224_021.child1.child2 (s=...)
at foo_o224_021.adb:9
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
gdb/ChangeLog:
* inline-frame.c (inline_frame_sniffer, skip_inline_frames):
Stop counting inlined frames as soon as an out-of-line function
is found.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined.exp: Add run and "bt" tests.
Consider the following code, which defines a function, Child2,
which is itself nested inside Child1:
procedure Foo_O224_021 is
O1 : constant Object_Type := Get_Str ("Foo");
procedure Child1 is
O2 : constant Object_Type := Get_Str ("Foo");
function Child2 (S : String) return Boolean is -- STOP
begin
for C of S loop
Do_Nothing (C);
if C = 'o' then
return True;
end if;
end loop;
return False;
end Child2;
R : Boolean;
begin
R := Child2 ("Foo");
R := Child2 ("Bar");
R := Child2 ("Foobar");
end Child1;
begin
Child1;
end Foo_O224_021;
On x86_64-linux, when compiled at -O2, GDB is unable to insert
a breakpoint on Child2:
% gnatmake -g -O2 foo_o224_021
% gdb foo_o224_021
(gdb) b child2
Function "child2" not defined.
(gdb) b foo_o224_021.child1.child2
Function "foo_o224_021.child1.child2" not defined.
The problem is caused by the fact that GDB did not create a symbol
for Child2, and this, in turn, is caused by the fact that the compiler
decided to inline Child1, but not Child2. The DWARF debugging info
first provides an abstract instance tree for Child1...
<3><1b7b>: Abbrev Number: 29 (DW_TAG_subprogram)
<1b7c> DW_AT_name : (indirect string, offset: 0x23f8): foo_o224_021__child1
<1b82> DW_AT_inline : 1 (inlined)
<1b83> DW_AT_sibling : <0x1c01>
... where that subprogram is given the DW_AT_inline attribute.
Inside that function there is a lexical block which has no PC
range (corresponding to the fact that this is the abstract tree):
<4><1b87>: Abbrev Number: 30 (DW_TAG_lexical_block)
... inside which our subprogram Child2 is described:
<5><1b92>: Abbrev Number: 32 (DW_TAG_subprogram)
<1b93> DW_AT_name : (indirect string, offset: 0x2452): foo_o224_021__child1__child2
<1b99> DW_AT_type : <0x1ab1>
<1b9d> DW_AT_low_pc : 0x402300
<1ba5> DW_AT_high_pc : 0x57
[...]
Then, later on, we get the concrete instance tree, starting at:
<3><1c5e>: Abbrev Number: 41 (DW_TAG_inlined_subroutine)
<1c5f> DW_AT_abstract_origin: <0x1b7b>
<1c63> DW_AT_entry_pc : 0x4025fd
<1c6b> DW_AT_ranges : 0x150
... which refers to Child1. One of that inlined subroutine children
is the concrete instance of the empty lexical block we saw above
(in the abstract instance tree), which gives the actual address
range for this inlined instance:
<5><1c7a>: Abbrev Number: 43 (DW_TAG_lexical_block)
<1c7b> DW_AT_abstract_origin: <0x1b87>
<1c7f> DW_AT_ranges : 0x180
This is the DIE which provides the context inside which we can
record Child2. But unfortunately, GDB does not take the abstract
origin into account when handling lexical blocks, causing it
to miss the fact that this block contains some symbols described
in the abstract instance tree. This is the first half of this patch:
modifying GDB to follow DW_AT_abstract_origin attributes for
lexical blocks.
But this not enough to fix the issue, as we're still unable to
break on Child2 with just that change. The second issue can be
traced to the way inherit_abstract_dies determines the list of
DIEs to inherit from. For that, it iterates over all the DIEs in
the concrete instance tree, and finds the list of DIEs from the
abstract instance tree that are not referenced from the concrete
instance tree. As it happens, there is one type of DIE in the
concrete instance tree which does reference Child2's DIE, but
in fact does otherwise define a concrete instance of the reference
DIE; that's (where <0x1b92> is Child2's DIE):
<6><1d3c>: Abbrev Number: 35 (DW_TAG_GNU_call_site)
<1d3d> DW_AT_low_pc : 0x4026a4
<1d45> DW_AT_abstract_origin: <0x1b92>
So, the second part of the patch is to modify inherit_abstract_dies
to ignore DW_TAG_GNU_call_site DIEs when iterating over the concrete
instance tree.
This patch also includes a testcase which can be used to reproduce
the issue. Unfortunately, for it to actually pass, a smal patch in
GCC is also necessary to make sure that GCC provides lexical blocks'
DW_AT_abstract_origin attributes from the concrete tree back to
the abstract tree. We hope to be able to submit and integrate that
patch in the GCC tree soon. Meanwhile, a setup_xfail has been added.
gdb/ChangeLog:
2014-05-05 Pierre-Marie de Rodat <derodat@adacore.com>
* dwarf2read.c (inherit_abstract_dies): Skip
DW_TAG_GNU_call_site dies while inheriting children of an
abstract DIE into a scope.
(read_lexical_block_scope): Inherit abstract DIE's for
lexical scopes.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined: New testcase.
Consider the following declarations:
type Int_Access is access Integer;
type Record_Type is record
IA : Int_Access;
end record;
R : Record_Type;
Printing the type name of "R.IA" yields:
(gdb) whatis r.ia
type = access integer
It should be:
(gdb) whatis r.ia
type = bar.int_access
Looking at the debugging info, field "r.ia" is defined as
a typedef which has the name of the field type:
.uleb128 0x3 # (DIE (0x4e) DW_TAG_typedef)
.long .LASF4 # DW_AT_name: "bar__int_access"
.long 0x8b # DW_AT_type
... with the typedef's target type being an anonymous pointer
type:
.uleb128 0x7 # (DIE (0x8b) DW_TAG_pointer_type)
.byte 0x8 # DW_AT_byte_size
.long 0x91 # DW_AT_type
What happens here is that a couple of function in ada-lang.c
always start by stripping all typedef layers when handling
struct fields, with the effect of making us lose the type name
in this case.
We did not understand this at the time the code was written,
but typedefs should be stripped only when we know we do not
need them. So this patch, adjust the code to avoid the stripping
while handling the fields, and adds it back in the lone place
which handles the result of processing and didn't know how to
handle typedefs struct fields yet.
gdb/ChangeLog:
* ada-lang.c (ada_is_tagged_type): Add call to ada_check_typedef.
(ada_lookup_struct_elt_type): Remove calls to ada_check_typedef.
(template_to_static_fixed_type): Call ada_check_typedef only
when necessary.
gdb/testsuite/ChangeLog:
* gdb.ada/rec_comp: New testcase.
Even when referenced types are dynamic, the corresponding referencing
type should not be considered as dynamic: it's only a pointer. This
prevents reference type for values not in memory to be resolved.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal): Remove special handling
of TYPE_CODE_REF types so that they are not considered as
dynamic depending on the referenced type.
(resolve_dynamic_type_internal): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_ref.exp: New file.
* gdb.ada/funcall_ref/foo.adb: New file.
gdb/testsuite/ChangeLog:
PR symtab/17855
* gdb.ada/exec_changed.exp: Add second test where symbol lookup cache
is read after symbols have been re-read.
* gdb.ada/exec_changed/first.adb (First): New procedure Break_Me.
* gdb.ada/exec_changed/second.adb (Second): Ditto.
Consider the following declarations:
type Array_Type is array (Integer range <>) of Integer;
type Record_Type (N : Integer) is record
A : Array_Type (1 .. N);
end record;
R : Record_Type := Get (10);
It defines what Ada programers call a "discriminated record", where
"N" is a component of that record called a "discriminant", and where
"A" is a component defined as an array type whose upper bound is
equal to the value of the discriminant.
So far, we rely on a number of fairly complex GNAT-specific encodings
to handle this situation. This patch is to enhance GDB to be able to
print this record in the case where the compiler has been modified
to replace those encodings by pure DWARF constructs.
In particular, the debugging information generated for the record above
looks like the following. "R" is a record..
.uleb128 0x10 # (DIE (0x13e) DW_TAG_structure_type)
.long .LASF17 # DW_AT_name: "foo__record_type"
... whose is is of course dynamic (not our concern here)...
.uleb128 0xd # DW_AT_byte_size
.byte 0x97 # DW_OP_push_object_address
.byte 0x94 # DW_OP_deref_size
.byte 0x4
.byte 0x99 # DW_OP_call4
.long 0x19b
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x7
.byte 0x9 # DW_OP_const1s
.byte 0xfc
.byte 0x1a # DW_OP_and
.byte 0x1 # DW_AT_decl_file (foo.adb)
.byte 0x6 # DW_AT_decl_line
... and then has 2 members, fist "n" (our discriminant);
.uleb128 0x11 # (DIE (0x153) DW_TAG_member)
.ascii "n\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (foo.adb)
.byte 0x6 # DW_AT_decl_line
.long 0x194 # DW_AT_type
.byte 0 # DW_AT_data_member_location
... and "A"...
.uleb128 0x11 # (DIE (0x181) DW_TAG_member)
.ascii "a\0" # DW_AT_name
.long 0x15d # DW_AT_type
.byte 0x4 # DW_AT_data_member_location
... which is an array ...
.uleb128 0x12 # (DIE (0x15d) DW_TAG_array_type)
.long .LASF18 # DW_AT_name: "foo__record_type__T4b"
.long 0x194 # DW_AT_type
... whose lower bound is implicitly 1, and the upper bound
a reference to DIE 0x153 = "N":
.uleb128 0x13 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x174 # DW_AT_type
.long 0x153 # DW_AT_upper_bound
This patch enhanced GDB to understand references to other DIEs
where the DIE's address is at an offset of its enclosing type.
The difficulty was that the address used to resolve the array's
type (R's address + 4 bytes) is different from the address used
as the base to compute N's address (an offset to R's address).
We're solving this issue by using a stack of addresses rather
than a single address when trying to resolve a type. Each address
in the stack corresponds to each containing level. For instance,
if resolving the field of a struct, the stack should contain
the address of the field at the top, and then the address of
the struct. That way, if the field makes a reference to an object
of the struct, we can retrieve the address of that struct, and
properly resolve the dynamic property references that struct.
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop): New PROP_ADDR_OFFSET enum
kind.
* gdbtypes.c (resolve_dynamic_type_internal): Replace "addr"
parameter by "addr_stack" parameter.
(resolve_dynamic_range): Replace "addr" parameter by
"stack_addr" parameter. Update function documentation.
Update code accordingly.
(resolve_dynamic_array, resolve_dynamic_union)
(resolve_dynamic_struct, resolve_dynamic_type_internal): Likewise.
(resolve_dynamic_type): Update code, following the changes made
to resolve_dynamic_type_internal's interface.
* dwarf2loc.h (struct property_addr_info): New.
(dwarf2_evaluate_property): Replace "address" parameter
by "addr_stack" parameter. Adjust function documentation.
(struct dwarf2_offset_baton): New.
(struct dwarf2_property_baton): Update documentation of
field "referenced_type" to be more general. New field
"offset_info" in union data field.
* dwarf2loc.c (dwarf2_evaluate_property): Replace "address"
parameter by "addr_stack" parameter. Adjust code accordingly.
Add support for PROP_ADDR_OFFSET properties.
* dwarf2read.c (attr_to_dynamic_prop): Add support for
DW_AT_data_member_location attributes as well. Use case
statements instead of if/else condition.
gdb/testsuite/ChangeLog:
* gdb.ada/disc_arr_bound: New testcase.
Tested on x86_64-linux, no regression.
This is preparation work to avoid a regression in the Ada/varobj.
An upcoming patch is going to add support for types in DWARF
which have dynamic properties whose value is a reference to another
DIE.
Consider for instance the following declaration:
type Variant_Type (N : Int := 0) is record
F : String(1 .. N) := (others => 'x');
end record;
type Variant_Type_Access is access all Variant_Type;
VTA : Variant_Type_Access := null;
This declares a variable "VTA" which is an access (=pointer)
to a variant record Variant_Type. This record contains two
components, the first being "N" (the discriminant), and the
second being "F", an array whose lower bound is 1, and whose
upper bound depends on the value of "N" (the discriminant).
Of interest to us, here, is that second component ("F"), and
in particular its bounds. The debugging info, and in particular
the info for the array looks like the following...
.uleb128 0x9 # (DIE (0x91) DW_TAG_array_type)
.long .LASF16 # DW_AT_name: "bar__variant_type__T2b"
.long 0xac # DW_AT_GNAT_descriptive_type
.long 0x2cb # DW_AT_type
.long 0xac # DW_AT_sibling
.uleb128 0xa # (DIE (0xa2) DW_TAG_subrange_type)
.long 0xc4 # DW_AT_type
.long 0x87 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x91
... where the upper bound of the array's subrange type is a reference
to "n"'s DIE (0x87):
.uleb128 0x8 # (DIE (0x87) DW_TAG_member)
.ascii "n\0" # DW_AT_name
[...]
Once the patch to handle this dynamic property gets applied,
this is what happens when creating a varobj for variable "VTA"
(whose value is null), and then trying to list its children:
(gdb)
-var-create vta * vta
^done,name="vta",numchild="2",value="0x0",
type="bar.variant_type_access",has_more="0"
(gdb)
-var-list-children 1 vta
^done,numchild="2",
children=[child={name="vta.n",[...]},
child={name="vta.f",exp="f",
numchild="43877616", <<<<-----
value="[43877616]", <<<<-----
type="array (1 .. n) of character"}],
has_more="0"
It has an odd number of children.
In this case, we cannot really determine the number of children,
since that number depends on the value of a field in a record
for which we do not have a value. Up to now, the value we've been
displaying is zero - meaning we have an empty array.
What happens in this case, is that, because the VTA is a null pointer,
we're not able to resolve the pointer's target type, and therefore
end up asking ada_varobj_get_array_number_of_children to return
the number of elements in that array; for that, it relies blindly
on get_array_bounds, which assumes the type is no longer dynamic,
and therefore the reads the bound without seeing that it's value
is actually a reference rather than a resolved constant.
This patch prevents the issue by explicitly handling the case of
dynamic arrays, and returning zero child in that case.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_get_array_number_of_children):
Return zero if PARENT_VALUE is NULL and parent_type's
range type is dynamic.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_var_array: New testcase.
Tested on x86_64-linux.
Consider the following code:
type Table is array (Positive range <>) of Integer;
type Object (N : Integer) is record
Data : Table (1 .. N);
end record;
My_Object : Object := (N => 3, Data => (3, 5, 8));
Trying to print the range and length of the My_Object.Data array yields:
(gdb) print my_object.data'first
$1 = 1
(gdb) print my_object.data'last
$2 = 0
(gdb) print my_object.data'length
$3 = 0
The first one is correct, and that is thanks to the fact that
the lower bound is statically known. However, for the upper
bound, and consequently the array's length, the values are incorrect.
It should be:
(gdb) print my_object.data'last
$2 = 3
(gdb) print my_object.data'length
$3 = 3
What happens here is that ada_array_bound_from_type sees that
our array has a parallel "___XA" type, and therefore tries to
use it. In particular, it described our array's index type as:
[...]___XDLU_1__n, which means lower bound = 1, and upper bound
is value of "n". Unfortunately, ada_array_bound_from_type does
not have access to the discriminant, and is therefore unable to
compute the bound correctly.
Fortunately, at this stage, the bound has already been computed
a while ago, and therefore doesn't need to be re-computed here.
This patch fixes the issue by ignoring that ___XA type if the array
is marked as already fixed.
This also fixes the same issue with packed arrays.
gdb/ChangeLog:
* ada-lang.c (ada_array_bound_from_type): Ignore array's parallel
___XA type if the array has already been fixed.
gdb/testsuite/ChangeLog:
* gdb.ada/var_arr_attrs: New testcase.
Trying to print the value of a string whose size is not known at
compile-time before it gets assigned a value can lead to the following
internal error:
(gdb) p my_str
$1 =
/[...]/utils.c:1089: internal-error: virtual memory exhausted.
What happens is that my_str is described as a reference to an array
type whose bounds are dynamic. During the read of that variable's
value (in default_read_var_value), we end up resolving dynamic types
which, for reference types, makes us also resolve the target of that
reference type. This means we resolve our variable to a reference
to an array whose bounds are undefined, and unfortunately very far
appart.
So, when we pass that value to ada-valprint, and in particular to
da_val_print_ref, we eventually try to allocate too large of a buffer
corresponding to the (bogus) size of our array, hence the internal
error.
This patch fixes the problem by adding a size_check before trying
to print the dereferenced value. To perform this check, a function
that was previously specific to ada-lang.c (check_size) gets
exported, and renamed to something less prone to name collisions
(ada_ensure_varsize_limit).
gdb/ChangeLog:
* ada-lang.h (ada_ensure_varsize_limit): Declare.
* ada-lang.c (check_size): Remove advance declaration.
(ada_ensure_varsize_limit): Renames check_size.
Replace calls to check_size by calls to ada_ensure_varsize_limit
throughout.
* ada-valprint.c (ada_val_print_ref): Add call to
ada_ensure_varsize_limit. Add comment explaining why.
gdb/testsuite/ChangeLog:
* gdb.ada/str_uninit: New testcase.
Python 3's print requires to use parentheses, so this patch adds them
where they were missing.
gdb/testsuite/ChangeLog:
* gdb.ada/py_range.exp: Add parentheses to calls to print.
* gdb.dwarf2/symtab-producer.exp: Same.
* gdb.gdb/python-interrupts.exp: Same.
* gdb.gdb/python-selftest.exp: Same.
* gdb.python/py-linetable.exp: Same.
* gdb.python/py-type.exp: Same.
* gdb.python/py-value-cc.exp: Same.
* gdb.python/py-value.exp: Same.
Consider the following variable declaration:
type Array_Type is array (Integer range <>) of Integer;
Var: Array_Type (0 .. -1);
"ptype var" prints the wrong upper bound for that array:
(gdb) ptype var
type = array (0 .. 4294967295) of integer
The debugging info for the type of variable "Var" is as follow:
<2><cf>: Abbrev Number: 13 (DW_TAG_structure_type)
<d0> DW_AT_name : foo__var___PAD
<3><db>: Abbrev Number: 14 (DW_TAG_member)
<dc> DW_AT_name : F
<e0> DW_AT_type : <0xa5>
This is just an artifact from code generation, which is just
a wrapper that we should ignore. The real type is the type of
field "F" in that PAD type, which is described as:
<2><a5>: Abbrev Number: 10 (DW_TAG_array_type)
<a6> DW_AT_name : foo__TvarS
<3><b6>: Abbrev Number: 11 (DW_TAG_subrange_type)
<b7> DW_AT_type : <0xc1>
<bb> DW_AT_lower_bound : 0
<bc> DW_AT_upper_bound : 0xffffffff
Trouble occurs because DW_AT_upper_bound is encoded using
a DW_FORM_data4, which is ambiguous regarding signedness.
In that case, dwarf2read.c::dwarf2_get_attr_constant_value
reads the value as unsigned, which is not what we want
in this case.
As it happens, we already have code dealing with this situation
in dwarf2read.c::read_subrange_type which checks whether
the subrange's type is signed or not, and if it is, fixes
the bound's value by sign-extending it:
if (high.kind == PROP_CONST
&& !TYPE_UNSIGNED (base_type) && (high.data.const_val & negative_mask))
high.data.const_val |= negative_mask;
Unfortunately, what happens in our case is that the base type
of the array's subrange type is marked as being unsigned, and
so we never get to apply the sign extension. Following the DWARF
trail, the range's base type is described as another subrange type...
<2><c1>: Abbrev Number: 12 (DW_TAG_subrange_type)
<c7> DW_AT_name : foo__TTvarSP1___XDLU_0__1m
<cb> DW_AT_type : <0x2d>
... whose base type is, (finally), a basic type (signed):
<1><2d>: Abbrev Number: 2 (DW_TAG_base_type)
<2e> DW_AT_byte_size : 4
<2f> DW_AT_encoding : 5 (signed)
<30> DW_AT_name : integer
The reason why GDB thinks that foo__TTvarSP1___XDLU_0__1m
(the base type of the array's range type) is an unsigned type
is found in gdbtypes.c::create_range_type. We consider that
a range type is unsigned iff its lower bound is >= 0:
if (low_bound->kind == PROP_CONST && low_bound->data.const_val >= 0)
TYPE_UNSIGNED (result_type) = 1;
That is normally sufficient, as one would expect the upper bound to
always be greater or equal to the lower bound. But Ada actually
allows the declaration of empty range types where the upper bound
is less than the lower bound. In this case, the upper bound is
negative, so we should not be marking the type as unsigned.
This patch fixes the issue by simply checking the upper bound as well
as the lower bound, and clears the range type's unsigned flag when
it is found to be constant and negative.
gdb/ChangeLog:
* gdbtypes.c (create_range_type): Unset RESULT_TYPE's
flag_unsigned if HIGH_BOUND is constant and negative.
gdb/testsuite/ChangeLog:
* gdb.ada/n_arr_bound: New testcase.
Tested on x86_64-linux.
Consider the following code which declares a variable A2 which
is an array of arrays of integers.
type Array2_First is array (24 .. 26) of Integer;
type Array2_Second is array (1 .. 2) of Array2_First;
A1 : Array1_Second := ((10, 11, 12), (13, 14, 15));
Trying to print the type of that variable currently yields:
(gdb) ptype A2
type = array (1 .. 2, 24 .. 26) of integer
This is not correct, as this is the description of a two-dimension
array, which is different from an array of arrays. The expected
output is:
(gdb) ptype a2
type = array (1 .. 2) of foo_n926_029.array2_first
GDB's struct type currently handles multi-dimension arrays the same
way arrays of arrays, where each dimension is stored as a sub-array.
The ada-valprint module considers that consecutive array layers
are in fact multi-dimension arrays. For array of arrays, a typedef
layer is introduced between the two arrays, creating a break between
each array type.
In our situation, A2 is a described as a typedef of an array type...
.uleb128 0x8 # (DIE (0x125) DW_TAG_variable)
.ascii "a2\0" # DW_AT_name
.long 0xfc # DW_AT_type
.uleb128 0x4 # (DIE (0xfc) DW_TAG_typedef)
.long .LASF5 # DW_AT_name: "foo__array2_second"
.long 0x107 # DW_AT_type
.uleb128 0x5 # (DIE (0x107) DW_TAG_array_type)
.long .LASF5 # DW_AT_name: "foo__array2_second"
.long 0xb4 # DW_AT_type
.uleb128 0x6 # (DIE (0x114) DW_TAG_subrange_type)
.long 0x11b # DW_AT_type
.byte 0x2 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x107
... whose element type is, as expected, a typedef to the sub-array
type:
.uleb128 0x4 # (DIE (0xb4) DW_TAG_typedef)
.long .LASF4 # DW_AT_name: "foo__array2_first"
.long 0xbf # DW_AT_type
.uleb128 0x9 # (DIE (0xbf) DW_TAG_array_type)
.long .LASF4 # DW_AT_name: "foo__array2_first"
.long 0xd8 # DW_AT_GNAT_descriptive_type
.long 0x1c5 # DW_AT_type
.uleb128 0xa # (DIE (0xd0) DW_TAG_subrange_type)
.long 0xf0 # DW_AT_type
.byte 0x18 # DW_AT_lower_bound
.byte 0x1a # DW_AT_upper_bound
.byte 0 # end of children of DIE 0xbf
The reason why things fails is that, during expression evaluation,
GDB tries to "fix" A1's type. Because the sub-array has a parallel
(descriptive) type (DIE 0xd8), GDB thinks that our array's index
type must be dynamic and therefore needs to be fixed. This in turn
causes the sub-array to be "fixed", which itself results in the
typedef layer to be stripped.
However, looking closer at the parallel type, we see...
.uleb128 0xb # (DIE (0xd8) DW_TAG_structure_type)
.long .LASF8 # DW_AT_name: "foo__array2_first___XA"
[...]
.uleb128 0xc # (DIE (0xe4) DW_TAG_member)
.long .LASF10 # DW_AT_name: "foo__Tarray2_firstD1___XDLU_24__26"
... that all it tells us is that the array bounds are 24 and 26,
which is already correctly provided by the array's DW_TAG_subrange_type
bounds, meaning that this parallel type is just redundant.
Parallel types in general are slowly being removed in favor of
standard DWARF constructs. But in the meantime, this patch kills
two birds with one stone:
1. It recognizes this situation where the XA type is useless,
and saves an unnecessary range-type fixing;
2. It fixes the issue at hand because ignoring the XA type results
in no type fixing being required, which allows the typedef layer
to be preserved.
gdb/ChangeLog:
* ada-lang.c (ada_is_redundant_range_encoding): New function.
(ada_is_redundant_index_type_desc): New function.
(to_fixed_array_type): Ignore parallel XA type if redundant.
gdb/testsuite/ChangeLog:
* gdb.ada/arr_arr: New testcase.
Tested on x86_64-linux.
... when that packed array is part of a discriminated record and
one of the bounds is a discriminant.
Consider the following code:
type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]);
type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T;
pragma PACK (FUNNY_STR_T);
type FUNNY_STRING_T (SIZE : NATURAL := 1) is
record
STR : FUNNY_STR_T (1 .. SIZE) := (others => '0');
LENGTH : NATURAL := 4;
end record;
TEST: FUNNY_STRING_T(100);
GDB is able to print the value of variable "test" and "test.str".
But not "test.str(1)":
(gdb) p test
$1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1)
(gdb) p test.str
$2 = (33 'A', nul <repeats 99 times>)
(gdb) p test.str(1)
object size is larger than varsize-limit
The problem occurs during the phase where we are trying to resolve
the expression subscript operation. On the one hand of the subscript
operator, we have the result of the evaluation of "test.str", which
is our packed array. We have the following code to handle packed
arrays in particular:
if (ada_is_constrained_packed_array_type
(desc_base_type (value_type (argvec[0]))))
argvec[0] = ada_coerce_to_simple_array (argvec[0]);
This eventually leads to a call to constrained_packed_array_type
to return the "simple array". This function relies on a parallel
___XA type, when available, to determine the bounds. In our case,
we find type...
failure__funny_string_t__T4b___XA"
... which has one field describing the bounds of our array as:
failure__funny_string_t__T3b___XDLU_1__size
The part that interests us is after the ___XD suffix or,
in other words: "LU_1__size". What this means in GNAT encoding
parlance is that the lower bound is 1, and that the upper bound
is the value of "size". "size" is our discriminant in this case.
Normally, we would access the record's discriminant in order to
get the upper bound's value, but we do not have that information,
here. We are in a mode where we are just trying to "fix" the type
without an actual value. This is what the call to to_fixed_range_type
is doing, and because the fix'ing fails, it ends up returning
the ___XDLU type unmodified as our index type.
This shouldn't be a problem, except that the later part of
constrained_packed_array_type then uses that index_type to
determine the array size, via a call to get_discrete_bounds.
The problem is that the upper bound of the ___XDLU type is
dynamic (in the DWARF sense) while get_discrete_bounds implicitly
assumes that the bounds are static, and therefore accesses
them using macros that assume the bounds values are constants:
case TYPE_CODE_RANGE:
*lowp = TYPE_LOW_BOUND (type);
*highp = TYPE_HIGH_BOUND (type);
This therefore returns a bogus value for the upper bound,
leading to an unexpectedly large size for our array, which
later triggers the varsize-limit guard we've seen above.
This patch avoids the problem by adding special handling
of dynamic range types. It also extends the documentation
of the constrained_packed_array_type function to document
what happens in this situation.
gdb/ChangeLog:
* ada-lang.c (constrained_packed_array_type): Set the length
of the return array as if both bounds where zero if that
returned array's index type is dynamic.
gdb/testsuite/ChangeLog:
* gdb.ada/pkd_arr_elem: New Testcase.
Tested on x86_64-linux.
When trying to evaluate an expression which adds a pointer and
an integral, the evaluation succeeds if the pointer is on
the left handside of the operator, but not when it is on the right
handside:
(gdb) p something'address + 0
$1 = (system.address) 0x613418 <pck.something>
(gdb) p 0 + something'address
Argument to arithmetic operation not a number or boolean.
Same issue when doing subtractions:
(gdb) p something'address - 0
$2 = (system.address) 0x613418 <pck.something>
(gdb) p 0 - something'address
Argument to arithmetic operation not a number or boolean.
This patch enhances the Ada expression evaluator to handle
these two situations.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling
of the case where the second operand is a pointer.
<BINOP_SUB>: Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/addr_arith: New testcase.
Tested on x86_64-linux.
This add a testcases that verifies correct handling of dynamicity
for lower bounds of arrays.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_arrayidx: New testcase.
Given the following variable...
BT : Bounded := New_Bounded (Low => 1, High => 3);
... where type Bounded is defined as a simple unconstrained array:
type Bounded is array (Integer range <>) of Integer;
Creating a varobj for that variable, and immediately asking for
varobj updates, GDB says that our varobj changed types!
(gdb)
-var-create bt * bt
^done,name="bt",numchild="3",value="[3]",type="<ref> array (1 .. 3) of integer",has_more="0"
(gdb)
-var-update 1 *
^done,changelist=[{name="bt",value="[3]",in_scope="true",type_changed="true",new_type="<ref> array (1 .. 3) of integer",new_num_children="3",has_more="0"}]
The expected output for the -var-update command is, in this case:
(gdb)
-var-update 1 *
^done,changelist=[]
The problem occurs because the ada-varobj module does not handle
references, and while the references gets stripped when the varobj
gets created, it doesn't when computing varobj updates.
More specifically, when creating the varobj, varobj_create creates
a new value which is a reference to a TYPE_CODE_ARRAY. It then calls
install_new_value which calls coerce_ref with the following comment:
/* We are not interested in the address of references, and given
that in C++ a reference is not rebindable, it cannot
meaningfully change. So, get hold of the real value. */
if (value)
value = coerce_ref (value);
This leaves the varobj's type component still a ref, while
the varobj's value is now our array, without the ref. This explains
why the "value" field in the varobj indicates an array with 3 elements
"[3]" while the "type" field shows a ref to an array. Generally
speaking, most users have said that showing the ref was a useful
piece of information, so this patch is not touching this part.
Next, when the user issues the -var-update request, varobj_update
calls value_of_root to compute the varobj's new value as well as
determine whether the value's type has changed or not. What happens
in a nutshell is that it calls value_of_root_1 (which re-evaluates
the expression and returns the corresponding new value), finds that
the new value is not NULL, and thus asks whether it has mutated:
else if (varobj_value_has_mutated (var, value, value_type (value)))
This then indirectly delegates the determination to the language-specific
callback, which fails, because it does not handle references.
This patch fixes the issue by adjusting varobj_value_has_mutated to
expect references, and strip them when seen. This allows the various
language-specific implementations to remain unaware of references.
gdb/ChangeLog:
* varobj.c (varobj_value_has_mutated): If NEW_VALUE is
a reference, strip the reference layer before calling
the lang_ops value_has_mutated callback.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_dyn_arr: New testcase.
The completion feature and other features on readline depend on the
readline library. However, readline library is not always used, for
example, running testsuite like
make check RUNTESTFLAGS="--host_board=local-remote-host"
the input stream is not a tty, and GDB doesn't use readline library
as a result.
This patch is to skip tests on completion and readline if
'show editing' is off, which means readline isn't used. Note that
some tests in gdb.base/completion.exp test command complete, which
isn't related to readline, so these tests aren't affected by readline
library. This patch also moves these tests up, run them
unconditionally, and run the rest if readline library is used.
gdb/testsuite:
2014-03-26 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (readline_is_used): New proc.
* gdb.base/completion.exp: Move tests on command complete up.
Skip the rest of tests if readline is not used.
* gdb.ada/complete.exp: Skp the test if readline is not
used.
* gdb.base/filesym.exp: Likewise.
* gdb.base/macscp.exp: Likewise.
* gdb.base/readline-ask.exp: Likewise.
* gdb.base/readline.exp: Likewise.
* gdb.python/py-cmd.exp: Likewise.
* gdb.trace/tfile.exp: Likewise.
When evaluating an expression, if it is of a tagged type, GDB reads
the tag in memory and deduces the full view. At parsing time, however,
this operation is done only in the case of OP_VAR_VALUE. ptype does
not go through a full evaluation of expressions so it may return some
odd results:
(gdb) print c.menu_name
$1 = 0x0
(gdb) ptype $
type = system.strings.string_access
(gdb) ptype c.menu_name
type = <void>
This change removes this peculiarity by extending the tag resolution
to UNOP_IND and STRUCTOP_STRUCT. As in the case of OP_VAR_VALUE, this
implies switching from EVAL_AVOID_SIDE_EFFECTS to EVAL_NORMAL when a
tagged type is dereferenced.
gdb/
* ada-lang.c (ada_evaluate_subexp): Resolve tagged types to
full view in the case of UNOP_IND and STRUCTOP_STRUCT.
gdb/testsuite/
* gdb.ada/tagged_access: New testcase.
With the test changed as in the patch, against current mainline, we get:
(gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
break break_me task 1
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
break break_me task 3
Note: breakpoint 2 also set at pc 0x4030b0.
Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 3 main_task
2 63bd80 1 48 Accept or Select Term task_list(1)
* 3 63f510 1 48 Accepting RV with 1 task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.
The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check. This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
}
IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly. Put another task-specific or
non-task-specific breakpoint there, and things break.
A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint. IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:
break break_me task 3
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 2 main_task
* 2 63bd80 1 48 Accepting RV with 1 task_list(1)
3 63f510 1 48 Accept or Select Term task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
It was after seeing this that I thought of how to expose the bug with
current mainline.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
task-specific breakpoints.
gdb/testsuite/
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
Consider the following code:
type Color is (Black, Red, Green, Blue, White);
type Primary_Table is array (Color range Red .. Blue) of Boolean;
Prim : Primary_Table := (True, False, False);
GDB prints the length of arrays in a fairly odd way:
(gdb) p prim'length
$2 = blue
The length returned should be an integer, not the array index type,
and this patch fixes this.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp): Set the type of the value
returned by the 'Length attribute to integer.
testsuite/ChangeLog:
* gdb.ada/tick_length_array_enum_idx: New testcase.
type Char_Table is array (Character range Character'First .. Character'Last)
of Natural;
Trying to print the type description of this type currently yields:
(gdb) ptype char_table
type = array ('["00"]' .. '["ff"]') of natural
Although technically correct, it seemed more useful to print the array
range as:
(gdb) ptype char_table
type = array (character) of natural
This patch implements this suggestion.
gdb/ChangeLog:
* ada-typeprint (type_is_full_subrange_of_target_type):
New function.
(print_range): Add parameter bounds_prefered_p. If not set,
try printing range types using the name of their base type.
(print_range_type): Add parameter bounds_prefered_p.
Use it in call to print_range.
(print_array_type, ada_print_type): Update calls to print_range
and print_range_type.
gdb/testsuite/ChangeLog:
* gdb.ada/array_char_idx: New testcase.
Consider the following code:
type Element is abstract tagged null record;
type GADataType is interface;
type Data_Type is new Element and GADataType with record
I : Integer := 42;
end record;
Result1 : Data_Type;
GGG1 : GADataType'Class := GADataType'Class (Result1);
When trying to create a varobj for variable ggg1, GDB currently
returns an object which has no child:
-var-create ggg1 * ggg1
^done,name="ggg1",numchild="0",[...]
This is incorrect, it should return an object which has one child
(field "i"). This is because tagged-type objects are dynamic, and
we need to apply a small transformation in order to get their actual
type. This is already done on the GDB/CLI side in ada-valprint,
and it needs to be done on the ada-varobj side as well.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_adjust_for_child_access): Convert
tagged type objects to their actual type.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_interface: New testcase.
Consider the following types:
type Time_T is record
Secs : Integer;
end record;
Before : Time_T := (Secs => 1384395743);
In this example, we assume that type Time_T is the number of seconds
since Epoch, and so added a Python pretty-printer, to print this
type in a more human-friendly way. For instance:
(gdb) print before
$1 = Thu Nov 14 02:22:23 2013 (1384395743)
However, we've noticed that things stop working when this type is
embedded inside another record, and we try to print that record.
For instance, with the following declarations:
type Composite is record
Id : Integer;
T : Time_T;
end record;
Afternoon : Composite := (Id => 1, T => (Secs => 1384395865));
(gdb) print afternoon
$2 = (id => 1, t => (secs => 1384395865))
We expected instead:
(gdb) print afternoon
$2 = (id => 1, t => Thu Nov 14 02:24:25 2013 (1384395865))
This patch fixes the problem by making sure that we try to print
each field via a call to val_print, rather than calling ada_val_print
directly. We need to go through val_print, as the val_print
handles all language-independent features such as calling the
pretty-printer, knowing that ada_val_print will get called eventually
if actual Ada-specific printing is required (which should be the
most common scenario).
And because val_print takes the language as parameter, we enhanced
the print_field_values and print_variant_part to also take a language.
As a bonus, this allows us to remove a couple of references to
current_language.
gdb/ChangeLog:
* ada-valprint.c (print_field_values): Add "language" parameter.
Update calls to print_field_values and print_variant_part.
Pass new parameter "language" in call to val_print instead
of "current_language". Replace call to ada_val_print by call
to val_print.
(print_variant_part): Add "language" parameter.
(ada_val_print_struct_union): Update call to print_field_values.
gdb/testsuite/ChangeLog:
* gdb.ada/pp-rec-component.exp, gdb.ada/pp-rec-component.py,
gdb.ada/pp-rec-component/foo.adb, gdb.ada/pp-rec-component/pck.adb,
gdb.ada/pp-rec-component/pck.ads: New files.
This function has the following code:
elt_type = type;
for (i = n; i > 1; i--)
elt_type = TYPE_TARGET_TYPE (type);
For multi-dimension arrays, the code above tries to find the array
type corresponding to the dimension we're trying to inspect.
The problem is that, past the second dimension, the loop does
nothing other than repeat the first iteration. There is a little
thinko where it got the TYPE_TARGET_TYPE of TYPE instead of ELT_TYPE!
To my surprise, I was unable to produce an Ada exemple that demonstrated
the problem. That's because the examples I created all trigger a parallel
___XA type which we then use in place of the ELT_TYPE in order to
determine the bounds - see the code that immediately follows our
loop above:
index_type_desc = ada_find_parallel_type (type, "___XA");
ada_fixup_array_indexes_type (index_type_desc);
if (index_type_desc != NULL)
[...]
So, in order to avoid depending on an Ada example where the compiler
can potentially decide one way or the other, I decided to use an
artificial example, written in C. With ...
int multi[1][2][3];
... forcing the language to Ada, and trying to print the 'last,
we get:
(gdb) p multi'last(1)
$1 = 0
(gdb) p multi'last(2)
$2 = 1
(gdb) p multi'last(3)
$3 = 1 <<<--- This should be 2!
Additionally, I noticed that a couple of check_typedef's were missing.
This patch adds them. And since the variable in question only gets
used within an "else" block, I moved the variable declaration and
use inside that block - making it clear what the scope of the variable
is.
gdb/ChangeLog:
* ada-lang.c (ada_array_bound_from_type): Move the declaration
and assignment of variable "elt_type" inside the else block
where it is used. Add two missing check_typedef calls.
Fix bug where we got TYPE's TYPE_TARGET_TYPE, where in fact
we really wanted to get ELT_TYPE's TYPE_TARGET_TYPE.
gdb/testsuite/ChangeLog:
* gdb.ada/arraydim: New testcase.
This helps with the following issue: Given an Ada program defining
a global variable:
package Pck is
Watch : Integer := 1974;
end Pck;
When printing the address of this variable, GDB also tries to print
the associated symbol name:
(gdb) p watch'address
$1 = (access integer) 0x6139d8 <pck__watch>
^^
||
The problem is that GDB prints the variable's linkage name, instead
of its natural name. This is because the language of the associated
minimal symbol never really gets set.
This patch adds handling for Ada symbols in symbol_find_demangled_name.
After this patch, we now get:
(gdb) p watch'address
$1 = (access integer) 0x6139d8 <pck.watch>
^
|
gdb/ChangeLog:
* symtab.c (symbol_find_demangled_name): Add handling of
Ada symbols.
gdb/testsuite/ChangeLog:
* gdb.ada/int_deref.exp: Add test verifying that we print
the decoded symbol name when printing the address of Ada
symbols.
Joel Brobecker
Pierre-Marie de Rodat
Jan Kratochvil
Jerome Guitton
Doug Evans
Simon Marchi
Andreas Arnez
Yao Qi
Pedro Alves