mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-28 12:33:36 +08:00
a2cd4f1475
318 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Joel Brobecker
|
a2cd4f1475 |
(Ada) fix GDB crash printing packed array
Trying to print a packed array sometimes leads to a crash (see
attached testcase for an example of when this happens):
| (gdb) p bad
| [1] 65571 segmentation fault gdb -q foo
Variable "bad" is declared in the debug information as an array where
the array's type name has an XPnnn suffix:
| .uleb128 0xc # (DIE (0x566) DW_TAG_typedef)
| .long .LASF200 # DW_AT_name: "pck__t___XP1"
| [loc info attributes snipped]
| .long 0x550 # DW_AT_type
| .byte 0x1 # DW_AT_alignment
The signals to GDB that the debugging information follows a GNAT encoding
used for packed arrays, and an in order to decode it, we need to find
the type whose name is the same minus the "___XPnnn" suffix: "pck__t".
For that, we make a call to ada-lang.c::standard_lookup, which is
a simple function which essentially does:
| /* Return the result of a standard (literal, C-like) lookup of NAME in
| given DOMAIN, visible from lexical block BLOCK. */
|
| [...]
| sym = lookup_symbol_in_language (name, block, domain, language_c, 0);
Unfortunately for us, while the intent of this call was to perform
an exact-match lookup, in our case, it returns ... type pck__t___XP1
instead! In other words, it finds itself back. The reason why it finds
this type is a confluence of two factors:
(1) Forcing the lookup into language_c currently does not affect
how symbol matching is done anymore, because we look at the symbol's
language to determine which kind of matching should be done;
(2) The lookup searches the local context (via block) first, beforei
doing a more general lookup. And looking at the debug info for
the main subprogram, we see that type "pck__t" is not declared
there, only in the debug info for pck.ads. In other words,
there is no way that we accidently find "pck__t" by random chance.
I believe Pedro added a new function called ada_lookup_encoded_symbol
for that specific purpose, so I started by replacing the lookup
by language above by this. Unfortunately, still no joy.
This was because, even though ada_lookup_encoded_symbol puts angle-
brackets around the search name to signal that we want a verbatim
search, we end up losing that information in the function called
to compare a symbol with the search name:
| static bool
| do_full_match (const char *symbol_search_name,
| const lookup_name_info &lookup_name,
| completion_match_result *comp_match_res)
| {
| return full_match (symbol_search_name, ada_lookup_name (lookup_name));
^^^^^^^^^^^^^^^
|
<=> lookup_name.m_ada.m_encoded_name
(no angle brackets)
The way I fixed this was by introducing a new function called
do_exact_match, and then adjust ada_get_symbol_name_matcher to
return that function when seeing that we have a verbatim non-wild-match
search.
As it happens, this fixes an incorrect test in gdb.ada/homony.exp,
where we were inserting a breakpoint on a symbol using the angle-brackets
notation, and got 2 locations for that breakpoint...
(gdb) b <homonym__get_value>
Breakpoint 1 at 0x4029fc: <homonym__get_value>. (2 locations)
... each location being in a different function:
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004029fc in homonym.get_value
at /[...]/homonym.adb:32
1.2 y 0x0000000000402a3a in homonym.get_value
at /[...]/homonym.adb:50
(gdb) x /i 0x00000000004029fc
0x4029fc <homonym__get_value+8>: movl $0x1d,-0x4(%rbp)
(gdb) x /i 0x0000000000402a3a
0x402a3a <homonym__get_value__2+8>: movl $0x11,-0x4(%rbp)
Since we used angle-brackets, we shouldn't be matching the second one,
something this patch fixes.
gdb/ChangeLog:
* ada-lang.c (standard_lookup): Use ada_lookup_encoded_symbol
instead of lookup_symbol_in_language
(do_exact_match): New function.
(ada_get_symbol_name_matcher): Return do_exact_match when
doing a verbatim match.
gdb/testsuite/ChangeLog:
* gdb.ada/big_packed_array: New testcase.
* gdb.ada/homonym.exp: Fix incorrect expected output for
"break <homonym__get_value>" test.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
aff29d1c73 |
(Ada) -var-update crash for variable whose type is a reference to changeable
Consider the following variable, which is a string whose value
is not known at compile time, because it is the return value
from a function call (Get_Name):
A : String := Get_Name;
If one tries to create a varobj for that variable, everything works
as expected:
| (gdb) -var-create a * a
| ^done,name="a",numchild="19",value="[19] \"Some kind of string\"",type="<ref> array (1 .. 19) of character",thread-id="1",has_more="0"
However, try then to request an update, regardless of whether the string
has changed or not, and we get a crash:
| -var-update a
| ~"/[...]/gdb/varobj.c:1379: internal-error: bool install_new_value(varobj*, value*, bool): Assertion `!value_lazy (var->value.get ())' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "
When the varobj gets created (-var-create), the expression is evaluated
and transformed into a value. The debugging information describes our
variables as a reference to an array of characters, so our value has
the corresponding type. We then call varobj.c::install_new_value
to store that value inside our varobj, and we see that this function
pretty starts by determining weither our varobj is changeable, via:
| changeable = varobj_value_is_changeable_p (var);
(where 'var' is the varobj we are building, and where the function
varobj_value_is_changeable_p simply dispatches to the Ada version
of this routine: ada_value_is_changeable_p).
At this point, the varobj doesn't have a value, yet, but it does
have a type which was provided by varobj_create a little bit before
install_new_value was called. So ada_value_is_changeable_p uses that
to determine whether or not our type is changeable.
Since our type is a reference to an array, and that the value of
such objects is displayed as if there weren't a reference, it means
that our object is changeable -- in other words, if an element of
the string changes, then the "value" field of the varobj will change
accordingly. But unfortunately, ada_value_is_changeable_p mistakenly
returns false, because it is missing the handling of reference types.
As a consequence of this, install_new_value doesn't feel it is
necessary to fetch the value's contents, as explained by the following
comment inside that function:
/* The new value might be lazy. If the type is changeable,
that is we'll be comparing values of this type, fetch the
value now. Otherwise, on the next update the old value
will be lazy, which means we've lost that old value. */
This means that a lazy value gets installed inside our varobj
as a result of the mistake in ada_value_is_changeable_p.
Another important detail is that, after determining whether
our varobj is changeable or not, it then purposefully removes
the reference layer from our value:
/* 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);
The consequence of those two facts on shows up only later, when
the user requests an update (-var-update). When doing so, GDB
evaluates the expression again into a value which is once more
a reference to a string, and then calls install_new_value again
to install the new value and report any changes. This time around,
the call to...
| changeable = varobj_value_is_changeable_p (var);
... now gets a varobj which has a value, and one which had the reference
layer removed! So, this time, we classify the varobj correctly, and
say it is changeable. And because it is changeable, we then go into
the section of code in install_new_value which checks for changes,
where we need the varobj's value to not be lazy, as explained by
the comment we quoted above. That's what the assertion was about.
This patch fixes the issues by teaching ada_value_is_changeable_p
to ignore reference layers when evaluating a given varobj's type.
gdb/ChangeLog:
* ada-varobj.c (ada_value_is_changeable_p): Add handling of
TYPE_CODE_REF types.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ref_changeable: New testcase.
Prior to this patch, this testcase reports 2 unresolved tests
(due to GDB hitting the internal error). With this patch, all
tests in this testcase pass.
Tested on x86_64-linux, no regression.
|
||
|
Joel Brobecker
|
42a4f53d2b |
Update copyright year range in all GDB files.
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files. |
||
Philippe Waroquiers
|
293bf1a719 |
Fix gdb.ada/fun_renaming.exp by using more unique names.
The test fails due to conflict between var 'next' and s-pooloc.adb next: (gdb) print next(1) Multiple matches for next [0] cancel [1] pack.next (integer) return integer at /bd/home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/fun_renaming/pack.adb:19 [2] system.pool_local.next (system.address) return system.pool_local.acc_address at s-pooloc.adb:151 > FAIL: gdb.ada/fun_renaming.exp: print next(1) (timeout) Fix by making the names and renamings more unique. gdb/testsuite/ChangeLog 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/fun_renaming/pack.ads (Next): Rename to Fun_Rename_Test_Next. (Renamed_Next): Rename to Renamed_Fun_Rename_Test_Next. gdb.ada/fun_renaming/pack.adb (Next): Rename to Fun_Rename_Test_Next. gdb.ada/fun_renaming/fun_renaming.adb (N): Rename to Fun_Rename_Test_N. gdb.ada/fun_renaming.exp: Update accordingly. |
||
|
Philippe Waroquiers
|
3cf139964e |
Fix gdb.ada/assign_arr.exp by using more unique names.
The test fails (timeout) due to conflict between var 'input' and s-ststop.adb 'input': (gdb) print input.u2 := (0.25,0.5,0.75) Multiple matches for input [0] cancel [1] system.strings.stream_ops.storage_array_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return system.storage_elements.storage_array at s-ststop.adb:127 [2] system.strings.stream_ops.stream_element_array_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return ada.streams.stream_element_array at s-ststop.adb:127 [3] system.strings.stream_ops.string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return string at s-ststop.adb:127 [4] system.strings.stream_ops.wide_string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return wide_string at s-ststop.adb:127 [5] system.strings.stream_ops.wide_wide_string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return wide_wide_string at s-ststop.adb:127 [6] target_wrapper.input at /bd/home/philippe/gdb/git/info_t/gdb/testsuite/gdb.ada/assign_arr/target_wrapper.ads:24 > FAIL: gdb.ada/assign_arr.exp: print input.u2 := (0.25,0.5,0.75) (timeout) gdb/testsuite/ChangeLog 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/assign_arr/target_wrapper.ads (Input): Rename to Assign_Arr_Input. main_p324_051.adb: Update accordingly. gdb.ada/assign_arr.exp: Likewise. |
||
|
Philippe Waroquiers
|
afcfda091e |
Improve gdb.ada/rename_subscript_param.exp by using more unique names.
With old compilers, the test fails because no debug info is generated for 'B' and GDB finds some 'b' in atnat.h: (gdb) print b Multiple matches for b [0] cancel [1] b at ../sysdeps/ieee754/dbl-64/atnat.h:106 [2] b at ../sysdeps/ieee754/dbl-64/atnat.h:106 [3] b at ../sysdeps/ieee754/dbl-64/atnat.h:106 > FAIL: gdb.ada/rename_subscript_param.exp: print b before changing its value (timeout) Avoid the timeout by renaming 'b' to rename_subscript_param_b. Also, change 'before' to 'after' in the gdb_test message that prints the value after changing it. The test still fails with old compilers that do not properly generate debug info for this renaming: (gdb) print rename_subscript_param_b No definition of "rename_subscript_param_b" in current context. (gdb) FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b before changing its value Note: if the compiler would generate the correct debug info, the test should succeed with the name B. However, waiting for this fix, changing the name ensures that the test fails directly, instead of causing a timeout. 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> PR ada/23381 * gdb.ada/rename_subscript_param/pkg.adb (B): Rename to Rename_Subscript_Param_B. All users updated. gdb.ada/rename_subscript_param.exp: Test names made unique. Note that PR ada/23381 is only fully fixed when using a recent compiler. |
||
|
Philippe Waroquiers
|
2ab54467f8 |
Fix gdb.ada/packed_array_assign.exp by using more unique names.
The test gdb.ada/packed_array_assign fails due to conflict between component 'w' and system.dim.mks.w: (gdb) print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23)) Unknown component name: system.dim.mks.w. (gdb) FAIL: gdb.ada/packed_array_assign.exp: print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23)) Also, depending on the compiler version, the component w might be reordered and placed before components x and y. So, change the component order in the source, so that both an old compiler (GNATMAKE 6.3.0, gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516) and a new compiler (GNATMAKE Pro 20.0w (20181210-82), based on gcc 8.2.1) produce the same component order (checked by using -gnatR3s). So, update to test the new (more unique) names in the source order. 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/packed_array_assign/aggregates.ads (Packed_Rec): Rename components to Packed_Array_Assign_[X|Y|W]. Place component Packed_Array_Assign_W as first component, to ensure old and new compilers have the same representation. All users updated. |
||
|
Philippe Waroquiers
|
b5a1e55720 |
Fix gdb.ada bp_fun_addr failure due to conflict between fun 'a' and s-dimmks.ads 'A'.
The test fails (timeout) due to: (gdb) PASS: gdb.ada/bp_fun_addr.exp: break *a'address run Starting program: /bd/home/philippe/gdb/git/build_info_t/gdb/testsuite/outputs/gdb.ada/bp_fun_addr/a Multiple matches for a [0] cancel [1] a at /bd/home/philippe/gdb/git/info_t/gdb/testsuite/gdb.ada/bp_fun_addr/a.adb:18 [2] system.dim.mks.a at s-dimmks.ads:115 > FAIL: gdb.ada/bp_fun_addr.exp: run until breakpoint at a'address (timeout) testcase /home/philippe/gdb/git/build_info_t/gdb/testsuite/../../../info_t/gdb/testsuite/gdb.ada/bp_fun_addr.exp completed in 10 seconds Fix this by using a fun name that has more chances to be unique. 2018-12-24 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/bp_fun_addr/a.adb (a): Rename to bp_fun_addr. Filename a.adb changed to bp_fun_addr.adb. gdb.ada/bp_fun_addr.exp: Update test accordingly. |
||
|
Philippe Waroquiers
|
161d081c56 |
Ensure deterministic result order in gdb.ada/info_auto_lang.exp
standard_ada_testfile, standard_test_file and the explicit csrcfile assignment in info_auto_lang.exp all gives similar pathnames prefix for a source, such as /home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>. Note that the above pathnames contain ../ which appears when a relative pathname is used to call configure. In any case, the gnat compiler normalizes Ada sources path when compiling. So, the 'Ada' .o object are referencing a pathname such as /home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb, while the 'C' .o object still references the not normalized pathname. As the results of 'info functions | ...' are sorted by pathname first, the order of the results depends on the comparison between different directories, leading to results that can change depending on these directories. => Ensure the result order is always the same, by normalising the C source file, which makes the results independent of the way configure is launched. Tested by running the testcase in 2 different builds, that without normalize were giving different results. Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C. After discussion, it was deemed sufficient to just normalize the pathname for this test. gdb/testsuite/ChangeLog 2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: Normalize some_c source file. Update order of results accordingly. |
||
|
Philippe Waroquiers
|
fb5e1ed910 |
Add a test to verify info [functions|variables|types]|rbreak respect language_mode.
2018-11-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: New testcase. * gdb.ada/info_auto_lang/global_pack.ads: New file. * gdb.ada/info_auto_lang/proc_in_ada.adb: New file. * gdb.ada/info_auto_lang/some_c.c: New file. |
||
|
Joel Brobecker
|
e2b7af7242 |
(Ada) fix "error in expression" when using watch -location command
The "watch -l EXPR" command with the language set to Ada currently
fails with the following error:
(gdb) watch -l global_var
Error in expression, near ` 0x000000000062d2d8'.
The error occurs because GDB internally translate the request into
a watchpoint on a different expression: "* (TYPE *) ADDR" where
TYPE and ADDR are the type and the address of the object returned
by the expression's evaluation (resp.). So, in the example above,
global_var being an integer stored at 0x000000000062d2d8, GDB tries
to set a watchpoint on "* (integer *) 0x000000000062d2d8", which
fails, because we try to parse this expression with Ada, when
in fact it is not valid.
This patch fixes the issue by implementing the la_watch_location_expression
language method, using a syntax that the Ada parser recognizes
("{TYPE} ADDR").
gdb/ChangeLog:
* ada-lang.c (ada_watch_location_expression): New function.
(ada_language_defn): Set la_watch_location_expression to
ada_watch_location_expression.
gdb/testsuite/ChangeLog:
* gdb.ada/watch_minus_l: New testcase.
|
||
Tom de Vries
|
812cd6eb05 |
[gdb/testsuite] Fix capitalized test names
At https://sourceware.org/gdb/wiki/GDBTestcaseCookbook\ #Follow_the_test_name_convention we find: .. Test names should start with a lower case and don't need to end with a period (they are not sentences). ... Fix some capitalized test names. Tested on x86_64-linux. 2018-10-18 Tom de Vries <tdevries@suse.de> * gdb.ada/bp_inlined_func.exp: Fix capitalized test name. * gdb.ada/excep_handle.exp: Same. * gdb.ada/mi_string_access.exp: Same. * gdb.ada/mi_var_union.exp: Same. * gdb.arch/arc-analyze-prologue.exp: Same. * gdb.arch/arc-decode-insn.exp: Same. * gdb.base/readnever.exp: Same. * gdb.fortran/printing-types.exp: Same. * gdb.guile/scm-lazy-string.exp: Same. |
||
Sergio Durigan Junior
|
7a6d2b458f |
Expect for "@" when doing "complete break ada" on gdb.ada/complete.exp
Currently, gdb.ada/complete.exp's "complete break ada" test fails because the regexp used to match the command's output doesn't expect "@", but we have an output like: ... complete break ada break ada.assertions.assert break ada.calendar.arithmetic.difference break ada.calendar.arithmetic_operations.add break ada.calendar.arithmetic_operations.add.cold break ada.calendar.arithmetic_operations.add@plt break ada.calendar.arithmetic_operations.difference break ada.calendar.arithmetic_operations.difference@plt ... This patch adds "@" to the regexp, unbreaking the test. OK? gdb/testsuite/ChangeLog: 2018-09-18 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.ada/complete.exp: Expect for "@" when doing "complete break ada". |
||
Jerome Guitton
|
1f5d1570c0 |
(Ada) Fix resolving of homonym components in tagged types
ada_value_struct_elt is used when displaying a component (say, 'N') of
a record object (say, 'Obj') of type, say, 't1'. Now if Obj is tagged
(Ada parlance: "tagged types" are what other object-oriented languages
call "classes"), then 'N' may not be visible in the current view and
we need to look for it in its actual type. We do that at the same time
as resolving variable-length fields. This would typically be done by
the following call to ada_value_struct_elt, with the last parameter
check_tag set to 1:
t1 = ada_to_fixed_type (ada_get_base_type (t1), NULL,
address, NULL, 1);
This is the general logic, but recently we introduced a special case
to handle homonyms. Different components may have the same name in a
tagged type. For instance:
type Top_T is tagged record
N : Integer := 1;
end record;
type Middle_T is new Top.Top_T with record
N : Character := 'a';
end record;
Middle_T extends Top_T and both define a (different) component with
the same name ('N'). In such a case, using the actual type of a
Middle_T object would create a confusion, since we would have two
component 'N' in this actual type.
So, to handle homonyms, we convert t1 to the actual type *if
and only if* N cannot be found in the current view. For example, if Obj
has been created as a Middle_T but is seen as a Top_T'Class at our
point of execution, then "print Obj.N" will display the integer field
defined in Top_T's declaration.
Now, even if we find N in the current view, we still have to get a
fixed type: for instance, the record can be unconstrained and we still
need a fixed type to get the proper offset to each field. That is
to say, in this case:
type Dyn_Top_T (Disc : Natural) is tagged record
S : Integer_Array (1 .. Disc) := (others => Disc);
N : Integer := 1;
end record;
type Dyn_Middle_T is new Dyn_Top.Dyn_Top_T with record
N : Character := 'a';
U : Integer := 42;
end record;
If we have an object Obj of type Dyn_Middle_T and we want to display
U, we don't need to build, from its tag, a real type with all its real
fields. In other words, we don't need to add the parent components:
Disc, S, and the integer N. We only need to access U and it is
directly visible in Dyn_Middle_T. So no tag handling. However, we do
need to build a fixed-size type to have the proper offset to U (since
this offset to U depends on the size of Obj.S, which itself is dynamic
and depends on the value of Obj.Disc).
We accidentally lost some of this treatment when we introduced the
resolution of homonyms. This patch re-install this part by uncoupling
the tag resolution from the "fixing" of variable-length components.
This change also slightly simplifies the non-tagged case: in the
non-tagged case, no need to set check_tag to 1, since we already know
that there is no tag.
gdb/ChangeLog:
* ada-lang.c (ada_value_struct_elt): Call ada_to_fixed_type
with check_tag to 1 if and only if the type is tagged and the
component being searched cannot been found in the current
view. Otherwise, always call ada_to_fixed_type with
check_tag to 0.
gdb/testsuite/ChangeLog:
* gdb.ada/same_component_name: Add test for case of tagged record
with variable-length fields.
|
||
Xavier Roirand
|
cc330e39bc |
(Ada) Fix printing of access to unconstrained arrays
Using this Ada code:
type String_Access is access String;
type Array_Of_String is array (1 .. 2) of String_Access;
Aos : Array_Of_String := (new String'("ab"), new String'("cd"));
When debugging with GDB, printing each Aos element displays:
(gdb) print Aos(1)
$2 = "ab"
(gdb) print Aos(2)
$3 = "cd"
Whereas it should display:
(gdb) print Aos(1)
$2 = (foo_r118_024.string_access) 0x635018
(gdb) print Aos(2)
$3 = (foo_r118_024.string_access) 0x635038
Notice that printing the entire array works:
(gdb) print Aos
$1 = (0x635018, 0x635038)
The problem was located in ada_value_print function and due to the fact
that the value_type used in this function was based on
value_enclosing_type rather than value_type itself.
In our example, the difference between the value_type and the
value_enclosing_type of the value is that the value_type contains an
additional typedef layer which is not present in the value_enclosing_type.
This typedef layer is GNAT's way to specify that the element is, at the
source level, an access to the unconstrained array, rather than the
unconstrained array.
Moreover, the value_enclosing_type is not really needed in that case and
the value_type can be used instead in this function, and this patch fixes
this.
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use type instead of
enclosing type.
testsuite/ChangeLog:
* gdb.ada/access_to_unbounded_array.exp: New testcase.
* gdb.ada/access_to_unbounded_array/foo.adb: New file.
* gdb.ada/access_to_unbounded_array/pack.adb: New file.
* gdb.ada/access_to_unbounded_array/pack.ads: New file.
Tested: x86_64-linux
|
||
|
Xavier Roirand
|
b9c50e9a9a |
(Ada/MI) Fix -var-evaluate-expression for access to unconstrained arrays
Using this Ada code:
type String_Access is access String;
type Array_Of_String is array (1 .. 2) of String_Access;
Aos : Array_Of_String := (new String'("ab"), new String'("cd"));
In GDB/MI mode, create a variable which type is Aos, evaluate it:
(gdb) -var-create var1 * Aos
^done,name="var1",numchild="2",value="[2]",type="bar.array_of_string",thread-id="1",has_more="0"
Now print it:
(gdb) -var-list-children 1 var1
^done,numchild="2",children=[child={name="var1.1",exp="1",numchild="1",value="[2] \"ab\"", type="bar.string_access",thread-id="1"},child={name="var1.2",exp="2",numchild="1",value="[2] \"cd\"", type="bar.string_access",thread-id="1"}],has_more="0"
But printed fields "value" are wrong, since it should be:
^done,numchild="2",children=[child={name="var1.1",exp="1",numchild="1",value="0x634018",type="bar.string_access",thread-id="1"},child={name="var1.2",exp="2",numchild="1",value="0x634038",type="bar.string_access",thread-id="1"}],has_more="0"^M
Print each child of var1:
(gdb) -var-evaluate-expression var1.1
^done,value="[2] \"ab\""
(gdb) -var-evaluate-expression var1.2
^done,value="[2] \"cd\""
Whereas it should be
(gdb) -var-evaluate-expression var1.1
^done,value="0x635018"
(gdb) -var-evaluate-expression var1.2
^done,value="0x635038"
This patch fixes this.
gdb/ChangeLog:
* ada-lang.c (ada_value_subscript): Handle case when parameter is
an array of access to unconstrained array.
testsuite/ChangeLog
* gdb.ada/mi_string_access.exp: New testcase.
* gdb.ada/mi_string_access/bar.adb: New file.
* gdb.ada/mi_string_access/pck.adb: New file.
* gdb.ada/mi_string_access/pck.asd: New file.
Tested on x86_64-linux.
|
||
|
Xavier Roirand
|
2963898f38 |
(Ada) Fix -var-list-children MI command for union type
Using this Ada code:
type Union_Type (A : Boolean := False) is record
case A is
when True => B : Integer;
when False => C : Float;
end case;
end record;
pragma Unchecked_Union (Union_Type);
Ut : Union_Type := (A => True, B => 3);
In GDB/MI mode, once creating a varobj from variable "Ut" as follow:
(gdb) -var-create var1 * ut
^done,name="var1",numchild="2",value="{...}",type="foo.union_type",thread-id="1",has_more="0"
Printing the list of its children displays:
(gdb) -var-list-children 1 var1
^error,msg="Duplicate variable object name"
Whereas it should be
(gdb) -var-list-children 1 var1
^done,numchild="2",children=[child={name="var1.b",exp="b",numchild="0",value="3",type="integer",thread-id="1"},child={name="var1.c",exp="c",numchild="0",value="4.20389539e-45",type="float",thread-id="1"}],has_more="0"
The problem occurs because ada_varobj_describe_struct_child wasn't
handling unions. This patch fixes this.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_describe_struct_child)
(ada_varobj_describe_child): Handle union case like struct one.
testsuite/ChangeLog
* gdb.ada/mi_var_union.exp: New testcase.
* gdb.ada/mi_var_union/bar.adb: New file.
* gdb.ada/mi_var_union/pck.adb: New file.
* gdb.ada/mi_var_union/pck.asd: New file.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
424da6cf3b |
(Ada) fix handling of expression with parameterless function call
Consider the following function, which takes no parameter and returns
an integer:
function Something return Integer;
For the purpose of this discussion, our function has been implemented
to always return 124:
function Something return Integer is
begin
return 124;
end Something;
In Ada, such function can been called without using the parentheses.
For instance, in the statement below, variable My_Value is assigned
the returned value from the call to Something:
My_Value := Something;
The Ada expression interpeter in GDB supports this case, as we can
see below:
(gdb) print something
$1 = 124
However, we get fairly strange results when trying to use this feature
as part of a larger expression. For instance:
(gdb) print something + 1
$2 = 248
The problem occurs while doing the resolution pass of the expression.
After prefixying the expression, we obtain the following expression:
0 BINOP_ADD
1 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
5 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
The resolution pass is then expected to remove the OP_VAR_VALUE
entry, and replace it with an OP_FUNCALL. This is what the call
to replace_operator_with_call in ada-lang.c::resolve_subexp is
expected to do:
if (deprocedure_p
&& (TYPE_CODE (SYMBOL_TYPE (exp->elts[pc + 2].symbol))
== TYPE_CODE_FUNC))
{
replace_operator_with_call (expp, pc, 0, 0,
exp->elts[pc + 2].symbol,
exp->elts[pc + 1].block);
exp = expp->get ();
}
The problem is that we're passing OPLEN (zero -- 4th parameter in
the call), and so replace_operator_with_call ends up removing zero
element from our expression, and inserting the corresponding OP_FUNCALL
instead. As a result, instead of having the OP_LONG (1) as the second
argument of the BINOP_ADD, it is now the OP_VAR_VALUE that we were
meant to replace. That OP_VAR_VALUE then itself gets transformed into
an OP_FUNCALL, with the same issue, and eventually, the resolved
expression now looks like this:
0 BINOP_ADD
1 OP_FUNCALL Number of args: 0
4 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
8 OP_FUNCALL Number of args: 0
11 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
15 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
19 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
This explains why we get twice the result of the function call
instead of its value plus one. The extra entries in the expression
at the end are just ignored.
This patch fixes the issue by calling replace_operator_with_call
with the correct OPLEN equal to the size of an OP_VAR_VALUE (4).
gdb/ChangeLog:
* ada-lang.c (resolve_subexp): Pass correct OPLEN in call to
replace_operator_with_call.
gdb/testsuite/ChangeLog:
* gdb.ada/expr_with_funcall: New testcase.
|
||
|
Joel Brobecker
|
2a62dfa93f |
(Ada) assigning packed array aggregate with variable as component
Consider a variable "PRA" defined as a packed array of packed
records as follow:
subtype Int is Integer range 0 .. 7;
type Packed_Rec is record
X, Y : Int;
W : Integer;
end record;
pragma Pack (Packed_Rec);
type Packed_RecArr is array (Integer range <>) of Packed_Rec;
pragma Pack (Packed_RecArr);
PRA : Packed_RecArr (1 .. 3);
Consider also a variable "PR", which is a Packed_Rec record,
declared as follow:
PR : Packed_Rec := (2, 2, 2);
Trying to assign a new value to PRA using an aggregate expression
where one of the components is our variable PR yields the wrong
result on big-endian machines (e.g. on ppc-linux):
(gdb) p pra := (pr, (2,2,2), (2,2,2))
$6 = ((x => 1, y => 0, w => 8), [...]
On the other hand, replacing "pr" by "(2,2,2)" does work.
I tracked the issue down to the bit offset we use to extract
the value of "PR" and copy it inside PRA. in value_assign_to_component,
we have:
if (gdbarch_bits_big_endian (get_type_arch (value_type (container))))
move_bits ([target buffer], [bit offset in target buffer],
[source buffer where PR is stored],
TYPE_LENGTH (value_type (component)) * TARGET_CHAR_BIT - bits,
bits, 1);
The issue is with the third-to-last argument, which provides the bit
offset where the value of PR is stored relative to its start address,
and therefore the bit offset relative to the start of the source
buffer passed as the previous argument.
In our case, component is a 38bit packed record whose TYPE_LENGTH
is 5 bytes, so the bit-offset that gets calculated is 2 (bits).
However, that formula only really applies to scalars, whereas
in our case, we have a record (struct). The offset in the non-scalar
case should be zero.
gdb/ChangeLog:
* ada-lang.c (value_assign_to_component): In the case of
big-endian targets, extract the bits of the given VAL
using an src_offset of zero if container is not a scalar.
gdb/testsuite/ChangeLog:
* gdb.ada/packed_array_assign: New testcase.
|
||
|
Tom de Vries
|
0fe3a55830 |
[gdb/testsuite/ada] Fix number-of-bp test in bp_inlined_func.exp
At the moment, bp_inlined_func.exp passes for a combined current gcc and
gdb-binutils repos build but fails for a build with system gcc (7.3.1) and
ld (2.29.1).
It checks for 4 breakpoints on read_small:
...
gdb_test "break read_small" \
"Breakpoint $decimal at $hex: read_small\\. \\(4 locations\\)" \
"set breakpoint at read_small"
...
and fails because it gets 5 breakpoint locations instead:
...
(gdb) break read_small
Breakpoint 2 at 0x401f9a: read_small. (5 locations)
(gdb) FAIL: gdb.ada/bp_inlined_func.exp: set breakpoint at read_small
...
The 4 expected breakpoint locations are inlined versions of read_small, and
the 5th breakpoint location has this address:
...
(gdb) info breakpoint
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000401f9a in b.read_small
at bp_inlined_func/b.adb:20
...
which is the read_small function itself:
...
(gdb) x 0x0000000000401f9a
0x401f9a <b__read_small+4>: 0x22f8058b
...
This patch updates the test to allow 5 breakpoint locations.
Tested on the configurations mentioned above, on x86_64.
2018-06-18 Tom de Vries <tdevries@suse.de>
* gdb.ada/bp_inlined_func.exp: Allow 5 breakpoint locations.
|
||
|
Joel Brobecker
|
8e81706197 |
inadvertent language switch during breakpoint_re_set_one
Trying to insert a breakpoint using *FUNC'address with an Ada program
and then running the program until reaching that breakpoint currently
yields the following behavior:
(gdb) break *a'address
Breakpoint 1 at 0x40240c: file a.adb, line 1.
(gdb) run
[1] + 27222 suspended (tty output) /[...]/gdb -q simple_main
Unsuspending GDB then shows it was suspended trying to report
the following error:
Starting program: /home/takamaka.a/brobecke/ex/simple/a
Error in re-setting breakpoint 1: Unmatched single quote.
Error in re-setting breakpoint 1: Unmatched single quote.
Error in re-setting breakpoint 1: Unmatched single quote.
[Inferior 1 (process 32470) exited normally]
The "a'address" is Ada speak for function A's address ("A" by
itself means the result of calling A with no arguments). The
transcript above shows that we're having problems trying to
parse the breakpoint location while re-setting it. As a result,
we also fail to stop at the breakpoint.
Normally, breakpoint locations are evaluated with the current_language
being set to the language of the breakpoint. But, unfortunately for us,
what happened in this case is that parse_exp_in_context_1 calls
get_selected_block which eventually leads to a call to select_frame
because the current_frame hadn't been set yet. select_frame then
finds that our language_mode is auto, and therefore changes the
current_language to match the language of the frame we just selected.
In our case, the language chosen was 'c', which of course is not
able to parse an Ada expression, hence the error.
This patch prevents this by forcing the language_mode to manual
before we call breakpoint_re_set_one.
gdb/ChangeLog:
* breakpoint.c (breakpoint_re_set): Temporarily force language_mode
to language_mode_manual while calling breakpoint_re_set_one.
gdb/testsuite/ChangeLog:
* gdb.ada/bp_fun_addr: New testcase.
Tested on x86_64-linux.
|
||
Keith Seitz
|
ddfe970e6b |
Don't elide all inlined frames
This patch essentially causes GDB to treat inlined frames like "normal"
frames from the user's perspective. This means, for example, that when a
user sets a breakpoint in an inlined function, GDB will now actually stop
"in" that function.
Using the test case from breakpoints/17534,
3 static inline void NVIC_EnableIRQ(int IRQn)
4 {
5 volatile int y;
6 y = IRQn;
7 }
8
9 __attribute__( ( always_inline ) ) static inline void __WFI(void)
10 {
11 __asm volatile ("nop");
12 }
13
14 int main(void) {
15
16 x= 42;
17
18 if (x)
19 NVIC_EnableIRQ(16);
20 else
21 NVIC_EnableIRQ(18);
(gdb) b NVIC_EnableIRQ
Breakpoint 1 at 0x4003e4: NVIC_EnableIRQ. (2 locations)
(gdb) r
Starting program: 17534
Breakpoint 1, main () at 17534.c:19
19 NVIC_EnableIRQ(16);
Because skip_inline_frames currently skips every inlined frame, GDB "stops"
in the caller. This patch adds a new parameter to skip_inline_frames
that allows us to pass in a bpstat stop chain. The breakpoint locations
on the stop chain can be used to determine if we've stopped inside an inline
function (due to a user breakpoint). If we have, we do not elide the frame.
With this patch, GDB now reports that the inferior has stopped inside the
inlined function:
(gdb) r
Starting program: 17534
Breakpoint 1, NVIC_EnableIRQ (IRQn=16) at 17534.c:6
6 y = IRQn;
Many thanks to Jan and Pedro for guidance on this.
gdb/ChangeLog:
* breakpoint.c (build_bpstat_chain): New function, moved from
bpstat_stop_status.
(bpstat_stop_status): Add optional parameter, `stop_chain'.
If no stop chain is passed, call build_bpstat_chain to build it.
* breakpoint.h (build_bpstat_chain): Declare.
(bpstat_stop_status): Move documentation here from breakpoint.c.
* infrun.c (handle_signal_stop): Before eliding inlined frames,
build the stop chain and pass it to skip_inline_frames.
Pass this stop chain to bpstat_stop_status.
* inline-frame.c: Include breakpoint.h.
(stopped_by_user_bp_inline_frame): New function.
(skip_inline_frames): Add parameter `stop_chain'.
Move documention to inline-frame.h.
If non-NULL, use stopped_by_user_bp_inline_frame to determine
whether the frame should be elided.
* inline-frame.h (skip_inline_frames): Add parameter `stop_chain'.
Add moved documentation and update for new parameter.
gdb/testsuite/ChangeLog:
* gdb.ada/bp_inlined_func.exp: Update inlined frame locations
in expected breakpoint stop locations.
* gdb.dwarf2/implptr.exp (implptr_test_baz): Use up/down to
move to proper scope to test variable values.
* gdb.opt/inline-break.c (inline_func1, not_inline_func1)
(inline_func2, not_inline_func2, inline_func3, not_inline_func3):
New functions.
(main): Call not_inline_func3.
* gdb.opt/inline-break.exp: Start inferior and set breakpoints at
inline_func1, inline_func2, and inline_func3. Test that when each
breakpoint is hit, GDB properly reports both the stop location
and the backtrace. Repeat tests for temporary breakpoints.
|
||
Andreas Arnez
|
b744723f57 |
Show line numbers in output for "info var/func/type"
The GDB commands "info variables", "info functions", and "info types" show the appropriate list of definitions matching the given pattern. They also group them by source files. But no line numbers within these source files are shown. The line number information is particularly useful to the user when a simple "grep" doesn't readily point to a definition. This is often the case when the definition involves a macro, occurs within a namespace, or when the identifier appears very frequently in the source file. This patch enriches the printout of these commands by the line numbers and adjusts affected test cases to the changed output where necessary. The new output looks like this: (gdb) i variables All defined variables: File foo.c: 3: const char * const foo; 1: int x; The line number is followed by a colon and a tab character, which is then followed by the symbol definition. If no line number is available, the tab is printed out anyhow, so definitions line up. gdb/ChangeLog: * symtab.c (print_symbol_info): Precede the symbol definition by the line number when available. * NEWS: Advertise this enhancement. gdb/doc/ChangeLog: * gdb.texinfo (Symbols): Mention the fact that "info variables/functions/types" show source files and line numbers. gdb/testsuite/ChangeLog: * gdb.ada/info_types.exp: Adjust expected output to the line numbers now printed by "info var/func/type". * gdb.base/completion.exp: Likewise. * gdb.base/included.exp: Likewise. * gdb.cp/cp-relocate.exp: Likewise. * gdb.cp/cplusfuncs.exp: Likewise. * gdb.cp/namespace.exp: Likewise. * gdb.dwarf2/dw2-case-insensitive.exp: Likewise. |
||
|
Joel Brobecker
|
3fcded8f30 |
set varsize-limit: New GDB setting for maximum dynamic object size
This is a command we somehow forgot to contribute at the time the Ada
language was first contributed to the FSF. This command allows
the user to change the maximum size we allow when reading memory
from dynamic objects (the default is 65536 bytes).
At the moment, this limit is only used by Ada, and so the implementation
is kept inside ada-lang.c. However, it is conceivable that other language
might want to use it also to handle the same kind of issues; for instance,
this might be useful when handling dynamic types in C. So the name
of the setting was made language-neutral, to allow for this.
Note that an alias for "set var" needs to be introduced as well.
We are not adding a test for that, since this is a feature that is
already exercized by numerous existing tests.
gdb/ChangeLog
* NEWS: Add entry describing new "set|show varsize-limit" command.
* ada-lang.c (_initialize_ada_language): Add "set/show varsize-limit"
command.
* printcmd.c (_initialize_printcmd): Add "set var" alias of
"set variable".
gdb/doc/ChangeLog:
* gdb.texinfo (Ada Settings): New subsubsection.
gdb/testsuite/ChangeLog:
* gdb.ada/varsize_limit: New testcase.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
59cc4834e5 |
problem looking up some symbols when they have a linkage name
This patch fixes a known failure in gdb.ada/maint_with_ada.exp
(maintenance check-psymtabs). Another way to witness the same
issue is by considering the following Ada declarations...
type Wrapper is record
A : Integer;
end record;
u00045 : constant Wrapper := (A => 16#060287af#);
pragma Export (C, u00045, "symada__cS");
... which declares a variable name "u00045" but with a linkage
name which is "symada__cS". This variable is a record with one
component, the Ada equivalent of a struct with one field in C.
Trying to print that variable's value currently yields:
(gdb) p /x <symada__cS>
'symada(char, signed)' has unknown type; cast it to its declared type
This indicates that GDB was only able to find the minimal symbol,
but not the full symbol. The expected output is:
(gdb) print /x <symada__cS>
$1 = (a => 0x60287af)
The error message gives a hint about what's happening: We processed
the symbol through gdb_demangle, which in the case of this particular
symbol name, ends up matching the C++ naming scheme. As a result,
the demangler transforms our symbol name into 'symada(char, signed)',
thus breaking Ada lookups.
This patch fixes the issue by first introducing a new language_defn
attribute called la_store_sym_names_in_linkage_form_p, which is a boolean
to be set to true for the few languages that do not want their symbols
to have their names stored in demangled form, and false otherwise.
We then use this language attribute to skip the call to gdb_demangle
for all languages whose la_store_sym_names_in_linkage_form_p is true.
In terms of the selection of languages for which the new attribute
is set to true, the selection errs on the side of preserving the
existing behavior, and only changes the behavior for the languages
where we are certain storing symbol names in demangling form is not
needed. It is conceivable that other languages might be in the same
situation, but I not knowing in detail the symbol name enconding
strategy, I decided to play it safe and let other language maintainers
potentially adjust their language if it makes sense to do so.
gdb/ChangeLog:
PR gdb/22670
* dwarf2read.c (dwarf2_physname): Do not return the demangled
symbol name if the CU's language stores symbol names in linkage
format.
* language.h (struct language_defn)
<la_store_sym_names_in_linkage_form_p>: New field. Adjust
all instances of this struct.
gdb/testsuite/ChangeLog:
* gdb.ada/maint_with_ada.exp: Remove PR gdb/22670 setup_kfail.
* gdb.ada/notcplusplus: New testcase.
* gdb.base/c-linkage-name.c: New file.
* gdb.base/c-linkage-name.exp: New testcase.
Tested on x86_64-linux.
This also passes AdaCore's internal GDB testsuite.
|
||
|
Andreas Arnez
|
079670b94a |
Testsuite: fully migrate to use_gdb_stub convenience func
In the GDB test suite, there are still multiple invocations of "target_info exists use_gdb_stub". However, the recommended way of checking for use_gdb_stub is to call the convenience function of the same name. Replace these occurrences and just call "use_gdb_stub" instead. gdb/testsuite/ChangeLog: * gdb.ada/exec_changed.exp: Replace "target_info exists use_gdb_stub" by "use_gdb_stub". * gdb.ada/start.exp: Likewise. * gdb.base/async-shell.exp: Likewise. * gdb.base/attach-pie-misread.exp: Likewise. * gdb.base/attach-wait-input.exp: Likewise. * gdb.base/break-entry.exp: Likewise. * gdb.base/break-interp.exp: Likewise. * gdb.base/dprintf-detach.exp: Likewise. * gdb.base/nostdlib.exp: Likewise. * gdb.base/solib-nodir.exp: Likewise. * gdb.base/statistics.exp: Likewise. * gdb.base/testenv.exp: Likewise. * gdb.mi/mi-exec-run.exp: Likewise. * gdb.mi/mi-start.exp: Likewise. * gdb.multi/dummy-frame-restore.exp: Likewise. * gdb.multi/multi-arch-exec.exp: Likewise. * gdb.multi/multi-arch.exp: Likewise. * gdb.multi/tids.exp: Likewise. * gdb.multi/watchpoint-multi.exp: Likewise. * gdb.python/py-events.exp: Likewise. * gdb.threads/attach-into-signal.exp: Likewise. * gdb.threads/attach-stopped.exp: Likewise. * gdb.threads/threadapply.exp: Likewise. * lib/selftest-support.exp: Likewise. |
||
|
Xavier Roirand
|
bea298f954 |
(Ada) Add gdb-mi support for stopping at start of exception handler.
Following my previous commit which add support for stopping at start of
exception handler, this commit adds required gdb-mi support for this
feature.
gdb/ChangeLog:
* mi/mi-cmd-catch.c (mi_cmd_catch_handlers): New function.
* mi/mi-cmds.c (mi_cmds): Add catch-handlers command.
* mi/mi-cmds.h (mi_cmd_catch_handlers): Add external declaration.
* NEWS: Document "-catch-handlers" command.
gdb/doc/ChangeLog:
* gdb.texinfo (Ada Exception gdb/mi Catchpoints): Add
documentation for new "-catch-handlers" command.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_catch_ex_hand.exp: New testcase.
* gdb.ada/mi_catch_ex_hand/foo.adb: New file.
Tested on x86_64-linux.
|
||
|
Xavier Roirand
|
4fa955b25e |
(Ada/MI) Add testcase for mi catch assert with condition
gdb/testsuite/ChangeLog:
* gdb.ada/mi_catch_assert.exp: New testcase.
* gdb.ada/mi_catch_assert/bla.adb: New file.
* gdb.ada/mi_catch_assert/pck.ads: New file.
Tested on x86_64-linux.
|
||
|
Xavier Roirand
|
395507f62b |
(Ada) Add testcase for catch assert with condition
gdb/testsuite/ChangeLog:
* gdb.ada/catch_assert_if.exp: New testcase.
* gdb.ada/catch_assert_if/bla.adb: New file.
* gdb.ada/catch_assert_if/pck.ads: New file.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
929b5ad40f |
internal-error using '@' (repeat) operator on array of dynamic objects
Using the following Ada declarations (the same as in
gdb.ada/dyn_stride.exp)...
subtype Small_Type is Integer range L .. U;
type Record_Type (I : Small_Type := L) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type :=
(1 => (I => U, S => (others => ASCII.NUL)),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
... where "L" and "U" are variables, trying to apply the repeat
operator to "A1(1)" yields to an internal error:
| (gdb) print a1(1)@3
| $5 = /[...]/gdbtypes.c:4883: internal-error: type* copy_type(const type*):
| Assertion `TYPE_OBJFILE_OWNED (type)' failed.
What happens first is that the ada-lang module evaluated the "A1(1)"
sub-expression returning a structure where "I" (one of the fields
in that structure) has a type which is dynamic, because it is
a range type whose bounds are not statically known.
Next, we apply the repeat ('@') operator, which is done via
allocate_repeat_value, which creates an array type with the correct
bounds to associate to our value, by calling lookup_array_range_type:
| struct type *
| lookup_array_range_type (struct type *element_type,
| LONGEST low_bound, LONGEST high_bound)
| {
| struct gdbarch *gdbarch = get_type_arch (element_type);
| struct type *index_type = builtin_type (gdbarch)->builtin_int;
| struct type *range_type
| = create_static_range_type (NULL, index_type, low_bound, high_bound);
|
| return create_array_type (NULL, element_type, range_type);
| }
As we can see, this creates an array type whose index type is
always owned by the gdbarch. This is where the problem lies.
Next, we use that type to construct a struct value. That value
then gets passed to the valprint module, which then checks
whether our object is dynamic or not. And because field "I" above
had a dynamic range type, we end up determining by association
that the artificial repeat array itself is also dynamic. So
we attempt to resolve the type, which leads to trying to copying
that type. And because the artifical array created by
lookup_array_range_type has an index which is not objfile-owned,
we trip the assertion.
This patch fixes the issue by enhancing lookup_array_range_type
to create an index type which has the same owner as the element
type.
gdb/ChangeLog:
* gdbtypes.c (lookup_array_range_type): Make sure the array's
index type is objfile-owned if the element type is as well.
gdb/testsuite/ChangeLog:
* testsuite/gdb.ada/dyn_stride.exp: Add "print a1(1)@3" test.
|
||
Pedro Alves
|
c63d3e8d12 |
Ada: make verbatim matcher override other language matchers (PR gdb/22670)
A previous patch fixed verbatim matching in the lookup at the minimal
symbol level, but we should also be finding that same symbol through
the partial/full symtab search.
For example, this is what happens if we use "print" instead of
"break":
(gdb) p <MixedCaseFunc>
$1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc>
Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a
function without parameters, and the expression above means calling
it. If you try it before having started the inferior, you'd get the
following (expected) error:
(gdb) print <MixedCaseFunc>
You can't do that without a process to debug.
The main idea behind making the name matcher be determined by the
symbol's language is so that C++ (etc.) wildmatching in linespecs
works even if the current language is not C++, as e.g., when you step
through C or assembly code.
Ada's verbatim matching syntax however ("<...>") isn't quite the same.
It is more a property of the current language than of a particular
symbol's language. We want to support this syntax when debugging an
Ada program, but it's reason of existence is to find non-Ada symbols.
This suggests going back to enabling it depending on current language
instead of language of the symbol being matched.
I'm not entirely happy with the "current_language" reference (though I
think that it's harmless). I think we could try storing the current
language in the lookup_name_info object, and then convert a bunch of
functions more to pass around lookup_name_info objects instead of
"const char *" names. I.e., build the lookup_name_info higher up.
I'm not sure about that, I'll have to think more about it. Maybe
something different will be better. Meanwhile, this gets us going.
I've extended the testcase to also exercise a no-debug-info function,
for extra coverage of the minsyms-only paths.
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* dwarf2read.c
(gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher):
Adjust to use language_get_symbol_name_matcher instead of
language_defn::la_get_symbol_name_matcher.
* language.c (language_get_symbol_name_matcher): If in Ada mode
and the lookup name is a verbatim match, return Ada's matcher.
* language.h (language_get_symbol_name_matcher): Adjust comment.
(ada_lookup_name_info::verbatim_p):: New method.
gdb/testsuite/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/bp_c_mixed_case.exp: Add intro comment. Test printing C
functions too. Test setting breakpoints and printing C functions
with no debug info too.
* gdb.ada/bp_c_mixed_case/qux.c: New file.
|
||
|
Pedro Alves
|
d4c2a405cb |
Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670)
This patch fixes the regression covered by the test added by:
commit
|
||
|
Pedro Alves
|
8825213e97 |
Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670)
The problem here is that we are using the user-provided lookup name literally for name comparisons. I.e., "<MixedCase>" with the "<>"s included. This commit fixes the minsym lookup case. psymbol/symbol lookup will be fixed in a follow up. In the minsym case, we're using using the user-provided lookup name literally for linkage name comparisons. That obviously can't work since the "<>" are not really part of the linkage name. The original idea was that we'd use the symbol's language to select the right symbol name matching algorithm, but that doesn't work for Ada because it's not really possible to unambiguously tell from the linkage name alone whether we're dealing with Ada symbols, so Ada minsyms end up with no language set, or sometimes C++ set. So fix this by treating Ada mode specially when determining the linkage name to match against. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * minsyms.c (linkage_name_str): New function. (iterate_over_minimal_symbols): Use it. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls. |
||
|
Xavier Roirand
|
b1dc1806fa |
Fix breakpoint add on inlined function using function name.
Using this Ada example:
package B is
procedure Read_Small with Inline_Always;
end B;
package body B is
Total : Natural := 0;
procedure Read_Small is
begin
Total := Total + 1;
end Read_Small;
end B;
and
with B;
procedure M is
begin
B.Read_Small;
end M;
% gnatmake -g -O0 -m m.adb -cargs -gnatn
% gdb m
Inserting a breakpoint on Read_Small inlined function does not work:
(gdb) b read_small
Breakpoint 1 at 0x40250e: file b.adb, line 5.
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000040250e in b.doit at b.adb:5
(gdb)
In this exemple we should have two breakpoints set, one in package B and
the other one in the inlined instance inside procedure M), like below:
(gdb) b read_small
Breakpoint 1 at 0x40250e: b.adb:5. (2 locations)
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x000000000040250e in b.doit at b.adb:5
1.2 y 0x0000000000402540 in m at b.adb:5
(gdb)
Looking at the DWARF info for inlined instance of Read_Small:
<1><1526>: Abbrev Number: 2 (DW_TAG_subprogram)
<1527> DW_AT_name : ([...], offset: 0x1e82): b__read_small
<152b> DW_AT_decl_file : 2
<152c> DW_AT_decl_line : 3
<152d> DW_AT_inline : 3 (declared as inline and inlined)
[...]
<2><1547>: Abbrev Number: 4 (DW_TAG_inlined_subroutine)
<1548> DW_AT_abstract_origin: <0x1526>
<154c> DW_AT_low_pc : 0x402552
<1554> DW_AT_high_pc : 0x2b
<155c> DW_AT_call_file : 1
<155d> DW_AT_call_line : 5
<2><155e>: Abbrev Number: 0
During the parsing of DWARF info in order to produce partial DIE linked
list, the DW_TAG_inlined_subroutine were skipped thus not present in the
final partial dies.
Taking DW_TAG_inlined_subroutine in account during the parsing process
fixes the problem.
gdb/ChangeLog:
* dwarf2read.c (scan_partial_symbols, add_partial_symbol)
(add_partial_subprogram, load_partial_dies): Add
DW_TAG_inlined_subroutine handling.
gdb/testsuite/ChangeLog:
* gdb.ada/bp_inlined_func: New testcase.
|
||
|
Joel Brobecker
|
30066b0b00 |
Relax expected output in gdb.ada/access_tagged_param.exp test
One of the tests in gdb.ada/access_tagged_param.exp verifies
the value of the parameters being printed by GDB when stopping
at a breakpoint inside procedure Pck.Inspect.
In particular, one of these parameters is actually generated
internally by the compiler, and does only indirectly depend
on the user-level code. A recent change in AdaCore's compiler
caused the code expansion to change a little bit, and as a result,
the value of that parameter has changed from 2 to 3. This can be
evindenced by looking at the code post expansion, using the -gnatDG
command-line switch to generate the .dg files:
$ gnatmake -g -gnatDG foo.adb
$ vi foo.adb.dg
We can see that the call to pck.inspect used to be:
pck__inspect (P8b, objL => 2);
With a recent version of GNAT Pro, it is now:
pck__inspect (P9b, objL => 3);
This change causes a spurious FAIL when running this testcase.
The objL parameter being, at heart, a simple counter of the nesting
level, this commit relaxes the expected output to accept any single-
digit number. We could accept any decimal, but given the example
program, I dout that number will reach double-digit level. If it
does, we'll double-check that this is normal, and relax the expected
output further.
gdb/testsuite/ChangeLog:
* gdb.ada/access_tagged_param.exp: Relax expected output
for value of "ObjL" in "continue" to pck.inspect breakpoint
test.
Tested on x86_64-linux.
|
||
|
Xavier Roirand
|
04bafb1ed0 |
(Ada) Fix print of array using non-contiguous enumeration indexes
Consider the following code:
type Index is (Index1, Index2);
Size : constant Integer := 10;
for Index use (Index1 => 1, Index2 => Size);
type Array_Index_Enum is array (Index) of Integer;
my_table : Array_Index_Enum :=(others => 42);
When compiling the code above with a compiler where the GNAT encodings
are turned off (which can be temporarily emulated by using the compiler
switch -fgnat-encodings=minimal), printing this table in gdb leads to:
(gdb) p my_table
$1 = (42, 42, 4203344, 10, -8320, 32767, 4203465, 0, 0, 0)
The displayed content is wrong since the handling part believes
that the length of the array is max index value (10) minus the
first index value (1) i+ 1 = 10 which is wrong since index are not
contiguous in this case.
The right behavior is to detect that the array is using enumeration
index hence parse the enumeration values in order to get the number
of indexes in this array (2 indexes here).
This patch fixes this issue and changes the output as follow:
(gdb) p my_table
$1 = (42, 42)
gdb/ChangeLog:
* ada-valprint.c (val_print_packed_array_elements): Use
proper number of elements when printing an array indexed
by an enumeration type.
gdb/testsuite/ChangeLog (Joel Brobecker <brobecker@adacore.com>):
* gdb.ada/arr_enum_idx_w_gap.exp
* gdb.ada/arr_enum_idx_w_gap/foo_q418_043.adb
Tested on x86_64-linux.
|
||
|
Pedro Alves
|
de63c46b54 |
Fix regresssion(internal-error) printing subprogram argument (PR gdb/22670)
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00298.html>, Joel wrote: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider the following code which first declares a tagged type (the equivalent of a class in Ada), and then a procedure which takes a pointer (access) to this type's 'Class. package Pck is type Top_T is tagged record N : Integer := 1; end record; procedure Inspect (Obj: access Top_T'Class); end Pck; Putting a breakpoint in that procedure and then running to it triggers an internal error: (gdb) break inspect (gdb) continue Breakpoint 1, pck.inspect (obj=0x63e010 /[...]/gdb/stack.c:621: internal-error: void print_frame_args(symbol*, frame_info*, int, ui_file*): Assertion `nsym != NULL' failed. What's special about this subprogram is that it takes an access to what we call a 'Class type, and for implementation reasons, the compiler adds an extra argument named "objL". If you are curious why, it allows the compiler for perform dynamic accessibility checks that are mandated by the language. If we look at the location where we get the internal error (in stack.c), we find that we are looping over the symbol of each parameter, and for each parameter, we do: /* We have to look up the symbol because arguments can have two entries (one a parameter, one a local) and the one we want is the local, which lookup_symbol will find for us. [...] nsym = lookup_symbol (SYMBOL_LINKAGE_NAME (sym), b, VAR_DOMAIN, NULL).symbol; gdb_assert (nsym != NULL); The lookup_symbol goes through the lookup structure, which means the symbol's linkage name ("objL") gets transformed into a lookup_name_info object (in block_lookup_symbol), before it gets fed to the block symbol dictionary iterators. This, in turn, triggers the symbol matching by comparing the "lookup" name which, for Ada, means among other things, lowercasing the given name to "objl". It is this transformation that causes the lookup find no matches, and therefore trip this assertion. Going back to the "offending" call to lookup_symbol in stack.c, what we are trying to do, here, is do a lookup by linkage name. So, I think what we mean to be doing is a completely literal symbol lookup, so maybe not even strcmp_iw, but actually just plain strcmp??? In the past, in practice, you could get that effect by doing a lookup using the C language. But that doesn't work, because we still end up somehow using Ada's lookup_name routine which transforms "objL". So, ideally, as I hinted before, I think what we need is a way to perform a literal lookup so that searches by linkage names like the above can be performed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This commit fixes the problem by implementing something similar to Joel's literal idea, but with some important differences. I considered adding a symbol_name_match_type::LINKAGE and supporting searching by linkage name for any language, but the problem with that is that the dictionaries only work with SYMBOL_SEARCH_NAME, because that's what is used for hashing. We'd need separate dictionaries for hashed linkage names. So with the current symbol tables infrastructure, it's not literal linkage names that we want to pass down, but instead literal _search_ names (SYMBOL_SEARCH_NAME, etc.). However, psymbols have no overload/function parameter info in C++, so a straight strcmp doesn't work properly for C++ name matching. So what we do is be a little less aggressive then and add a new symbol_name_match_type::SEARCH_SYMBOL instead that takes as input a non-user-input search symbol, and then we skip any decoding/demangling steps and make: - Ada treat that as a verbatim match, - other languages treat it as symbol_name_match_type::FULL. This also fixes the new '"maint check-psymtabs" for Ada' testcase for me (gdb.ada/maint_with_ada.exp). I've not removed the kfail yet because Joel still sees that testcase failing with this patch. That'll be fixed in follow up patches. gdb/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/22670 * ada-lang.c (literal_symbol_name_matcher): New function. (ada_get_symbol_name_matcher): Use it for symbol_name_match_type::SEARCH_NAME. * block.c (block_lookup_symbol): New parameter 'match_type'. Pass it down instead of assuming symbol_name_match_type::FULL. * block.h (block_lookup_symbol): New parameter 'match_type'. * c-valprint.c (print_unpacked_pointer): Use lookup_symbol_search_name instead of lookup_symbol. * compile/compile-object-load.c (get_out_value_type): Pass down symbol_name_match_type::SEARCH_NAME. * cp-namespace.c (cp_basic_lookup_symbol): Pass down symbol_name_match_type::FULL. * cp-support.c (cp_get_symbol_name_matcher): Handle symbol_name_match_type::SEARCH_NAME. * infrun.c (insert_exception_resume_breakpoint): Use lookup_symbol_search_name. * p-valprint.c (pascal_val_print): Use lookup_symbol_search_name. * psymtab.c (maintenance_check_psymtabs): Use symbol_name_match_type::SEARCH_NAME and SYMBOL_SEARCH_NAME. * stack.c (print_frame_args): Use lookup_symbol_search_name and SYMBOL_SEARCH_NAME. * symtab.c (lookup_local_symbol): Don't demangle the lookup name if symbol_name_match_type::SEARCH_NAME. (lookup_symbol_in_language): Pass down symbol_name_match_type::FULL. (lookup_symbol_search_name): New. (lookup_language_this): Pass down symbol_name_match_type::SEARCH_NAME. (lookup_symbol_aux, lookup_local_symbol): New parameter 'match_type'. Pass it down. * symtab.h (symbol_name_match_type::SEARCH_NAME): New enumerator. (lookup_symbol_search_name): New declaration. (lookup_symbol_in_block): New 'match_type' parameter. gdb/testsuite/ChangeLog: 2018-01-05 Joel Brobecker <brobecker@adacore.com> PR gdb/22670 * gdb.ada/access_tagged_param.exp: New file. * gdb.ada/access_tagged_param/foo.adb: New file. |
||
|
Pedro Alves
|
f98fc17b3a |
Fix gdb.ada/info_addr_mixed_case.exp (PR gdb/22670)
The comments about mixed case in the testcase are actually a red herring. The problem here is that we'd get to ada_lookup_encoded_symbol with "my_table", which wraps the looked up name in "<>"s to force a verbatim match, and that in turn disables wild matching. Fix this by swapping around the internals of ada_lookup_encoded_symbol and ada_lookup_symbol, thus avoiding the encoding and verbatim-wrapping in the ada_lookup_symbol case, the case that starts with a user-provided lookup name. Ada encoding is still done of course, in the ada_lookup_name_info ctor. This could be also seen as avoiding the double-encoding problem in a different way. gdb/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/22670 * ada-lang.c (ada_lookup_encoded_symbol): Reimplement in terms of ada_lookup_symbol. (ada_lookup_symbol): Reimplement in terms of ada_lookup_symbol_list, bits factored out from ada_lookup_encoded_symbol. gdb/testsuite/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/info_addr_mixed_case.exp: Remove kfail. Extend test to exercise lower case too, and to exercise both full matching and wild matching. |
||
|
Joel Brobecker
|
342f824039 |
(Ada) problem printing renaming which references a subprogram parameter
Consider the following code, which creates a local variable B
which is a renaming whose expression references a subprogram
parameter:
procedure Flip (Bits : in out Bits_Type; I : Natural) is
begin
declare
B : Boolean renames Bits (I);
begin
B := not B; -- BREAK
end;
end Flip;
Trying to print the value of B when at the "BREAK" line currently
does not work:
(gdb) p b
Could not find i
What happens is the following: For the renaming, GNAT generates
a variable whose name is encoded as follow:
b___XR_bits___XEXSi
GDB properly detects that variable, determines that, to compute
the variable's value, we start from the symbol "Bits", which
we then have to subscript (XS) using 'i' as the index. The error
occurs while trying to find 'i'.
This is because we forgot to pass the block in the call to
ada_lookup_encoded_symbol, which this patch fixes.
gdb/ChangeLog:
* ada-exp.y (write_object_renaming): When subscripting an array
using a symbol as the index, pass the block in call to
ada_lookup_encoded_symbol when looking that symbol up.
gdb/testsuite/ChangeLog:
* gdb.ada/rename_subscript_param: New testcase.
Tested on x86_64-linux.
Note: This requires the following GCC patch:
| 2017-04-25 Pierre-Marie de Rodat <derodat@adacore.com>
|
| * exp_dbug.adb: In Debug_Renaming_Declaration,
| when dealing with indexed component, accept to produce a renaming
| symbol when the index is an IN parameter or when it is a name
| defined in an outer scope.
|
||
|
Jerome Guitton
|
7150d33cda |
(Ada) Fix Length attribute on array access
Consider the following variable "Indexed_By_Enum", declared as
an access to an array whose index type is an enumerated type
whose underlying values have "gaps":
type Enum_With_Gaps is (LIT0, LIT1, LIT2, LIT3, LIT4);
for Enum_With_Gaps use (LIT0 => 3,
LIT1 => 5,
LIT2 => 8,
LIT3 => 13,
LIT4 => 21);
for Enum_With_Gaps'size use 16;
type MyWord is range 0 .. 16#FFFF# ;
for MyWord'Size use 16;
type AR is array (Enum_With_Gaps range <>) of MyWord;
type AR_Access is access AR;
Indexed_By_Enum : AR_Access :=
new AR'(LIT1 => 1, LIT2 => 43, LIT3 => 42, LIT4 => 41);
Trying to print the length (number of elements) of this array using
the 'Length attribute does not work:
(gdb) print indexed_by_enum'length
'POS only defined on discrete types
The problem occurs while trying to get the array's index type.
It was using TYPE_INDEX_TYPE for that. It does not work for Ada arrays
in general; use ada_index_type instead.
gdb/ChangeLog:
* ada-lang.c (ada_array_length): Use ada_index_type instead of
TYPE_INDEX_TYPE.
gdb/testsuite/ChangeLog:
* gdb.ada/arr_acc_idx_w_gap: New testcase.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
cc0e770c0d |
memory error printing component of record from convenience variable
Consider the following situation Ada code:
type Kind_T is (One, Two, Three);
type Time_Set_T is array (Kind_T) of Integer;
type T is record
Started : Time_Set_T;
end record;
Null_T : constant T := (Started => (others => 0));
My_Item : Pck.T := Pck.Null_T;
Trying to print the value of My_Item.Started is no problem:
(gdb) p item.started
$1 = (0, 0, 0)
However, if you save My_Item into a convenience variable first,
and then try to print a component of that record, you get
an unexpected memory error, instead of getting the same result.
For instance:
(gdb) set variable $item := item
(gdb) p $item.started
Cannot access memory at address 0x0
The issue occurs when, after we extracted the component from
the convenience variable, we next try to "fix" it (which is
ada-lang speak for resolving the type into a static type).
This is done in ada_to_fixed_value, which delegates to
ada_to_fixed_value_create via:
val = ada_to_fixed_value_create (value_type (val),
value_address (val), val);
And looking at ada_to_fixed_value_create, we see that:
struct type *type = ada_to_fixed_type (type0, 0, address, NULL, 1);
if (type == type0 && val0 != NULL)
return val0;
else
return value_from_contents_and_address (type, 0, address);
The part that interests us, in this case, is the "else" branch,
where we obviously make the implicit assumption that our object
has an address, which is not true, in this case, because we are
actually dealing with a convenience variable.
This patch plugs that hole by adding special handing for situations
where val does not live in memory. In that case, we just create
a not_lval value using val's contents.
gdb/ChangeLog:
* ada-lang.c (ada_to_fixed_value_create): Add handling of
the case where VALUE_LVAL (val0) is not lval_memory.
gdb/testsuite/ChangeLog:
* gdb.ada/convvar_comp: New testcase.
Tested on x86_64-linux.
|
||
|
Xavier Roirand
|
e3861a0313 |
(Ada) Remove printing of array's first index when unneeded
Consider the following code:
type Table is array (Character) of Natural;
My_Table : Table := (others => 4874);
Printing this table in gdb leads to:
(gdb) p my_table
$1 = ('["00"]' => 4874 <repeats 256 times>)
In this case, the index of the first element in this array is also
the first element of the index type (character type). Similar to what
we do we enumeration types, we do not need to print the index of the
first element when printing the array.
This patch fixes this issue and changes the output as follow:
(gdb) p my_table
$1 = (4874 <repeats 256 times>)
gdb/ChangeLog:
* ada-valprint.c (print_optional_low_bound): Handle
character-indexed array printing like boolean-indexed array
printing.
gdb/testuite/ChangeLog:
* testsuite/gdb.ada/array_char_idx/pck.ads (Table): New type.
(My_Table): New global variable.
* testsuite/gdb.ada/array_char_idx.exp: Add test.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
7365ec2ff4 |
gdb.ada/maint_with_ada.exp: New testcase
This commit adds a new testcase testing the "check-psymtabs" and
"check-symtabs" maintenance commands.
The "maintenance check-psymtabs" commands is currently known to
produce some errors. While the situation was admetedly made worse
by the following patch...
commit
|
||
|
Joel Brobecker
|
289483b6a0 |
Add new gdb.ada/bp_c_mixed_case testcase for PR gdb/22670
This patch adds a new testcase to demonstrate a regression introduced by:
commit
|
||
|
Joel Brobecker
|
344420da6b |
Add "complete break ada" test to gdb.ada/complete.exp
This patch adds a new test to demonstrate a regression introduced by:
commit
|
||
|
Joel Brobecker
|
66fc87a0d5 |
Add gdb.ada/info_addr_mixed_case new testcase
This patch adds a new testcase to demonstrate a regression introduced by:
commit
|
||
|
Xavier Roirand
|
9f757bf7fc |
(Ada) New command to stop at start of exception handler.
When using gdb for debugging Ada source code, there are several catchpoint
types you can define in order to stop upon certain conditions. Let's
use this small example:
procedure Foo is
begin
begin
raise Constraint_Error;
exception
when Program_Error =>
null;
when Constraint_Error =>
null;
when others =>
null;
end;
end Foo;
One can stop when the exception is being raised by using the exception
catchpoint like below:
(gdb) catch exception
Catchpoint 1: all Ada exceptions
(gdb)
In that case, when running Foo, gdb will stop at the line where the exception
was raised:
begin
>>> raise Constraint_Error;
exception
This patch introduces new type of catchpoint, when the user wants to stop
at the location of the exception handling.
Imagine we want to stop on any exception handled by the program, we can do:
(gdb) catch handlers
Catchpoint 1: all Ada exceptions handlers
(gdb) r
Starting program: /tmp/foo
By doing so, when running Foo, gdb will stop here:
Catchpoint 1, exception at 0x000000000040255a in foo () at foo.adb:25
25 when Constraint_Error =>
(gdb)
It is also possible to stop when the Constraint_Error exception is being
handled in this program. With this patch, we can use:
(gdb) catch handlers Constraint_Error
Catchpoint 1: `Constraint_Error' Ada exception handlers
(gdb)
Like for other catchpoint, you can set a condition when adding a catchpoint
on exception handlers.
Here the handlers catchpoint checks Global_Var:
(gdb) catch handlers Constraint_Error if Global_Var /= 0
gdb/ChangeLog:
* ada-lang.h (ada_exception_catchpoint_kind) <ada_catch_handlers>:
Add field.
* ada-lang.c (struct exception_support_info) <catch_handlers_sym>:
Add field.
(default_exception_support_info) <catch_handlers_sym>: Add field.
(exception_support_info_fallback) <catch_handlers_sym>: Add field.
(ada_exception_name_addr_1): Add "catch handlers" handling.
(ada_exception_catchpoint_cond_string) <ex>: New parameter.
Update all callers.
(create_excep_cond_exprs) <ex>: Add parameter.
(re_set_exception): Update create_excep_cond_exprs call.
(print_it_exception, print_one_exception, print_mention_exception)
(print_recreate_exception): Add "catch handler" handling.
(allocate_location_catch_handlers, re_set_catch_handlers)
(check_status_catch_handlers, print_it_catch_handlers)
(print_one_catch_handlers, print_mention_catch_handlers)
(print_recreate_catch_handlers): New function.
(catch_handlers_breakpoint_ops): New variable.
(catch_ada_exception_command_split) <is_catch_handlers_cmd>:
Add parameter. Add "catch handler" handling.
(ada_exception_sym_name, ada_exception_breakpoint_ops):
Add "catch handler" handling.
(ada_exception_catchpoint_cond_string): Add "catch handler"
handling.
(create_ada_exception_catchpoint): Update create_excep_cond_exprs
call.
(catch_ada_handlers_command): New function.
(initialize_ada_catchpoint_ops): Initialize "catch handlers"
operations structure.
(_initialize_ada_language): Add "catch handlers" command entry.
* NEWS: Document "catch handlers" feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Set Catchpoints): Add documentation for new
"catch handlers" action.
gdb/testsuite/ChangeLog:
* gdb.ada/excep_handle.exp: New testcase.
* gdb.ada/excep_handle/foo.adb: New file.
* gdb.ada/excep_handle/pck.ads: New file.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
9fe561ab7f |
[gdb/Ada] slices of arrays with dynamic strides
Consider the following Ada code:
procedure Nested (L, U : Integer) is
subtype Small_Type is Integer range L .. U;
type Record_Type (I : Small_Type := L) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type :=
(1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
procedure Discard (R : Record_Type) is
begin
null;
end Discard;
begin
Discard (A1 (1)); -- STOP
end;
Trying to print a slice of that array currently yields:
(gdb) p a1(1..3)
$1 = ((i => 0, s => ""), (i => 0, s => ""), (i => 0, s => ""))
We expected instead:
(gdb) p a1(1..3)
$1 = ((i => 0, s => ""), (i => 1, s => "A"), (i => 2, s => "AB"))
This is because the functions we use in ada-lang.c to create the type
of the array slice (ada_value_slice and ada_value_slice_from_ptr) was
not taking into account the stride of the array. This patch fixes this.
gdb/ChangeLog:
* ada-lang.c (ada_value_slice_from_ptr): Take array stride into
account when creating the array type of the slice.
(ada_value_slice): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_stride.exp: Add slice test.
Note that, with the current use of ada_value_slice, the enhancement
to handle dynamic array strides seems unnecessary, because I do not
see how an array with a dynamic stride can be referenced by either
by reference or pointer. Since references are coerced to array pointers,
in both cases, the slice is performed by ada_value_slice_from_ptr.
But ada_value_slice is enhanced nonetheless, in the spirit of making
the code more robust, in case we missed something, and also as similar
as possible with its from_ptr counterpart.
tested on x86_64-linux.
|
||
|
Joel Brobecker
|
a405673cc5 |
Add support for dynamic DW_AT_byte_stride.
This patch adds support for DW_AT_byte_stride, using Ada as one
example of where this would be useful. However, the implementation
is language-agnostic.
Consider the following Ada code:
procedure Nested (L, U : Integer) is
subtype Small_Type is Integer range L .. U;
type Record_Type (I : Small_Type := L) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type :=
(1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
procedure Discard (R : Record_Type) is
begin
null;
end Discard;
begin
Discard (A1 (1)); -- STOP
end;
It defines an array A1 of Record_Type, which is a variant record
type whose maximum size actually depends on the value of the
parameters passed when calling Nested. As a result, the stride
of the array A1 cannot be known statically, which leads the compiler
to generate a dynamic DW_AT_byte_stride attribute for our type.
Here is what the debugging info looks like with GNAT:
.uleb128 0x10 # (DIE (0x14e) DW_TAG_array_type)
.long .LASF17 # DW_AT_name: "foo__nested__T18b"
.long 0x141 # DW_AT_byte_stride
.long 0xdc # DW_AT_type
.uleb128 0x11 # (DIE (0x15f) DW_TAG_subrange_type)
.long 0x166 # DW_AT_type
.byte 0x3 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x14e
There DW_AT_byte_stride is a reference to a local (internal)
variable:
.uleb128 0x9 # (DIE (0x141) DW_TAG_variable)
.long .LASF6 # DW_AT_name: "foo__nested__T18b___PAD___XVZ"
This patch enhances GDB to handle this dynamic byte stride attribute
by first adding a new dynamic_prop_node_kind (DYN_PROP_BYTE_STRIDE)
to store the array dynamic stride info (when dynamic). It then enhances
the dynamic type resolver to handle this dynamic property.
Before applying this patch, trying to print the value of some of
A1's elements after having stopped at the "STOP" comment does not
work. For instance:
(gdb) p a1(2)
Cannot access memory at address 0x80000268dec0
With this patch applied, GDB now prints the value of all 3 elements
correctly:
(gdb) print A1(1)
$1 = (i => 0, s => "")
(gdb) print A1(2)
$2 = (i => 1, s => "A")
(gdb) print A1(3)
$3 = (i => 2, s => "AB")
gdb/ChangeLog:
* gdbtypes.h (enum dynamic_prop_node_kind) <DYN_PROP_BYTE_STRIDE>:
New enum value.
(create_array_type_with_stride): Add byte_stride_prop parameter.
* gdbtypes.c (create_array_type_with_stride) <byte_stride_prop>:
New parameter. Update all callers in this file.
(array_type_has_dynamic_stride): New function.
(is_dynamic_type_internal, resolve_dynamic_array): Add handling
of arrays with dynamic byte strides.
* dwarf2read.c (read_array_type): Add support for dynamic
DW_AT_byte_stride attributes.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_stride: New testcase.
Tested on x86_64-linux.
|
||
|
Joel Brobecker
|
e2882c8578 |
Update copyright year range in all GDB files
gdb/ChangeLog:
Update copyright year range in all GDB files
|