aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.ada
AgeCommit message (Collapse)AuthorFilesLines
28 hoursFix regexp quoting in gdb.ada test casesTom Tromey14-43/+43
I noticed that some gdb.ada tests used regular expressions like: "Continuing\..*$inferior_exited_re.*" \ Here, the "\." should either be "." or "\\." -- "\." is not really meaningful. This patch fixes all the cases of this I could find in gdb.ada. In one test (fun_renaming.exp), using "\\." would result in failures, and here I rewrote the tests to use -wrap. Approved-By: Andrew Burgess <aburgess@redhat.com>
12 daysEnsure gdb.ada/multiarray.exp runs in both modesTom Tromey1-1/+2
gdb.ada/multiarray.exp has a loop that looks like it should run the test in both 'all' and 'minimal' encodings mode. However, the body of the loop doesn't actually use the 'flags' variable. This was an oversight in the original commit.
2024-07-30[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp some moreTom de Vries1-1/+2
When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie), I run into: ... Expecting: ^(-var-create A_String_Access \* A_String_Access[ ]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[ ]+[(]gdb[)] [ ]*) -var-create A_String_Access * A_String_Access ^error,msg="Cannot access memory at address 0x4" (gdb) FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output) ... This is similar to the problem fixed by commit c5a72a8d1c3 ("[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp"). The problem in both cases is that we're printing an uninitialized variable, and consequently we can run into various error messages during printing. Fix this as in the other commit, by accepting the error message. Tested on arm-linux.
2024-07-23[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp on arm-linuxTom de Vries1-3/+4
On arm-linux, I run into: ... PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me Expecting: ^(-stack-list-arguments 1[^M ]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|<optimized out>)"})?\]},.*[^M ]+[(]gdb[)] ^M [ ]*) -stack-list-arguments 1^M ^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M (gdb) ^M FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) ... The problem is that the test-case expects a level 3 frame, but there is none. This can be reproduced using cli bt: ... $ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \ -ex "b task_switch.break_me" \ -ex run \ -ex bt Breakpoint 1 at 0x34b4: file task_switch.adb, line 57. Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \ at task_switch.adb:57 57 null; #0 task_switch.break_me () at task_switch.adb:57 #1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51 #2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) ... The purpose of the test-case is printing the frame at level 1, so I don't think we should bother about the presence of the frame at level 3. Fix this by allowing the backtrace to stop at level 2. Tested on arm-linux. Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-07-11gdb: add testcase for invalid record displayKévin Le Gouguec2-0/+97
More of a DWARF-generation non-regression test; fixed on the GCC side with 2024-06-03 "Implement wrap-around arithmetics in DWARF expressions" (f3d6d60d2ae). Approved-By: Tom Tromey <tom@tromey.com>
2024-07-02Accept unnamed array in gdb.ada/limited-length.expTom Tromey1-12/+9
Some compiler changes I'm working on cause a regression in gdb.ada/limited-length.exp -- with the changes, the array type is nameless and so is not mentioned in the max-value-size error message. Because the array type is nameless in the source code, this seems like an improvement to me, and so this patch changes the test to accept either form.
2024-04-02Implement Ada 2022 iterated assignmentTom Tromey4-0/+110
Ada 2022 includes iterated assignment for array initialization. This patch implements a subset of this for gdb. In particular, only arrays with integer index types really work -- currently there's no decent way to get the index type in EVAL_AVOID_SIDE_EFFECTS mode during parsing. Fixing this probably requires the Ada parser to take a somewhat more sophisticated approach to type resolution; and while this would help fix another bug in this area, this patch is already useful without it.
2024-04-02Run isortTom Tromey1-0/+1
This patch is the result of running 'isort .' in the gdb directory. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02[gdb/testsuite] Fix gdb.ada/verylong.exp on 32-bit targetTom de Vries1-7/+21
In an aarch32-linux chroot on an aarch64-linux system, I run into: ... (gdb) print x^M $1 = 9223372036854775807^M (gdb) FAIL: gdb.ada/verylong.exp: print x ... A passing version on aarch64-linux looks like: ... (gdb) print x^M $1 = 170141183460469231731687303715884105727^M (gdb) PASS: gdb.ada/verylong.exp: print x ... The difference is caused by the size of the type Long_Long_Long_Integer, which is: - a 128-bit signed on 64-bit targets, and - a 64-bit signed on 32-bit target. Fix this by detecting the size of the Long_Long_Long_Integer type, and handling it. Tested on aarch64-linux and aarch32-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31574 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31574 [1] https://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html
2024-03-25[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with gcc <= 12Tom de Vries1-1/+1
With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc 12, I get: ... (gdb) set debug symtab-create 1^M (gdb) print *the_local_var^M ... $1 = (n => 2)^M (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded ... The problem is that this fails: ... -re -wrap ".* = \\\(n => $decimal\\\)" { if {$found_pck + $found_pck2 == 1} { pass $gdb_test_name } else { fail $gdb_test_name } ... because $found_pck == 0 and $found_pck2 == 0. Indeed, with gcc 13 we have: ... $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' b~foo.adb b~foo.adb b~foo.adb b~foo.ads pck2.adb pck2.adb pck2.ads pck2.adb pck2.ads ... and with gcc 12: ... $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' b~foo.adb b~foo.adb b~foo.adb b~foo.ads ... Fix this by checking for "$found_pck + $found_pck2 <= 1" instead. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31514 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514
2024-03-21Implement Ada 2022 delta aggregatesTom Tromey4-0/+138
Ada 2022 includes a "delta aggregates" feature that can sometimes simplify aggregate creation. This patch implements this feature for GDB.
2024-03-19Speed up lookup of "type_specific_data"Tom Tromey6-0/+170
I noticed that "info locals" on a certain large Ada program was very slow. I tracked this down to ada_get_tsd_type expanding nearly every CU in the program. This patch fixes the problem by changing this code to use the more efficient lookup_transparent_type which, unlike the Ada-specific lookup functions, does not try to find all matching instances. Note that I first tried fixing this by changing ada_find_any_type, but this did not work -- I may revisit this approach at some later date. Also note that the copyright dates on the test files are set that way because I copied them from another test. New in v2: the new test failed on the Linaro regression tester. Looking at the logs, it seems that gdb was picking up a 'value' from libgnat: $1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value> This version renames the local variable in an attempt to work around this. v3: In v2, while trying to reproduce the problem locally, I accidentally forgot to commit one of the changes.
2024-03-18Fix Ada 'ptype' of access to arrayTom Tromey2-0/+15
ptype is a bit funny, in that it accepts both expressions and type names. It also evaluates the resulting expression using EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would you expect ptype to possibly cause inferior execution?), but is also a historical artifact of how expressions are implemented (there's no EVAL_FOR_TYPE). In Ada, calling a function with an array will sometimes result in a "thick pointer" array descriptor being made. This is essentially a structure holding a pointer and bounds information. Currently, in such a callee, printing the type of the array will yield funny results: (gdb) print str.all $1 = "Hello World" (gdb) ptype str type = array (<>) of character (gdb) ptype str.all type = array (1 .. 0) of character That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch trying to do "something" with an array descriptor, without doing too much. I tried briefly to make this code really dereference the array descriptor and get the correct runtime type. However, that proved to be tricky; it certainly can't be done for all access types, because that will cause dynamic type resolution and end up printing just the runtime type -- which with variants may be pretty far from what the user may expect. Instead, this patch arranges to just leave such types alone in this situation. I don't think this should have an extra effects, because things like array subscripting still work on thick pointers. This patch also touches arrayptr.exp, because in that case the access type is a "thin pointer", and this ensures that the output does not change in that scenario.
2024-03-11Special case NULL pointers in dynamic type resolutionTom Tromey2-0/+69
commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically") caused a regression on a test case in the AdaCore internal test suite. The issue here is that gdb would try to resolve the type of a dynamic pointer that happened to be NULL. In this case, the "Location address is not set." error would end up being thrown from the DWARF expression evaluator. I think it makes more sense to special-case NULL pointers and not try to resolve their target type, as that type can't really be accessed anyway. This patch implements this idea, and also adds the missing Ada test case.
2024-02-27Rewrite "python" command exception handlingTom Tromey1-4/+4
The "python" command (and the Python implementation of the gdb "source" command) does not handle Python exceptions in the same way as other gdb-facing Python code. In particular, exceptions are turned into a generic error rather than being routed through gdbpy_handle_exception, which takes care of converting to 'quit' as appropriate. I think this was done this way because PyRun_SimpleFile and friends do not propagate the Python exception -- they simply indicate that one occurred. This patch reimplements these functions to respect the general gdb convention here. As a bonus, some Windows-specific code can be removed, as can the _execute_file function. The bulk of this change is tweaking the test suite to match the new way that exceptions are displayed. These changes are largely uninteresting. However, it's worth pointing out the py-error.exp change. Here, the failure changes because the test changes the host charset to something that isn't supported by Python. This then results in a weird error in the new setup. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 Acked-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-02-27[gdb/testsuite] Remove KFAIL for PR ada/30908Tom de Vries2-44/+4
PR ada/30908 turns out to be a duplicate of PR ada/12607, which was fixed by commit d56fdf1b976 ("Refine Ada overload matching"). Remove the KFAILs for PR ada/30908. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908
2024-02-19[gdb/exp] Fix printing of out of bounds struct membersTom de Vries2-0/+155
When building gdb with -O0 -fsanitize=address, and running test-case gdb.ada/uninitialized_vars.exp, I run into: ... (gdb) info locals a = 0 z = (a => 1, b => false, c => 2.0) ================================================================= ==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80 READ of size 4 at 0x602000097f58 thread T0 #0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18) #1 0xbcab24 in unsigned char* std::__copy_move_backward<false, true, std::random_access_iterator_tag>::__copy_move_b<unsigned char const, unsigned char>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748 #2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769 #3 0xbc898c in unsigned char* std::__copy_move_backward_a1<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778 #4 0xbc715c in unsigned char* std::__copy_move_backward_a<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807 #5 0xbc4e6c in unsigned char* std::copy_backward<unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867 #6 0xbc2934 in void gdb::copy<unsigned char const, unsigned char>(gdb::array_view<unsigned char const>, gdb::array_view<unsigned char>) gdb/../gdbsupport/array-view.h:223 #7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239 #8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078 #9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095 #10 0xcafd64 in print_field_values gdb/ada-valprint.c:658 #11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857 #12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042 #13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04) #14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092 #15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184 #16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 #17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 #18 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 #19 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 #20 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 #21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 #22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259 #23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 #24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 #25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 #26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 #27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 #28 0x1384080 in command_handler(char const*) gdb/event-top.c:566 #29 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802 #30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 #31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 #32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 #33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 #34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 #35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 #36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 #37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694 #38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264 #39 0x1768080 in start_event_loop gdb/main.c:408 #40 0x17684c4 in captured_command_loop gdb/main.c:472 #41 0x176cfc8 in captured_main gdb/main.c:1342 #42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361 #43 0xb73edc in main gdb/gdb.c:39 #44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8) #45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac) #46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c) 0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58) allocated by thread T0 here: #0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218) #1 0xcbc278 in xcalloc gdb/alloc.c:97 #2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29 #3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937 #4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033 #5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector<range, std::allocator<range> > const&) gdb/value.c:229 #6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560 #7 0x20ca6fc in value_check_printable gdb/valprint.c:1133 #8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182 #9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 #10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 #11 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 #12 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 #13 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 #14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 #15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259 #16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 #17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 #18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 #19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 #20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 #21 0x1384080 in command_handler(char const*) gdb/event-top.c:566 #22 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802 #23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 #24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 #25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 #26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 #27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 #28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 #29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove ... The error happens when trying to print either variable y or y2: ... type Variable_Record (A : Boolean := True) is record case A is when True => B : Integer; when False => C : Float; D : Integer; end case; end record; Y : Variable_Record := (A => True, B => 1); Y2 : Variable_Record := (A => False, C => 1.0, D => 2); ... when the variables are uninitialized. The error happens only when printing the entire variable: ... (gdb) p y.a $2 = 216 (gdb) p y.b There is no member named b. (gdb) p y.c $3 = 9.18340949e-41 (gdb) p y.d $4 = 1 (gdb) p y <AddressSanitizer: heap-buffer-overflow> ... The error happens as follows: - field a functions as discriminant, choosing either the b, or c+d variant. - when y.a happens to be set to 216, as above, gdb interprets this as the variable having the c+d variant (which is why trying to print y.b fails). - when printing y, gdb allocates a value, copies the bytes into it from the target, and then prints the value. - gdb allocates the value using the type size, which is 8. It's 8 because that's what the DW_AT_byte_size indicates. Note that for valid values of a, it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1 (b variant), size is 8. - gdb tries to print field d, which is at an 8 byte offset, and that results in a out-of-bounds access for the allocated 8-byte value. Fix this by handling this case in value::contents_copy_raw, such that we have: ... (gdb) p y $1 = (a => 24, c => 9.18340949e-41, d => <error reading variable: access outside bounds of object>) ... An alternative (additional) fix could be this: in compute_variant_fields_inner gdb reads the discriminant y.a to decide which variant is active. It would be nice to detect that the value (y.a == 24) is not a valid Boolean, and give up on choosing a variant altoghether. However, the situation regarding the internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not possible to reliably decide what valid values are. The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the copyright years. Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc versions. [ So, it would be nice to rewrite it into a dwarf assembly test-case. ] The test-case loops over all languages. This is inherited from an earlier attempt to fix this, which had language-specific fixes (in print_field_values, cp_print_value_fields, pascal_object_print_value_fields and f_language::value_print_inner). I've left this in, but I suppose it's not strictly necessary anymore. Tested on x86_64-linux. PR exp/31258 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258
2024-01-28Use the new symbol domainsTom Tromey2-3/+3
This patch changes the DWARF reader to use the new symbol domains. It also adjusts many bits of associated code to adapt to this change. The non-DWARF readers are updated on a best-effort basis. This is somewhat simpler since most of them only support C and C++. I have no way to test a few of these. I went back and forth a few times on how to handle the "tag" situation. The basic problem is that C has a special namespace for tags, which is separate from the type namespace. Other languages don't do this. So, the question is, should a DW_TAG_structure_type end up in the tag domain, or the type domain, or should it be language-dependent? I settled on making it language-dependent using a thought experiment. Suppose there was a Rust compiler that only emitted nameless DW_TAG_structure_type objects, and specified all structure type names using DW_TAG_typedef. This DWARF would be correct, in that it faithfully represents the source language -- but would not work with a purely struct-domain implementation in gdb. Therefore gdb would be wrong. Now, this approach is a little tricky for C++, which uses tags but also enters a typedef for them. I notice that some other readers -- like stabsread -- actually emit a typedef symbol as well. And, I think this is a reasonable approach. It uses more memory, but it makes the internals simpler. However, DWARF never did this for whatever reason, and so in the interest of keeping the series slightly shorter, I've left some C++-specific hacks in place here. Note that this patch includes language_minimal as a language that uses tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, which doesn't specify the language for a type unit. Arguably this test case is wrong. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
2024-01-24Handle DW_AT_endianity on enumeration typesTom Tromey2-4/+14
A user found that gdb would not correctly print a field from an Ada record using the scalar storage order feature. We tracked this down to a combination of problems. First, GCC did not emit DW_AT_endianity on the enumeration type. DWARF does not specify this, but it is an obvious and harmless extension. This was fixed in GCC recently: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.html https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd Second, GDB did not handle this attribute on enumeration types. This patch makes this change and adds a test case that will pass with the patched GCC. So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes in, the test case in this patch can be updated to reflect that. Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess777-777/+777
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-12-15Refine Ada overload matchingTom Tromey2-0/+74
Currently, the overload handling in Ada assumes that any two array types are compatible. However, this is obviously untrue, and a user reported an oddity where comparing two Ada strings resulted in a call to the "=" function for packed boolean arrays. This patch improves the situation somewhat, by requiring that the two arrays have the same arity and compatible base element types. This is still over-broad, but it seems safe and is better than the status quo.
2023-12-11[gdb/testsuite] Fix $eol regexp usage in some test-casesTom de Vries3-13/+13
Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced: ... set eol "\[\r\n\]+" ... with the more strict: ... set eol "\r\n" ... in a few test-cases, but didn't update all uses of eol accordingly. Fix this in three gdb.ada test-cases. Tested on x86_64-linux. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-12-08gdb/testsuite: tighten up some end-of-line patternsAndrew Burgess6-7/+7
Following on from the previous commit, I searched the testsuite for places where we did: set eol "<some pattern>" in most cases the <some pattern> could be replaced with "\r\n" though in the stabs test I've switched to using the multi_line proc as that seemed like a better choice. In gdb.ada/info_types.exp I did need to add an extra use of $eol as the previous pattern would match multiple newlines, and in this one place we were actually expecting to match multiple newlines. The tighter pattern only matches a single newline, so we now need to be explicit when multiple newlines are expected -- I think this is a good thing. All the tests are still passing for me after these changes. Approved-By: Tom Tromey <tom@tromey.com>
2023-12-08gdb/testsuite: fix gdb.ada/complete.exp timeout in READ1 modeAndrew Burgess1-5/+14
While reviewing another patch I spotted a timeout in gdb.ada/complete.exp when testing in READ1 mode, e.g.: $ make check-read1 TESTS="gdb.ada/complete.exp" ... FAIL: gdb.ada/complete.exp: complete break ada (timeout) ... The problem is an attempt to match the entire output from GDB within a single gdb_test_multiple pattern, for a completion command that returns a large number of completions. This commit changes the gdb_test_multiple to process the output line by line. I don't use the gdb_test_multiple -lbl option, as I've always found that option backward -- it checks for the \r\n at the start of each line rather than the end, I think it's much clearer to use '^' at the start of each pattern, and '\r\n' at the end, so that's what I've done here. .... Or I would, if this test didn't already define $eol as the end of line regexp ... except that $eol was set to '[\r\n]*', which isn't that helpful, so I've updated $eol to be just '\r\n' the actual end of line regexp. And now, the test passes without a timeout when using READ1. There should be no change in what is tested after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-20PowerPC: Fix test gdb.ada/finish-large.expCarl Love1-1/+7
Function Create_large returns a large data structure. On PowerPC, register r3 contains the address of where the data structure to be returned is to be stored. However, on exit the ABI does not guarantee that r3 has not been changed. The GDB finish command prints the return value of the function at the end of the function. GDB needs to use the DW_TAG_call_site information to determine the value of r3 on entry to the function to correctly print the return value at the end of the function. The test must be compiled with -fvar-tracking for the DW_TAG_call_site information to be included in the executable file. This patch adds the -fvar-tracking option to the compile line if the option is supported. The patch fixes the one regression error for the test on PowerPC. The patch has been tested on Power 10 and X86-64 with no regressions.
2023-11-13Fix the gdb.ada/inline-section-gc.exp testCarl Love2-4/+20
The original intention of the test appears to be checking to make sure setting a breakpoint in an inlined function didn't set multiple breakpoints where one of them was at address 0. The gdb.ada/inline-section-gc.exp test may pass or fail depending on the version of gnat. Per the discussion on IRC, the ada inlining appears to have some target dependencies. In this test there are two functions, callee and caller. Function calee is inlined into caller. The test sets a breakpoint in function callee. The reported location where the breakpoint is set may be at the requested location in callee or the location in caller after callee has been inlined. The test needs to accept either location as correct provided the breakpoint address is not zero. This patch checks to see if the reported breakpoint is in function callee or function caller and fails if the breakpoint address is 0x0. The line number where the breakpoint is set will match the requested line if the breakpoint location is reported is callee.adb. If the breakpoint is reported in caller.adb, the line number in caller is the breakpoint location in callee where it is inlined into caller. This patch fixes the single regression failure for the test on PowerPC. It does not introduce any failures on X86-64.
2023-10-12Fix test suite failure in file-then-restart.expTom Tromey1-6/+2
Simon pointed out that the new file-then-restart.exp test fails with the extended-remote target board. The problem is that the test suite doesn't use gdb_file_cmd -- which handles things like "set remote exec-file". This patch changes gdb_file_cmd to make the "kill" command optional, and then switches the test case to use it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-10-02Clean up intermediate values in val_print_packed_array_elementsTom Tromey2-35/+43
Following on Tom de Vries' work in the other array-printers, this patch changes val_print_packed_array_elements to also avoid allocating too many values when printing an Ada packed array.
2023-10-02[gdb/testsuite] Handle older gcc in gdb.ada/import.expTom de Vries1-0/+34
When running test-case gdb.ada/import.exp with gcc 7, most test fail: ... FAIL: gdb.ada/import.exp: print imported_var_ada FAIL: gdb.ada/import.exp: print local_imported_var FAIL: gdb.ada/import.exp: print pkg.imported_var_ada FAIL: gdb.ada/import.exp: print pkg.exported_var_ada FAIL: gdb.ada/import.exp: print exported_var_ada FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at local_imported_func ... When running with gcc 8 or 9, only 2 tests fail: ... FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada ... The test-case passes fully with gcc 10, 11, 12 and 13. Debug info for pragma import seems to not have been supported before gcc 8, so require that version. The two FAILs with gcc 8 and 9 seem to be due to problems in debug info. Add an xfail for these. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-02[gdb/testsuite] Add KFAIL for PR ada/30908Tom de Vries2-4/+44
With gcc 13.2.1, I run into a cluster of fails: ... FAIL: gdb.ada/str_binop_equal.exp: print my_str = "ABCD" FAIL: gdb.ada/widewide.exp: print my_wws = " helo" FAIL: gdb.ada/widewide.exp: print my_ws = "wide" ... The problem is that the debug info contains information about function ada.strings.maps."=", and gdb uses it to implement the comparison. The function is supposed to compare two char sets, not strings, so gdb shouldn't use it. This is PR ada/30908. I don't see the same problem with gcc 7.5.0, because the exec doesn't contain the debug info for the function, because the corresponding object is not linked in. Adter adding "with Ada.Strings.Maps; use Ada.Strings.Maps;" to gdb.ada/widewide/foo.adb I run into the same problem with gcc 7.5.0. Add KFAILs for the PR. Tested on x86_64-linux: - openSUSE Leap 15.4 (using gcc 7.5.0), and - openSUSE Tumbleweed (using gcc 13.2.1). Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908
2023-09-26[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp with newer gccTom de Vries1-1/+2
When running test-case gdb.ada/mi_task_arg.exp on openSUSE Tumbleweed using gcc 13.2.1, I run into (layout adapted for readability): ... -stack-list-arguments 1^M ^done,stack-args=[ frame={level="0",args=[]}, frame={level="1",args=[{name="<_task>",value="0x464820"}, {name="<_taskL>",value="129"}]}, frame={level="2",args=[{name="self_id",value="0x464840"}]}, frame={level="3",args=[]}, frame={level="4",args=[]} ]^M (gdb) ^M FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) ... On openSUSE Leap 15.4 with gcc 7.5.0 I get instead: ... -stack-list-arguments 1^M ^done,stack-args=[ frame={level="0",args=[]}, frame={level="1",args=[{name="<_task>",value="0x444830"}]}, frame={level="2",args=[{name="self_id",value="0x444850"}]}, frame={level="3",args=[]}, frame={level="4",args=[]}]^M (gdb) ^M PASS: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 ... The difference in gdb output is due to difference in the dwarf generated by the compiler, so I don't see a problem with gdb here. Fix this by updating the test-case to accept this output. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-14[gdb/exp] Clean up asap in value_print_array_elementsTom de Vries4-0/+212
I've been running the test-suite on an i686-linux laptop with 1GB of memory, and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb not being able to spawn for a large number of test-cases afterwards. So I investigated the memory usage, on my usual x86_64-linux development platform. The test-case is compiled with -DCRASH_GDB=2097152, so this: ... static int a[CRASH_GDB], b[CRASH_GDB]; ... with sizeof (int) == 4 represents two arrays of 8MB each. Say we add a loop around the "print a" command and print space usage statistics: ... gdb_test "maint set per-command space on" for {set i 0} {$i < 100} {incr i} { gdb_test "print a" } ... This gets us: ... (gdb) print a^M $1 = {0 <repeats 2097152 times>}^M Space used: 478248960 (+469356544 for this command)^M (gdb) print a^M $2 = {0 <repeats 2097152 times>}^M Space used: 486629376 (+8380416 for this command)^M (gdb) print a^M $3 = {0 <repeats 2097152 times>}^M Space used: 495009792 (+8380416 for this command)^M ... (gdb) print a^M $100 = {0 <repeats 2097152 times>}^M Space used: 1308721152 (+8380416 for this command)^M ... In other words, we start out at 8MB, and the first print costs us about 469MB, and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the i686-linux laptop, the first print costs us 335MB. ] The subsequent 8MBs are consistent with the values being saved into the value history, but the usage for the initial print seems somewhat excessive. There is a PR open about needing sparse representation of large arrays (PR8819), but this memory usage points to an independent problem. The function value_print_array_elements contains a scoped_value_mark to free allocated values in the outer loop, but it doesn't prevent the inner loop from allocating a lot of values. Fix this by adding a scoped_value_mark in the inner loop, after which we have: ... (gdb) print a^M $1 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M (gdb) print a^M $2 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M (gdb) print a^M $3 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M ... (gdb) print a^M $100 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M ... Note that the +0 here just means that the mallocs did not trigger an sbrk. This is dependent on malloc (which can use either mmap or sbrk or some pre-allocated memory) and will likely vary between different tunings, versions and implementations, so this does not give us a reliable way detect the problem in a minimal way. A more reliable way of detecting the problem is: ... void value_free_to_mark (const struct value *mark) { + size_t before = all_values.size (); auto iter = std::find (all_values.begin (), all_values.end (), mark); if (iter == all_values.end ()) all_values.clear (); else all_values.erase (iter + 1, all_values.end ()); + size_t after = all_values.size (); + if (before - after >= 1024) + fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after); ... which without the fix tells us: ... +print a value_free_to_mark freed 2097152 items $1 = {0 <repeats 2097152 times>} ... Fix a similar problem for Fortran: ... +print array1 value_free_to_mark freed 4194303 items $1 = (0, <repeats 2097152 times>) ... in fortran_array_printer_impl::process_element. The problem also exists for Ada: ... +print Arr value_free_to_mark freed 2097152 items $1 = (0 <repeats 2097152 times>) ... but is fixed by the fix for C. Add Fortran and Ada variants of the test-case. The *.exp files are similar enough to the original to keep the copyright years range. While writing the Fortran test-case, I ran into needing an additional print setting to print the entire array in repeat form, filed as PR exp/30817. I managed to apply the compilation loop for the Ada variant as well, but with a cumbersome repetition style. I noticed no other test-case uses gnateD, so perhaps there's a better way of implementing this. The regression test included in the patch is formulated in its weakest form, to avoid false positive FAILs, which also means that smaller regressions may not get detected. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-07[gdb/ada] Move identical enums handling laterTom de Vries1-0/+2
When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board cc-with-dwz, I run into: ... (gdb) print enum_with_gaps'enum_rep(lit3)^M 'Enum_Rep requires argument to have same type as enum^M (gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep ... With target_board unix, we have instead: ... (gdb) print enum_with_gaps'enum_rep(lit3)^M $16 = 13^M (gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep ... Conversely, when I add this test to the test-case: ... gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \ "enum_rep" + gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \ + "other enum_rep" ... the extra test passes with target board cc-with-dwz, but fails with target board unix. The problem is here in remove_extra_symbols: ... if (symbols_are_identical_enums (syms)) syms.resize (1); ... where one of the two identical enums is picked before the enum_rep handling can resolve lit3 to one of the two. Fix this by moving the code to ada_resolve_variable. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR ada/30726 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726
2023-09-06[gdb/testsuite] Fix gdb.ada/same_enum.expTom de Vries2-2/+4
Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this bit of code in remove_extra_symbols: ... if (symbols_are_identical_enums (syms)) syms.resize (1); ... The test-case does "print red" and expects one of these two choices to be picked by remove_extra_symbols: ... type Color is (Black, Red, Green, Blue, White); type RGB_Color is new Color range Red .. Blue; ... but because only the type Color is used: ... FC : Color := Red; SC : Color := Green; ... the RGB_Color type is eliminated from the debug info, and consequently remove_extra_symbols has no effect for the test-case. In other words, we have: ... (gdb) ptype Color ^M type = (black, red, green, blue, white)^M (gdb) ptype RGB_Color^M No definition of "rgb_color" in current context.^M ... Fix this by changing the type of SC to RGB_Color, and add prints of the two types to check that they're both available. With the test-case fixed, if we disable the bit of code in remove_extra_symbols we get: ... (gdb) print red^M Multiple matches for red^M [0] cancel^M [1] pck.color'(pck.red) (enumeral)^M [2] pck.rgb_colorB'(pck.red) (enumeral)^M > FAIL: gdb.ada/same_enum.exp: print red (timeout) ... in other words, the test-case now properly functions as a regression test. Tested on x86_64-linux.
2023-09-05Read Ada main name from executable, not inferiorTom Tromey3-0/+119
An upstream bug report points out this bug: if the user switches from one Ada executable to another without "kill"ing the inferior, then the "start" command will fail. What happens here is that the Ada "main" name is found in a constant string in the executable. But, if the inferior is running, then the process_stratum target reads from the inferior memory. This patch fixes the problem by changing the main name code to set trust-readonly-sections, causing the target stack to read from the executable instead. I looked briefly at changing GNAT to emit DW_AT_main_subprogram instead, but this looks to be pretty involved. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811
2023-09-05Avoid crash with Ada and -fdata-sectionsTom Tromey2-0/+53
A user noticed that gdb would crash when showing a backtrace. Investigation showed this to be a crash in the DWARF reader when handling a "pragma export" symbol. The bug here is that earlier code decides to eliminate the symbol, but the export code tries to add it anyway -- but to a NULL list.
2023-08-17gdb: add inferior-specific breakpointsAndrew Burgess1-0/+2
This commit extends the breakpoint mechanism to allow for inferior specific breakpoints (but not watchpoints in this commit). As GDB gains better support for multiple connections, and so for running multiple (possibly unrelated) inferiors, then it is not hard to imagine that a user might wish to create breakpoints that apply to any thread in a single inferior. To achieve this currently, the user would need to create a condition possibly making use of the $_inferior convenience variable, which, though functional, isn't the most user friendly. This commit adds a new 'inferior' keyword that allows for the creation of inferior specific breakpoints. Inferior specific breakpoints are automatically deleted when the associated inferior is removed from GDB, this is similar to how thread-specific breakpoints are deleted when the associated thread is deleted. Watchpoints are already per-program-space, which in most cases mean watchpoints are already inferior specific. There is a small window where inferior-specific watchpoints might make sense, which is after a vfork, when two processes are sharing the same address space. However, I'm leaving that as an exercise for another day. For now, attempting to use the inferior keyword with a watchpoint will give an error, like this: (gdb) watch a8 inferior 1 Cannot use 'inferior' keyword with watchpoints A final note on the implementation: currently, inferior specific breakpoints, like thread-specific breakpoints, are inserted into every inferior, GDB then checks once the inferior stops if we are in the correct thread or inferior, and resumes automatically if we stopped in the wrong thread/inferior. An obvious optimisation here is to only insert breakpoint locations into the specific program space (which mostly means inferior) that contains either the inferior or thread we are interested in. This would reduce the number times GDB has to stop and then resume again in a multi-inferior setup. I have a series on the mailing list[1] that implements this optimisation for thread-specific breakpoints. Once this series has landed I'll update that series to also handle inferior specific breakpoints in the same way. For now, inferior specific breakpoints are just slightly less optimal, but this is no different to thread-specific breakpoints in a multi-inferior debug session, so I don't see this as a huge problem. [1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
2023-08-16Fix obvious bug in aggregate expressionTom Tromey5-0/+139
I found an obvious bug in Ada aggregate expression handling: if (vvo != nullptr) error (_("Invalid record component association.")); name = vvo->get_symbol ()->natural_name (); Here the code errors when vvo is not null -- and then proceeds to use vvo. This hasn't caused a crash because, I believe, there's currently no way to reach this code in the null case. However, I'm not really willing to assert this... Fixing this shows another bug, which is that due to the way the parser works, a field name in an aggregate expression might erroneously be fully qualified if some global variable with the same base name exists. The included test case triggers both bugs. Note that the test includes a confounding case for array aggregates as well, but as these are harder to fix, I've left it as kfail. As this is Ada-specific, and has already been tested internally at AdaCore, I am checking it in.
2023-08-11gdb.ada/mi_var_access.expCarl Love1-2/+9
The NUMCHILD value for the "A_String_Access" test differs for X86 and PowerPC. The patch substitutes $decimal instead of "1" to match the value of NUMCHILD. The test "-var-update A_String_Access" generates different output depending on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true, the strings "new_type" and "new_num_children" are printed along with their values. The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which produces the output: Expecting: ^(-var-update A_String_Access[ ]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][ ]+[(]gdb[)] [ ]*) -var-update A_String_Access ^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}] (gdb) FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output) The patch adds a second possible result string for the test $re_varobj_update_result_type to match the case when type_changed is true. Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED is true on PowerPC and false on X86-64. Fixes 2 failures on PowerPC. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-11Test GNAT encodings in arr_acc_idx_w_gap.expTom Tromey1-37/+43
While working on a GNAT bug, I wanted to also test arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is ready, I plan to add a new case here. Tested on x86-64 Fedora 36. I am checking this in.
2023-08-10Fix gdb.ada/O2_float_param.exp for PowerPCCarl Love1-1/+8
The frame command on Power pc prints the address in hex between the #0 and in calle.increment. For example (gdb) frame #0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...) at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19 19 procedure Increment (Val : in out Float; Msg: String) is The printing of the address for the frame is done by function print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame, function frame_show_address returns true and print_frame prints the address. Currently, SAL.IS is false on PowerPC and true on X86-64. Update the set re string to accept the hex address if it exits. Fixes two failures on PowerPC. Patch tested on Power10 with no new regressions. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-02Avoid failures in fixed_points.exp with older GCCTom Tromey1-2/+5
Tom de Vries pointed out that my recent change to fixed_points.exp failed with older versions of GCC. This patch fixes the problem by skipping the new test in this situation.
2023-07-31Fix bug in fixed-point handlingTom Tromey2-0/+11
Alexandre Oliva found a bug in gdb's handling of fixed-point -- a certain Ada fixed-point type would be misintepreted. The bug was that the DW_AT_small looked like: <1><13cd>: Abbrev Number: 16 (DW_TAG_constant) <13ce> DW_AT_GNU_numerator: 1 <13cf> DW_AT_GNU_denominator: 0x8000000000000000 ... but gdb interpreted the denominator as a negative value.
2023-07-21Implement Ada target name symbolTom Tromey1-0/+15
Ada 2022 adds the "target name symbol", which can be used on the right hand side of an assignment to refer to the left hand side. This allows for convenient updates. This patch implements this for gdb's Ada expression parser. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-07-13Implement 'Enum_Val and 'Enum_RepTom Tromey1-0/+5
This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-06-28Fix handling of DW_TAG_unspecified_type for AdaTom Tromey1-0/+5
Commit 80eaec735e ("[gdb/symtab] Handle named DW_TAG_unspecified_type DIE") changed the handling of DW_TAG_unspecified_type. Before this change, such types were not entered into the symbol table. It turns out that, when such a type is in the symtab, it can cause failures in Ada. In particular, a private type in another package may be seen locally as "void". Now, it would probably be better to fix this via check_typedef. However, that is somewhat difficult given the state of the DWARF reader -- in particular with gdb_index, this would require expanding potentially many CUs to find the correct type. Instead, this patch changes gdb to not enter a symbol for an unspecified type -- but only for Ada.
2023-06-22[gdb/testsuite] Clean or check standard_output_file dir in gdb_initTom de Vries1-5/+0
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some files at the start of the test-case: ... remote_file host delete [standard_output_file prog.o] remote_file host delete [standard_output_file prog.ali] ... Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in gdb_init") I tried to do this more structurally, by cleaning up the entire standard_output_file directory, for all test-cases. This caused a regression when using "make check -j 2", due to the cleanup removing the active gdb.log, so I reverted the commit. Try again, this time handling the two cases separately. If the standard_output_file directory contains an active gdb.log, check that the directory contains no files other than gdb.log and gdb.sum. This puts the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in which use --outdir. If the standard_output_file directory doesn't contain an active gdb.log, clean it by removing the entire directory. An exception is made for performance tests, where cleaning up the standard_output_file dir is the wrong thing to do, because an invocation with GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an earlier invocation with GDB_PERFTEST_MODE == compile. Tested on x86_64-linux. Suggested-By: Tom Tromey <tom@tromey.com> Reviewed-By: Tom Tromey <tom@tromey.com> Tested-By: Luis Machado <luis.machado@arm.com>
2023-06-21[gdb/testsuite] Add have_host_localeTom de Vries3-0/+3
With test-case gdb.tui/pr30056.exp, I run into: ... sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M ... and then subsequently into: ... WARNING: timeout in accept_gdb_output FAIL: gdb.tui/pr30056.exp: Control-C ... This is on a CentOS 7 distro for powerpc64le. Either it has no C.UTF-8 support, or it's not installed: ... $ locale -a | grep ^C C $ ... Fix this by: - adding a new proc have_host_locale, and - using it in all test-cases using setenv LC_ALL. Tested on powerpc64le-linux and x86_64-linux.
2023-06-19Revert "[gdb/testsuite] Clean standard_output_file dir in gdb_init"Tom de Vries1-0/+5
This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557.
2023-06-19[gdb/testsuite] Add shared_gnat_runtime_has_debug_infoTom de Vries1-1/+1
Test-case gdb.ada/catch_ex_std.exp passes for me with package libada7-debuginfo installed, but after removing it I get: ... (gdb) catch exception some_kind_of_error^M Your Ada runtime appears to be missing some debugging information.^M Cannot insert Ada exception catchpoint in this configuration.^M (gdb) FAIL: gdb.ada/catch_ex_std.exp: catch exception some_kind_of_error ... The test-case contains a require gnat_runtime_has_debug_info to deal with this, but the problem is that this checks the static gnat runtime, while this test-case uses the shared one. Fix this by introducing shared_gnat_runtime_has_debug_info, and requiring that one instead. Tested on x86_64-linux. PR testsuite/30094 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30094
generated by cgit v1.1 at 2024-08-31 19:01:02 +0000