aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2020-08-28Fix gdb.base/advance-until-multiple-locations.exp with some compilersPedro Alves2-2/+8
The tests in gdb.base/advance-until-multiple-locations.exp that expect the program to stop at a caller fail on some systems, depending on compiler. E.g., with Clang 10, I see: advance ovld_func 0x00000000004011a3 in test () at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.base/advance-until-multiple-locations.cc:51 51 ovld_func (); (gdb) FAIL: gdb.base/advance-until-multiple-locations.exp: advance_overload: second advance stops at caller And Tom de Vries saw: ... (gdb) until ovld_func^M main () at advance-until-multiple-locations.cc:61^M 61 }^M (gdb) FAIL: gdb.base/advance-until-multiple-locations.exp:until_overload: until ovld_func ... Which exact line the program stops is not important. All we care about here is that the program stopped at the caller function. So fix it by adjusting the patterns to match the frame header/function reported by the breakpoint hits instead of the source lines text. Tested against: - gcc {4.8, 4.9, 7.3.1, 9.3.0, trunk-20200828} - clang {5.0.2, 10} gdb/testsuite/ChangeLog: * gdb.base/advance-until-multiple-locations.exp (advance_overload, until_overload): Adjust to match the frame/function header instead of the source line text.
2020-08-28[gdb/breakpoint] Handle setting breakpoint on label without addressTom de Vries3-0/+66
Consider test-case test.c: ... $ cat test.c int main (void) { return 0; L1: (void)0; } ... Compiled with debug info: ... $ gcc test.c -g ... When attempting to set a breakpoint at L1, which is a label without address: ... <1><f4>: Abbrev Number: 2 (DW_TAG_subprogram) <f5> DW_AT_name : main <2><115>: Abbrev Number: 3 (DW_TAG_label) <116> DW_AT_name : L1 <119> DW_AT_decl_file : 1 <11a> DW_AT_decl_line : 5 <2><11b>: Abbrev Number: 0 ... we run into an internal-error: ... $ gdb -batch a.out -ex "b main:L1" linespec.c:3233: internal-error: void \ decode_line_full(const event_location*, int, program_space*, symtab*, \ int, linespec_result*, const char*, const char*): \ Assertion `result.size () == 1 || canonical->pre_expanded' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ... Fix this by detecting the error condition in decode_line_full instead, and throwing an error, such that we have instead: ... (gdb) b main:L1 Location main:L1 not available (gdb) ... Unfortunately, to call event_location_to_string, which is used to get the location name in the error message, we need to pass a non-const struct event_location, because the call may cache the string in the struct (See EL_STRING). So, we change the prototype of decode_line_full accordingly, and everywhere this propages to. Tested on x86_64-linux. gdb/ChangeLog: 2020-08-28 Tom de Vries <tdevries@suse.de> PR breakpoint/26544 * breakpoint.c (parse_breakpoint_sals): Remove const from struct event_location. (create_breakpoint): Same. (base_breakpoint_decode_location): Same. (bkpt_create_sals_from_location): Same. (bkpt_decode_location): Same. (bkpt_probe_create_sals_from_location): Same. (bkpt_probe_decode_location): Same. (tracepoint_create_sals_from_location): Same. (tracepoint_decode_location): Same. (tracepoint_probe_decode_location): Same. (strace_marker_create_sals_from_location): Same. (strace_marker_decode_location): Same. (create_sals_from_location_default): Same. (decode_location_default): Same. * breakpoint.h (struct breakpoint_ops): Same. (create_breakpoint): Same. * linespec.h (decode_line_full): Same. * linespec.c (decode_line_full): Same. Throw error if result.size () == 0. gdb/testsuite/ChangeLog: 2020-08-28 Tom de Vries <tdevries@suse.de> * gdb.base/label-without-address.c: New test. * gdb.base/label-without-address.exp: New file.
2020-08-27Fix advance/until and multiple locations (PR gdb/26524)Pedro Alves3-0/+210
If you do "advance LINESPEC", and LINESPEC expands to more than one location, GDB just errors out: if (sals.size () != 1) error (_("Couldn't get information on specified line.")); For example, advancing to a line in an inlined function, inlined three times: (gdb) b 21 Breakpoint 1 at 0x55555555516f: advance.cc:21. (3 locations) (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> 1.1 y 0x000055555555516f in inline_func at advance.cc:21 1.2 y 0x000055555555517e in inline_func at advance.cc:21 1.3 y 0x000055555555518d in inline_func at advance.cc:21 (gdb) advance 21 Couldn't get information on specified line. (gdb) Similar issue with the "until" command, as it shares the implementation with "advance". Since, as the comment in gdb.base/advance.exp says, "advance <location>" is really just syntactic sugar for "tbreak <location>;continue", fix this by making GDB insert a breakpoint at all the resolved locations. A new testcase is included, which exercises both "advance" and "until", in two different cases expanding to multiple locations: - inlined functions - C++ overloads This also exercises the inline frames issue fixed by the previous patch. gdb/ChangeLog: PR gdb/26524 * breakpoint.c (until_break_fsm) <location_breakpoint, caller_breakpoint>: Delete fields. <breakpoints>: New field. <until_break_fsm>: Adjust to save a breakpoint vector instead of two individual breakpoints. (until_break_fsm::should_stop): Loop over breakpoints in the breakpoint vector. (until_break_fsm::clean_up): Adjust to clear the breakpoints vector. (until_break_command): Handle location expanding into multiple sals. gdb/testsuite/ChangeLog: PR gdb/26523 PR gdb/26524 * gdb.base/advance-until-multiple-locations.cc: New. * gdb.base/advance-until-multiple-locations.exp: New.
2020-08-27gdb/testsuite: use multi_line in gdb.dwarf2/dw2-reg-undefined.expSimon Marchi2-1/+10
Use multi_line to make the expected pattern more readable. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-reg-undefined.exp: Use multi_line. Change-Id: Ia8e42d156c0c30265121eb890e1db17a692dbaf0
2020-08-27gdb: fix whitespace issues in ChangeLog filesSimon Marchi1-3/+3
Change-Id: I423867477d4342673e629dac71a80592fd879ea1
2020-08-27gdb/testsuite: make test names unique in gdb.arch/*.expAndrew Burgess9-186/+203
Make the test names unique in gdb.arch/*.exp by either modifying the test names or using with_test_prefix. I have also fixed a typo 'forth' -> 'fourth' throughout gdb.arch/*. Finally, I replaced code like this: gdb_test "break [gdb_get_line_number "first breakpoint here"]" \ "Breakpoint .* at .*${srcfile}.*" \ "set first breakpoint in main" With this: gdb_breakpoint [gdb_get_line_number "first breakpoint here"] In those files that I was already modifying for the other reasons given above. gdb/testsuite/ChangeLog: * gdb.arch/amd64-byte.exp: Make test names unique, use gdb_breakpoint, and fix typo 'forth' -> 'fourth'. * gdb.arch/amd64-dword.exp: Likewise. * gdb.arch/amd64-pseudo.c: Fix typo 'forth' -> 'fourth'. * gdb.arch/amd64-stap-special-operands.exp: Make test names unique. * gdb.arch/amd64-tailcall-ret.exp: Likewise. * gdb.arch/amd64-word.exp: Make test names unique, use gdb_breakpoint, and fix typo 'forth' -> 'fourth'. * gdb.arch/i386-byte.exp: Make test names unique, use gdb_breakpoint. * gdb.arch/i386-word.exp: Likewise.
2020-08-25arc: Add ARCv2 XML target along with refactoringShahab Vahedi2-2/+6
A few changes have been made to make the register support simpler, more flexible and extendible. The trigger for most of these changes are the remarks [1] made earlier for v2 of this patch. The noticeable improvements are: - The arc XML target features are placed under gdb/features/arc - There are two cores (based on ISA) and one auxiliary feature: v1-core: ARC600, ARC601, ARC700 v2-core: ARC EM, ARC HS aux: common in both - The XML target features represent a minimalistic sane set of registers irrespective of application (baremetal or linux). - A concept of "feature" class has been introduced in the code. The "feature" object is constructed from BFD and GDBARCH data. It contains necessary information (ISA and register size) to determine which XML target feature to use. - A new structure (ARC_REGISTER_FEATURE) is added that allows providing index, names, and the necessity of registers. This simplifies the sanity checks and future extendibility. - Documnetation has been updated to reflect ARC features better. - Although the feature names has changed, there still exists backward compatibility with older names through find_obsolete_[core,aux]_names() functions. The last two points were inspired from RiscV port. [1] https://sourceware.org/pipermail/gdb-patches/2020-May/168511.html gdb/ChangeLog: * arch/arc.h (arc_gdbarch_features): New class to stir the selection of target XML. (arc_create_target_description): Use FEATURES to choose XML target. (arc_lookup_target_description): Use arc_create_target_description to create _new_ target descriptions or return the already created ones if the FEATURES is the same. * arch/arc.c: Implementation of prototypes described above. * gdb/arc-tdep.h (arc_regnum enum): Add more registers. (arc_gdbarch_features_init): Initialize the FEATURES struct. * arc-tdep.c (*_feature_name): Make feature names consistent. (arc_register_feature): A new struct to hold information about registers of a particular target/feature. (arc_check_tdesc_feature): Check if XML provides registers in compliance with ARC_REGISTER_FEATURE structs. (arc_update_acc_reg_names): Add aliases for r58 and r59. (determine_*_reg_feature_set): Which feature name to look for. (arc_gdbarch_features_init): Given MACH and ABFD, initialize FEATURES. (mach_type_to_arc_isa): Convert from a set of binutils machine types to expected ISA enums to be used in arc_gdbarch_features structs. * features/Makefile (FEATURE_XMLFILES): Add new files. * gdb/features/arc/v1-aux.c: New file. * gdb/features/arc/v1-aux.xml: Likewise. * gdb/features/arc/v1-core.c: Likewise. * gdb/features/arc/v1-core.xml: Likewise. * gdb/features/arc/v2-aux.c: Likewise. * gdb/features/arc/v2-aux.xml: Likewise. * gdb/features/arc/v2-core.c: Likewise. * gdb/features/arc/v2-core.xml: Likewise. * NEWS (Changes since GDB 9): Announce obsolence of old feature names. gdb/doc/ChangeLog: * gdb.texinfo (Synopsys ARC): Update the documentation for ARC Features. gdb/testsuite/ChangeLog: * gdb.arch/arc-tdesc-cpu.xml: Use new feature names.
2020-08-25gdb/testsuite: fix gdb.threads/stepi-random-signal.exp pattern (gdb/26532)Simon Marchi2-1/+6
Commit 1eb8556f5a8b ("gdb: add infrun_debug_printf macro") changed the debug output format for `set debug infrun 1`. The test gdb.threads/stepi-random-signal.exp uses that debug output, and was updated, but not correctly. It results in this failure: FAIL: gdb.threads/stepi-random-signal.exp: stepi (no random signal) Fix it by adjusting the pattern in the test. gdb/testsuite/ChangeLog: PR gdb/26532 * gdb.threads/stepi-random-signal.exp: Update pattern. Change-Id: If5fa525e9545e32a286effe6a6184358374bd37c
2020-08-25gdb/testsuite: fix gdb.base/ui-redirect.exp pattern (gdb/26532)Simon Marchi2-1/+6
Commit 1eb8556f5a8b ("gdb: add infrun_debug_printf macro") changed the debug output format for `set debug infrun 1`. It broke test gdb.base/ui-redirect.exp, which I missed: FAIL: gdb.base/ui-redirect.exp: debugging: continue Fix it by adjusting the pattern in the test to the new reality. gdb/testsuite/ChangeLog: PR gdb/26532 * gdb.base/ui-redirect.exp: Update pattern. Change-Id: Ie8a8f6675e35a0cab55109b1534b44eb51baec9d
2020-08-25Fix ChangeLog entry for commit b04aa1fc8c9d4a79e6293a3a1df7507052afedf3Gary Benson1-1/+1
2020-08-25Disable Clang's integrated assembler for two testcasesGary Benson3-1/+20
gdb.dwarf2/dw2-dir-file-name.exp fails to build using Clang because the generated assembly language contains .ascii directives with more than one string literal. gdb.dwarf2/dw2-restore.exp fails to build using Clang because it contains .func and .endfunc directives. This commit causes Clang to invoke the system assembler to assemble the relevant files. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-dir-file-name.exp: Use system assembler when compiling with clang. * gdb.dwarf2/dw2-restore.exp: Likewise
2020-08-25Enable gdb.cp/ambiguous.exp with GCC and clangGary Benson2-2/+17
gdb.cp/ambiguous.exp failed to build using clang with the following error: gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.cp/ambiguous.cc:70:36: warning: direct base 'A1' is inaccessible due to ambiguity: class JVA1 -> class KV -> class A1 class JVA1 -> class A1 [-Winaccessible-base] class JVA1 : public KV, public LV, public A1 { ^~~~~~~~~ This commit builds this testcase with -Wno-inaccessible-base when using clang, to avoid this failure. Furthermore, gdb.cp/ambiguous.exp has been disabled when using GCC since 1998. This commit enables this testcase, building with -Wno-inaccessible-base when using GCC >= 10.1, and -w otherwise. gdb/testsuite/ChangeLog: * gdb.cp/ambiguous.exp: Enable test when compiling with GCC. Add additional_flags=-Wno-inaccessible-base when compiling with GCC >= 10.1 or clang. Add additional_flags=-w when compiling with GCC < 10.
2020-08-25gdb/modula-2: parsing of multi-subscript arraysGaius Mulley3-0/+82
Fix bug PR m2/26372, GDB's inability to parse multi-dimensional modula-2 arrays. We previously had two rules for handling the parsing of array sub-scripts. I have reproduced them here with the actual handler blocks removed to make the bug clearer: exp : exp '[' non_empty_arglist ']' ; exp : exp '[' exp ']' ; non_empty_arglist : exp ; non_empty_arglist : non_empty_arglist ',' exp ; This is ambiguous as the pattern "exp '[' exp" could match either of the 'exp' rules. Currently it just so happens that the parser picks the second 'exp' rule which means we can only handle a single array index. As the handler code for the first 'exp' pattern will correctly handle and number of array indexes then lets just remove the second pattern. gdb/ChangeLog: PR m2/26372 * m2-exp.y (exp): Improve comment for non_empty_arglist case, add an assert. Remove single element array indexing pattern as the MULTI_SUBSCRIPT support will handle this case too. gdb/testsuite/ChangeLog: PR m2/26372 * gdb.modula2/multidim.c: New file. * gdb.modula2/multidim.exp: New file.
2020-08-25Revert "Fix for Bug 26372 [Modula-2] Parsing of multi-subscript arrays"Andrew Burgess3-79/+0
This reverts commit 07758bdfa9e5a762f2ec0deeb51b11d6ad5fe376.
2020-08-25Fix for Bug 26372 [Modula-2] Parsing of multi-subscript arraysGaius Mulley3-0/+79
Here is a bugfix for Pr 26372 [Modula-2] Parsing of multi-subscript arrays. Also included is a dejagnu testcase. No extra regressions are caused on Debian GNU/Linux Buster amd64. gdb/ChangeLog: 2020-08-25 Gaius Mulley <gaiusmod2@gmail.com> PR m2/26372 * m2-exp.y: Rewrite array subscript rules to support multidimension array access. (ArgumentList) replaces non_empty_arglist. gdb/testsuite/ChangeLog: 2020-08-25 Gaius Mulley <gaiusmod2@gmail.com> PR m2/26372 * testsuite/gdb.modula2/multidim.exp: New file. * testsuite/gdb.modula2/multidim.c: New file.
2020-08-24gdb/testsuite: make runto always emit a FAIL on internal errorSimon Marchi2-3/+7
I noticed that when a test uses `runto_main` and a GDB internal error happens while running to main, no error or fail is emitted. This is because `runto_main` uses the `no-message` option of `runto`. As a result, if a test fails to run to main and exits, no sign that something went wrong is emitted. For example, add this always-false assertion to compute_frame_id: --- a/gdb/frame.c +++ b/gdb/frame.c @@ -545,6 +545,7 @@ static void compute_frame_id (struct frame_info *fi) { gdb_assert (!fi->this_id.p); + gdb_assert (false); if (frame_debug) fprintf_unfiltered (gdb_stdlog, "{ compute_frame_id (fi=%d) ", ... and run gdb.dwarf2/dw2-align.exp. No fail or sign that something went wrong is shown. It just appears as if the test gets skipped. A developer introducing such a regression in this test today would likely notice it, because we are used to diff-ing test results. So we would see some PASSes dispappear for no good reason and look into it. But I find it worrysome for two reasons: 1. Scripts that analyze regressions (such as the one on the buildbot) may only look for new FAILs or new ERRORs. It would probably miss this. 2. Imagine that we one day have a testsuite that runs cleanly (some people might already run subsets of the testsuite and expect it to all pass), we would just run the testsuite and check that there are no fails. It would be easy to miss something like this. In case of internal error, I suggest making `runto` emit a FAIL even if `no-message` was passed. This is different from other failure modes that might be expected (whchi rightfully cause the test to simply be skipped). An internal error is always bad, so if it happens it should noisily fail. gdb/testsuite/ChangeLog: * lib/gdb.exp (runto): Always emit fail on internal error. Change-Id: I6e6faed4868ea821541a23042b2d01c30058b0d3
2020-08-24gdb: add infrun_debug_printf macroSimon Marchi4-4/+11
Introduce this macro to print debug statements in the infrun.c file, same idea as what was done in 9327494e0eeb ("gdb: add linux_nat_debug_printf macro"). Although in this case, there are places outside infrun.c that print debug statements if debug_infrun is set. So the macro has to be declared in the header file, so that it can be used in these other files. Note one special case. In stop_all_threads, I've used an explicit if (debug_infrun) infrun_debug_printf_1 ("stop_all_threads", "done"); for the message in the SCOPE_EXIT. Otherwise, the message appears like this: [infrun] operator(): done Until we find a better solution for extracting a meaningful function name for lambda functions, I think it's fine to handle these special cases manually, they are quite rare. Some tests need to be updated, because they rely on some infrun debug statements. gdb/ChangeLog: * infrun.h (infrun_debug_printf_1): New function declaration. (infrun_debug_printf): New macro. * infrun.c (infrun_debug_printf_1): Use infrun_debug_printf throughout. (infrun_debug_printf): New function. * breakpoint.c (should_be_inserted): Use infrun_debug_printf. (handle_jit_event): Likewise. gdb/testsuite/ChangeLog: * gdb.base/gdb-sigterm.exp (do_test): Update expected regexp. * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Likewise. * gdb.threads/stepi-random-signal.exp: Likewise. Change-Id: I66433c8a9caa64c8525ab57c593022b9d1956d5c
2020-08-20gdb: fix typo "breapoint" -> "breakpoint"Tankut Baris Aktemur3-2/+7
gdb/ChangeLog: 2020-08-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infrun.c (process_event_stop_test): Fix typo "breapoint". gdb/testsuite/ChangeLog: 2020-08-20 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/print-file-var.exp: Fix typo "breapoint". * gdb.trace/strace.exp: Ditto.
2020-08-20Fix for incorrect breakpoint set in case of flang compiled binaryAlok Kumar Sharma2-2/+11
Currently, GDB is not able to set a breakpoint at subprogram post prologue for flang generated binaries. This is due to clang having two line notes one before and another after the prologue. Now the end of prologue is determined using symbol table, which was the way for clang generated binaries already. Since clang and flang both share same back-end it is true for flang as well. gdb/ChangeLog * amd64-tdep.c (amd64_skip_prologue): Using symbol table to find the end of prologue for flang compiled binaries. * arm-tdep.c (arm_skip_prologue): Likewise. * i386-tdep.c (i386_skip_prologue): Likewise. * producer.c (producer_is_llvm): New function. (producer_parsing_tests): Added new tests for clang/flang. * producer.h (producer_is_llvm): New declaration. gdb/testsuite/ChangeLog * gdb.fortran/vla-type.exp: Skip commands not required for the Flang compiled binaries after prologue fix.
2020-08-17Update xfail pattern in gdb.rust/simple.expTom Tromey2-1/+8
In PR rust/26197, Tom de Vries notes that the variant part rewrite caused some regressions for the Rust compiler he has. This compiler is unusual in that it combines a relatively recent rustc with a relatively old LLVM -- so variant parts are not emitted using DWARF. Most of the bugs in that PR were already fixed by earlier patches, but some lingered. After some research we found that some of these never did work -- which is consistent with the investigations we did into the debug info -- but instead were xfail'd. This patch updates the xfails to cope with the new output. (After this, just one failure remains.) Tom de Vries tested this using his rustc and suggested a fix that appears in this version. gdb/testsuite/ChangeLog 2020-08-17 Tom de Vries <tdevries@suse.de> Tom Tromey <tromey@adacore.com> PR rust/26197: * gdb.rust/simple.exp (xfail_pattern): Update for new failure.
2020-08-17Fix MI crash with Ada string accessTom Tromey5-0/+145
I happened to notice that using -var-create at a certain spot in an Ada program caused a crash. This happens because ada_get_decoded_value can return NULL -- in particular, deeper in the code it can hit this return in ada_type_of_array: descriptor = desc_bounds (arr); if (value_as_long (descriptor) == 0) return NULL; This patch avoids the crash by handling this NULL return. gdb/ChangeLog 2020-08-17 Tom Tromey <tromey@adacore.com> * ada-varobj.c (ada_varobj_decode_var): Handle case where ada_get_decoded_value returns NULL. gdb/testsuite/ChangeLog 2020-08-17 Tom Tromey <tromey@adacore.com> * gdb.ada/mi_var_access.exp: New file. * gdb.ada/mi_var_access/mi_access.adb: New file. * gdb.ada/mi_var_access/pck.adb: New file. * gdb.ada/mi_var_access/pck.ads: New file.
2020-08-16[gdb/testsuite] Add gdb.base/eh_return.expTom de Vries3-0/+151
In PR25350, an internal error was reported: ... (gdb) break *eh2+0x7e Breakpoint 1 at 0x13e2: file small.c, line 38. (gdb) run Starting program: a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Breakpoint 1, 0x00005555555553e2 in eh2 ( frame.c:558: internal-error: frame_id get_frame_id(frame_info*): \ Assertion `stashed' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ... The internal error does not reproduce after recent commit 547ce8f00b "[gdb/backtrace] Fix printing of fortran string args". Add the corresponding test-case as regression test, given that the code is rather atypical. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-08-16 Tom de Vries <tdevries@suse.de> PR gdb/25350 * gdb.base/eh_return.c: New test. * gdb.base/eh_return.exp: New file.
2020-08-15[gdb/testsuite] Fix charlen type in mixed-lang-stack.cTom de Vries2-1/+14
In gdb.fortran/mixed-lang-stack.f90, we have fortran function mixed_func_1d: ... subroutine mixed_func_1d(a, b, c, d, str) use, intrinsic :: iso_c_binding, only: c_int, c_float, c_double use, intrinsic :: iso_c_binding, only: c_float_complex implicit none integer(c_int) :: a real(c_float) :: b real(c_double) :: c complex(c_float_complex) :: d character(len=*) :: str ... which we declare in C in gdb.fortran/mixed-lang-stack.c like this: ... extern void mixed_func_1d_ (int *, float *, double *, complex float *, char *, size_t); ... The fortran string parameter str is passed as a char *, and an additional argument str_ for the string length. The type used for the string length argument is size_t, but for gcc 7 and earlier, the actual type is int instead ( see https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html ). Fix this by declaring the string length type depending on the gcc version: ... #if !defined (__GNUC__) || __GNUC__ > 7 typedef size_t fortran_charlen_t; #else typedef int fortran_charlen_t; ... Tested on x86_64-linux, with gcc-7 and gcc-8. gdb/testsuite/ChangeLog: 2020-08-15 Tom de Vries <tdevries@suse.de> * gdb.fortran/mixed-lang-stack.c (fortran_charlen_t): New type. (mixed_func_1d_): Use fortran_charlen_t in decl.
2020-08-15[gdb/backtrace] Fix printing of fortran string argsTom de Vries2-13/+23
When running test-case gdb.fortran/mixed-lang-stack.exp, it passes, but we find in gdb.log: ... (gdb) bt^M ... #7 0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \ e=<error reading variable: value requires 140737488341744 bytes, which \ is more than max-value-size>, g=..., _e=6) at mixed-lang-stack.f90:87^M ... while a bit later in gdb.log, we have instead for the same frame (after adding a gdb_test_no_output "set print frame-arguments all" to prevent getting "e=..."): ... (gdb) up^M #7 0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \ e='abcdef', g=( a = 1.5, b = 2.5 ), _e=6) at mixed-lang-stack.f90:87^M ... The difference is that in the latter case, we print the frame while it's selected, while in the former, it's not. The problem is that while trying to resolve the dynamic type of e in resolve_dynamic_type, we call dwarf2_evaluate_property with a frame == NULL argument, and then use the selected frame as the context in which to evaluate the dwarf property, effectively evaluating a DW_OP_fbreg operation in the wrong frame context. Fix this by temporarily selecting the frame of which we're trying to print the arguments in print_frame_args, borrowing code from print_frame_local_vars that was added to fix a similar issue in commit 16c3b12f19 "error/internal-error printing local variable during "bt full". Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-15 Tom de Vries <tdevries@suse.de> PR backtrace/26390 * stack.c (print_frame_args): Temporarily set the selected frame to FRAME while printing the frame's arguments. gdb/testsuite/ChangeLog: 2020-08-15 Tom de Vries <tdevries@suse.de> PR backtrace/26390 * gdb.fortran/mixed-lang-stack.exp: Call bt with -frame-arguments all. Update expected pattern.
2020-08-13Add skip_fortran_tests to more Fortran testcasesPedro Alves18-1/+56
This adds missing skip_fortran_tests checks to Fortran testcases, using the exact same pattern the existing files that do check it use. gdb/testsuite/ChangeLog: * gdb.fortran/complex.exp: Check skip_fortran_tests. * gdb.fortran/library-module.exp: Likewise. * gdb.fortran/logical.exp: Likewise. * gdb.fortran/module.exp: Likewise. * gdb.fortran/print_type.exp: Likewise. * gdb.fortran/vla-alloc-assoc.exp: Likewise. * gdb.fortran/vla-datatypes.exp: Likewise. * gdb.fortran/vla-history.exp: Likewise. * gdb.fortran/vla-ptr-info.exp: Likewise. * gdb.fortran/vla-ptype-sub.exp: Likewise. * gdb.fortran/vla-ptype.exp: Likewise. * gdb.fortran/vla-sizeof.exp: Likewise. * gdb.fortran/vla-type.exp: Likewise. * gdb.fortran/vla-value-sub-arbitrary.exp: Likewise. * gdb.fortran/vla-value-sub-finish.exp: Likewise. * gdb.fortran/vla-value-sub.exp: Likewise. * gdb.fortran/vla-value.exp: Likewise.
2020-08-13Add skip_ada_tests to more Ada testcasesPedro Alves145-1/+436
This adds missing skip_ada_tests checks to Ada testcases, using the exact same pattern the existing files that do check it use. gdb/testsuite/ChangeLog: * gdb.ada/access_tagged_param.exp: Check skip_ada_tests. * gdb.ada/access_to_packed_array.exp: Likewise. * gdb.ada/access_to_unbounded_array.exp: Likewise. * gdb.ada/addr_arith.exp: Likewise. * gdb.ada/arr_acc_idx_w_gap.exp: Likewise. * gdb.ada/arr_arr.exp: Likewise. * gdb.ada/arr_enum_idx_w_gap.exp: Likewise. * gdb.ada/array_bounds.exp: Likewise. * gdb.ada/array_of_variable_length.exp: Likewise. * gdb.ada/array_ptr_renaming.exp: Likewise. * gdb.ada/array_subscript_addr.exp: Likewise. * gdb.ada/arraydim.exp: Likewise. * gdb.ada/arrayparam.exp: Likewise. * gdb.ada/arrayptr.exp: Likewise. * gdb.ada/assign_1.exp: Likewise. * gdb.ada/assign_arr.exp: Likewise. * gdb.ada/atomic_enum.exp: Likewise. * gdb.ada/attr_ref_and_charlit.exp: Likewise. * gdb.ada/bad-task-bp-keyword.exp: Likewise. * gdb.ada/bias.exp: Likewise. * gdb.ada/boolean_expr.exp: Likewise. * gdb.ada/bp_c_mixed_case.exp: Likewise. * gdb.ada/bp_enum_homonym.exp: Likewise. * gdb.ada/bp_inlined_func.exp: Likewise. * gdb.ada/bp_on_var.exp: Likewise. * gdb.ada/bp_range_type.exp: Likewise. * gdb.ada/bp_reset.exp: Likewise. * gdb.ada/call_pn.exp: Likewise. * gdb.ada/catch_assert_if.exp: Likewise. * gdb.ada/catch_ex.exp: Likewise. * gdb.ada/catch_ex_std.exp: Likewise. * gdb.ada/char_enum.exp: Likewise. * gdb.ada/char_param.exp: Likewise. * gdb.ada/complete.exp: Likewise. * gdb.ada/cond_lang.exp: Likewise. * gdb.ada/convvar_comp.exp: Likewise. * gdb.ada/dgopt.exp: Likewise. * gdb.ada/disc_arr_bound.exp: Likewise. * gdb.ada/display_nested.exp: Likewise. * gdb.ada/dot_all.exp: Likewise. * gdb.ada/dyn_loc.exp: Likewise. * gdb.ada/dyn_stride.exp: Likewise. * gdb.ada/excep_handle.exp: Likewise. * gdb.ada/expr_delims.exp: Likewise. * gdb.ada/expr_with_funcall.exp: Likewise. * gdb.ada/exprs.exp: Likewise. * gdb.ada/fin_fun_out.exp: Likewise. * gdb.ada/fixed_cmp.exp: Likewise. * gdb.ada/formatted_ref.exp: Likewise. * gdb.ada/frame_arg_lang.exp: Likewise. * gdb.ada/frame_args.exp: Likewise. * gdb.ada/fullname_bp.exp: Likewise. * gdb.ada/fun_addr.exp: Likewise. * gdb.ada/fun_in_declare.exp: Likewise. * gdb.ada/fun_overload_menu.exp: Likewise. * gdb.ada/fun_renaming.exp: Likewise. * gdb.ada/funcall_char.exp: Likewise. * gdb.ada/funcall_param.exp: Likewise. * gdb.ada/funcall_ptr.exp: Likewise. * gdb.ada/funcall_ref.exp: Likewise. * gdb.ada/homonym.exp: Likewise. * gdb.ada/info_addr_mixed_case.exp: Likewise. * gdb.ada/info_auto_lang.exp: Likewise. * gdb.ada/info_exc.exp: Likewise. * gdb.ada/info_types.exp: Likewise. * gdb.ada/int_deref.exp: Likewise. * gdb.ada/interface.exp: Likewise. * gdb.ada/iwide.exp: Likewise. * gdb.ada/lang_switch.exp: Likewise. * gdb.ada/length_cond.exp: Likewise. * gdb.ada/maint_with_ada.exp: Likewise. * gdb.ada/mi_catch_assert.exp: Likewise. * gdb.ada/mi_catch_ex.exp: Likewise. * gdb.ada/mi_catch_ex_hand.exp: Likewise. * gdb.ada/mi_dyn_arr.exp: Likewise. * gdb.ada/mi_ex_cond.exp: Likewise. * gdb.ada/mi_exc_info.exp: Likewise. * gdb.ada/mi_interface.exp: Likewise. * gdb.ada/mi_prot.exp: Likewise. * gdb.ada/mi_ref_changeable.exp: Likewise. * gdb.ada/mi_string_access.exp: Likewise. * gdb.ada/mi_task_arg.exp: Likewise. * gdb.ada/mi_task_info.exp: Likewise. * gdb.ada/mi_var_array.exp: Likewise. * gdb.ada/mi_var_union.exp: Likewise. * gdb.ada/mi_variant.exp: Likewise. * gdb.ada/minsyms.exp: Likewise. * gdb.ada/mod_from_name.exp: Likewise. * gdb.ada/nested.exp: Likewise. * gdb.ada/null_array.exp: Likewise. * gdb.ada/optim_drec.exp: Likewise. * gdb.ada/out_of_line_in_inlined.exp: Likewise. * gdb.ada/packed_array_assign.exp: Likewise. * gdb.ada/packed_tagged.exp: Likewise. * gdb.ada/pp-rec-component.exp: Likewise. * gdb.ada/print_chars.exp: Likewise. * gdb.ada/print_pc.exp: Likewise. * gdb.ada/ptr_typedef.exp: Likewise. * gdb.ada/ptype_arith_binop.exp: Likewise. * gdb.ada/ptype_array.exp: Likewise. * gdb.ada/ptype_field.exp: Likewise. * gdb.ada/ptype_tagged_param.exp: Likewise. * gdb.ada/ptype_union.exp: Likewise. * gdb.ada/py_range.exp: Likewise. * gdb.ada/py_taft.exp: Likewise. * gdb.ada/rdv_wait.exp: Likewise. * gdb.ada/rec_comp.exp: Likewise. * gdb.ada/rec_return.exp: Likewise. * gdb.ada/ref_param.exp: Likewise. * gdb.ada/ref_tick_size.exp: Likewise. * gdb.ada/rename_subscript_param.exp: Likewise. * gdb.ada/repeat_dyn.exp: Likewise. * gdb.ada/same_component_name.exp: Likewise. * gdb.ada/same_enum.exp: Likewise. * gdb.ada/scalar_storage.exp: Likewise. * gdb.ada/set_wstr.exp: Likewise. * gdb.ada/small_reg_param.exp: Likewise. * gdb.ada/str_binop_equal.exp: Likewise. * gdb.ada/str_ref_cmp.exp: Likewise. * gdb.ada/str_uninit.exp: Likewise. * gdb.ada/sub_variant.exp: Likewise. * gdb.ada/sym_print_name.exp: Likewise. * gdb.ada/taft_type.exp: Likewise. * gdb.ada/tagged.exp: Likewise. * gdb.ada/tagged_access.exp: Likewise. * gdb.ada/task_bp.exp: Likewise. * gdb.ada/task_switch_in_core.exp: Likewise. * gdb.ada/tasks.exp: Likewise. * gdb.ada/tick_last_segv.exp: Likewise. * gdb.ada/tick_length_array_enum_idx.exp: Likewise. * gdb.ada/type_coercion.exp: Likewise. * gdb.ada/unc_arr_ptr_in_var_rec.exp: Likewise. * gdb.ada/unchecked_union.exp: Likewise. * gdb.ada/uninitialized_vars.exp: Likewise. * gdb.ada/var_arr_attrs.exp: Likewise. * gdb.ada/var_arr_typedef.exp: Likewise. * gdb.ada/var_rec_arr.exp: Likewise. * gdb.ada/variant-record.exp: Likewise. * gdb.ada/variant.exp: Likewise. * gdb.ada/variant_record_packed_array.exp: Likewise. * gdb.ada/varsize_limit.exp: Likewise. * gdb.ada/whatis_array_val.exp: Likewise. * gdb.ada/widewide.exp: Likewise. * gdb.ada/win_fu_syms.exp: Likewise.
2020-08-12Fix duplicate label in gdb.dwarf2/dw2-op-out-param.SGary Benson2-8/+12
gdb.dwarf2/dw2-op-out-param.S contained a duplicate label, and failed to build with clang with the following error: gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.dwarf2/dw2-op-out-param.S:163:1: error: invalid symbol redefinition .Ltext5: ^ This commit renames the two labels as .Ltext5a and .Ltext5b, and updates all references appropriately. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-out-param.S (.Ltext5): Fix duplicate label.
2020-08-07gdb: fix whitespace issues in ChangeLogSimon Marchi1-1/+1
Change-Id: Iea4bd2096bb994ec4ea9145cbe316aa345e8c6db
2020-08-05gdb/testsuite: link some dwarf2 tests with nopieSimon Marchi6-6/+7
I noticed some gdb.dwarf2 tests not running on my machine because of this: Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/dw2-single-line-discriminators.exp ... gdb compile failed, /usr/bin/ld: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-single-line-discriminators/dw2-single-line-discriminators0.o: relocation R_X86_64_32S against symbol `x' can not be used when making a PIE object; recompile with -fPIE collect2: error: ld returned 1 exit status We get this when the target toolchain produces position-independent executables by default. These tests are built from some assembly which produces some relocations incompatible with position-independent executables. Add `nopie` to the compilation flags of these tests to force the toolchain to produce non-position-independent executables. With this, the changed tests run successfully on my machine. gdb/ChangeLog: * gdb.dwarf2/clztest.exp, gdb.dwarf2/dw2-common-block.exp, gdb.dwarf2/dw2-dup-frame.exp, gdb.dwarf2/dw2-reg-undefined.exp, gdb.dwarf2/dw2-single-line-discriminators.exp, dw2-undefined-ret-addr.exp: Pass nopie to compilation options. Change-Id: Ie06c946f8e56a6030be247d1c57f416fa8b67e4c
2020-08-04gdb/testsuite: Use 'array unset' instead of just 'unset'Andrew Burgess2-1/+6
In the check-test-names.exp library 'unset' was being used to unset an array variable. Though this seems to work fine on tcl 8.6, it was discovered on a CentOS 7.8.2003 machine, running tcl 8.5, that this doesn't work and 'array unset' should be used instead. Using 'array unset' should work fine for newer and older versions of tcl (since 8.3, releases ~2000). gdb/testsuite/ChangeLog: * lib/check-test-names.exp (do_reset_vars): Use 'array unset' to unset the array variable.
2020-08-03[gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user rangeTom de Vries4-0/+136
When reading an exec with a .debug_line section containing a vendor-specific extended opcode, we get: ... $ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode During symbol reading: mangled .debug_line section ... and reading of the .debug_line section is abandoned. The vendor-specific extended opcode should be ignored, as specified in the DWARF standard (7.1 Vendor Extensibility). [ FWIW, vendor-specific standard opcodes are already ignored. ] Fix this by ignoring all vendor-specific extended opcodes. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * dwarf2/read.c (dwarf_decode_lines_1): Ignore DW_LNE_lo_user/DW_LNE_hi_user range. gdb/testsuite/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * lib/dwarf.exp (DW_LNE_user): New proc. * gdb.dwarf2/dw2-vendor-extended-opcode.c: New test. * gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.
2020-07-31gdb.base/coremaker2.c: Fix compilation problems for x86_64 -m32 multilibKevin Buettner2-7/+14
There are compilation warnings / errors when compiling coremaker2.c for the gdb.base/corefile2.exp tests. Here's the command to use on x86_64 linux: make check RUNTESTFLAGS="--target_board unix/-m32" \ TESTS="gdb.base/corefile2.exp" These are the warnings / errors - I've shortened the paths somewhat: gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main': gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 106 | addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 108 | if (addr <= (unsigned long long) buf_ro | ^ gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 109 | || addr >= (unsigned long long) buf_ro + sizeof (buf_ro)) | ^ gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 115 | mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ, | ^ gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 130 | addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 132 | if (addr <= (unsigned long long) buf_rw | ^ gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 133 | || addr >= (unsigned long long) buf_rw + sizeof (buf_rw)) | ^ gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 139 | mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ, | ^ These were fixed by changing unsigned long long to uintptr_t. Tested on either rawhide or Fedora 32 with architectures: x86_64, x86_64/-m32, aarch64, s390x, and ppc64le. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c: Change all uses of 'unsigned long long' to 'uintptr_t' (inttypes.h): Include.
2020-07-31Fix gdb.base/corefile2.exp test case for ppc64leKevin Buettner2-12/+22
It turns out that the recently added gdb.base/corefile2.exp test won't run on ppc64le linux. The test case fails the internal checks which ensure that a mmap'd region can be placed within the statically allocated regions buf_rw[] and buf_ro[]. ppc64le linux apparently has 64k pages, which is much larger than the 24k regions originally allocated for buf_rw[] and buf_ro[]. This patch increases the size of each region to 256 KiB. Tested on either rawhide or Fedora 32 for these architectures: x86_64, x86_64/-m32, ppc64le, aarch64, and s390x. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB. (C5_24k): Delete. (C5_8k, C5_64k, C5_256k): New macros. (buf_ro): Allocate 256 KiB of initialized data.
2020-07-30gdb/breakpoint: set the condition exp after parsing the condition successfullyTankut Baris Aktemur2-0/+95
In 'set_breakpoint_condition', GDB resets the condition expressions before parsing the condition input by the user. This leads to the problem of losing the condition expressions if the new condition does not parse successfully and is thus rejected. For instance: $ gdb ./test Reading symbols from ./test... (gdb) start Temporary breakpoint 1 at 0x114e: file test.c, line 4. Starting program: test Temporary breakpoint 1, main () at test.c:4 4 int a = 10; (gdb) break 5 Breakpoint 2 at 0x555555555155: file test.c, line 5. Now define a condition that would evaluate to false. Next, attempt to overwrite that with an invalid condition: (gdb) cond 2 a == 999 (gdb) cond 2 gibberish No symbol "gibberish" in current context. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000555555555155 in main at test.c:5 stop only if a == 999 It appears as if the bad condition is successfully rejected. But if we resume the program, we see that we hit the breakpoint although the condition would evaluate to false. (gdb) continue Continuing. Breakpoint 2, main () at test.c:5 5 a = a + 1; /* break-here */ Fix the problem by not resetting the condition expressions before parsing the condition input. Suppose the fix is applied. A similar problem could occur if the condition is valid, but has "junk" at the end. In this case, parsing succeeds, but an error is raised immediately after. It is too late, though; the condition expression is already updated. For instance: $ gdb ./test Reading symbols from ./test... (gdb) start Temporary breakpoint 1 at 0x114e: file test.c, line 4. Starting program: test Temporary breakpoint 1, main () at test.c:4 4 int a = 10; (gdb) break 5 Breakpoint 2 at 0x555555555155: file test.c, line 5. (gdb) cond 2 a == 999 (gdb) cond 2 a == 10 if Junk at end of expression (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000555555555155 in main at test.c:5 stop only if a == 999 (gdb) c Continuing. Breakpoint 2, main () at test.c:5 5 a = a + 1; /* break-here */ (gdb) We should not have hit the breakpoint because the condition would evaluate to false. Fix this problem by updating the condition expression of the breakpoint after parsing the input successfully and checking that there is no remaining junk. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Update the condition expressions after checking that the input condition string parses successfully and does not contain junk at the end. gdb/testsuite/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/condbreak-bad.exp: Extend the test with scenarios that attempt to overwrite an existing condition with a condition that fails parsing and also with a condition that parses fine but contains junk at the end.
2020-07-30gdb/breakpoint: do not update the condition string if parsing the condition ↵Tankut Baris Aktemur3-0/+69
fails The condition of a breakpoint can be set with the 'cond' command. If the condition has errors that make it problematic to evaluate, it appears like GDB rejects the condition, but updates the breakpoint's condition string, which causes incorrect/unintuitive behavior. For instance: $ gdb ./test Reading symbols from ./test... (gdb) break 5 Breakpoint 1 at 0x1155: file test.c, line 5. (gdb) cond 1 gibberish No symbol "gibberish" in current context. At this point, it looks like the condition was rejected. But "info breakpoints" shows the following: (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000001155 in main at test.c:5 stop only if gibberish Running the code gives the following behavior, where re-insertion of the breakpoint causes failures. (gdb) run Starting program: test warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context. [Inferior 1 (process 19084) exited normally] (gdb) This broken behavior occurs because GDB updates the condition string of the breakpoint *before* checking that it parses successfully. When parsing fails, the update has already taken place. Fix the problem by updating the condition string *after* parsing the condition. We get the following behavior when this patch is applied: $ gdb ./test Reading symbols from ./test... (gdb) break 5 Breakpoint 1 at 0x1155: file test.c, line 5. (gdb) cond 1 gibberish No symbol "gibberish" in current context. (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000001155 in main at test.c:5 (gdb) run Starting program: test Breakpoint 1, main () at test.c:5 5 a = a + 1; /* break-here */ (gdb) c Continuing. [Inferior 1 (process 15574) exited normally] (gdb) A side note: The problem does not occur if the condition is given at the time of breakpoint definition, as in "break 5 if gibberish", because the parsing of the condition fails during symtab-and-line creation, before the breakpoint is created. Finally, the code included the following comment: /* I don't know if it matters whether this is the string the user typed in or the decompiled expression. */ This comment did not make sense to me because the condition string is the user-typed input. The patch updates this comment, too. gdb/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (set_breakpoint_condition): Update the condition string after parsing the new condition successfully. gdb/testsuite/ChangeLog: 2020-07-30 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/condbreak-bad.c: New test. * gdb.base/condbreak-bad.exp: New file.
2020-07-30[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-4.8Tom de Vries3-6/+32
When running test-case gdb.fortran/info-modules.exp with gfortran 4.8.5, I get: ... FAIL: gdb.fortran/info-modules.exp: info module functions: \ check for entry 'info-types.f90', '35', \ 'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);' FAIL: gdb.fortran/info-modules.exp: info module functions -m mod1: \ check for entry 'info-types.f90', '35', \ 'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);' FAIL: gdb.fortran/info-modules.exp: info module variables: \ check for entry 'info-types.f90', '(35)?', \ 'Type m1t1 mod1::__def_init_mod1_M1t1;' FAIL: gdb.fortran/info-modules.exp: info module variables: \ check for entry 'info-types.f90', '(35)?', \ 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;' ... With gfortran 7.5.0, we have: ... $ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1" <286> DW_AT_name : __def_init_mod1_M1t1 <29f> DW_AT_name : __vtype_mod1_M1t1 <3de> DW_AT_name : __copy_mod1_M1t1 $ ... but with gfortran 4.8.5: ... $ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1" $ ... Fix this by allowing these module functions and variables to be missing. Tested on x86_64-linux with gcc 4.8.5 and gcc 7.5.0. gdb/testsuite/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> * lib/sym-info-cmds.exp (GDBInfoModuleSymbols::check_entry_1): Factor out of ... (GDBInfoModuleSymbols::check_entry): ... here. (GDBInfoModuleSymbols::check_optional_entry): New proc. * gdb.fortran/info-modules.exp: Use check_optional_entry for entries related to __def_init_mod1_M1t1 / __vtype_mod1_M1t1 / __copy_mod1_M1t1.
2020-07-30[gdb/testsuite] Fix gdb.fortran/ptype-on-functions.exp with gcc-4.8Tom de Vries2-2/+7
When running test-case gdb.fortran/ptype-on-functions.exp with gfortran 4.8.5, we run into: ... (gdb) ptype some_module::get_number^M type = integer(kind=4) (Type __class_some_module_Number)^M (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::get_number ptype some_module::set_number^M type = void (Type __class_some_module_Number, integer(kind=4))^M (gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype some_module::set_number ... The test-case pattern expects a "_t" suffix on "__class_some_module_Number". The difference is caused by a gcc commit 073afca6884 'class.c (gfc_build_class_symbol): Append "_t" to target class names to make the generated type names unique' which has been present since gcc 4.9.0. Fix the pattern by optionally matching the _t suffix. Tested on x86_64-linux, with gfortran 4.8.5 and 7.5.0. gdb/testsuite/ChangeLog: 2020-07-30 Tom de Vries <tdevries@suse.de> * gdb.fortran/ptype-on-functions.exp: Make "_t" suffix on "__class_some_module_Number_t" optional.
2020-07-29[gdb/testsuite] Fix captured_command_loop breakpoint in selftestsTom de Vries2-2/+8
When building gcc with CFLAGS/CXXFLAGS="-O2 -g", and running the regression tests, I run into the following FAILs: ... FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop FAIL: gdb.gdb/python-interrupts.exp: breakpoint in captured_command_loop FAIL: gdb.gdb/python-selftest.exp: breakpoint in captured_command_loop ... The problem is that when setting the breakpoint at captured_command_loop: ... (gdb) break captured_command_loop^M Breakpoint 1 at 0x4230ed: captured_command_loop. (2 locations)^M (gdb) FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop ... there are two breakpoint locations instead of one. This is due to PR26096 - "gdb sets breakpoint at cold clone": ... $ nm gdb | grep captured_command_loop| c++filt 0000000000659f20 t captured_command_loop() 00000000004230ed t captured_command_loop() [clone .cold] ... Work around this by allowing multiple breakpoint locations for captured_command_loop. Reg-tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * lib/selftest-support.exp (selftest_setup): Allow breakpoint at multiple locations.
2020-07-29[gdb/testsuite] Make gdb.dwarf2/dw2-line-number-zero.exp more robustTom de Vries2-2/+7
On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to problems in the prologue analyzer (filed as PR26310). Make the test-case more robust by avoiding to use the prologue analyzer: ... -gdb_breakpoint "bar1" +gdb_breakpoint "$srcfile:27" ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines rather than function name.
2020-07-28Demangle function names when disassemblingAndrew Burgess3-0/+104
Andrew Burgess pointed out a regression, which he described in PR symtab/26270: ================ After commit: commit bcfe6157ca288efed127c5efe21ad7924e0d98cf (refs/bisect/bad) Date: Fri Apr 24 15:35:01 2020 -0600 Use the linkage name if it exists The disassembler no longer demangles function names in its output. So we see things like this: (gdb) disassemble tree_insert Dump of assembler code for function _Z11tree_insertP4nodei: .... Instead of this: (gdb) disassemble tree_insert Dump of assembler code for function tree_insert(node*, int): .... This is because find_pc_partial_function now returns the linkage name rather than the demangled name. ================ This patch fixes the problem by introducing a new "overload" of find_pc_partial_function, which returns the general_symbol_info rather than simply the name. This lets the disassemble command choose which name to show. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> PR symtab/26270: * symtab.h (find_pc_partial_function_sym): Declare. * cli/cli-cmds.c (disassemble_command): Use find_pc_partial_function_sym. Check asm_demangle. * blockframe.c (cache_pc_function_sym): New global. (cache_pc_function_name): Remove. (clear_pc_function_cache): Update. (find_pc_partial_function_sym): New function, from find_pc_partial_function. (find_pc_partial_function): Rewrite using find_pc_partial_function_sym. gdb/testsuite/ChangeLog 2020-07-28 Andrew Burgess <andrew.burgess@embecosm.com> PR symtab/26270: * gdb.cp/disasm-func-name.cc: New file. * gdb.cp/disasm-func-name.exp: New file.
2020-07-28Fix bug in DW_OP_GNU_variable_value evaluationTom Tromey2-0/+7
A modified version of the gnat compiler (TBH I don't know if the modifications are relevant to this bug or not, but I figured I'd mention it) can generate a DWARF location expression like: <1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure) <1202> DW_AT_location : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13 (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop) <2><1279>: Abbrev Number: 9 (DW_TAG_structure_type) <127a> DW_AT_name : (indirect string, offset: 0x1a5a): p__logical_channel_t <127e> DW_AT_byte_size : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and) When evaluated, this gives: Incompatible types on DWARF stack In Jakub's original message about DW_OP_GNU_variable_value: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html .. it says: The intended behavior is that the debug info consumer computes the value of that referenced variable at the current PC, and if it can compute it and pushes the value as a generic type integer into the DWARF stack Instead, gdb is using the variable's type -- but this fails with some operations, like DW_OP_and, which expect the types to match. I believe what was intended was for the value to be cast to the DWARF "untyped" type, which is what this patch implements. This patch also updates varval.exp to exhibit the bug. gdb/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * dwarf2/expr.c (dwarf_expr_context::execute_stack_op) <DW_OP_GNU_variable_value>: Cast to address type. gdb/testsuite/ChangeLog 2020-07-28 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to 'varval' location.
2020-07-28gdb/python: make more use of RegisterDescriptorsAndrew Burgess2-1/+15
This commit unifies all of the Python register lookup code (used by Frame.read_register, PendingFrame.read_register, and gdb.UnwindInfo.add_saved_register), and adds support for using a gdb.RegisterDescriptor for register lookup. Currently the register unwind code (PendingFrame and UnwindInfo) allow registers to be looked up either by name, or by GDB's internal number. I suspect the number was added for performance reasons, when unwinding we don't want to repeatedly map from name to number for every unwind. However, this kind-of sucks, it means Python scripts could include GDB's internal register numbers, and if we ever change this numbering in the future users scripts will break in unexpected ways. Meanwhile, the Frame.read_register method only supports accessing registers using a string, the register name. This commit unifies all of the register to register-number lookup code in our Python bindings, and adds a third choice into the mix, the use of gdb.RegisterDescriptor. The register descriptors can be looked up by name, but once looked up, they contain GDB's register number, and so provide all of the performance benefits of using a register number directly. However, as they are looked up by name we are no longer tightly binding the Python API to GDB's internal numbering scheme. As we may already have scripts in the wild that are using the register numbers directly I have kept support for this in the API, but I have listed this method last in the manual, and I have tried to stress that this is NOT a good method to use and that users should use either a string or register descriptor approach. After this commit all existing Python code should function as before, but users now have new options for how to identify registers. gdb/ChangeLog: * python/py-frame.c: Remove 'user-regs.h' include. (frapy_read_register): Rewrite to make use of gdbpy_parse_register_id. * python/py-registers.c (gdbpy_parse_register_id): New function, moved here from python/py-unwind.c. Updated the return type, and also accepts register descriptor objects. * python/py-unwind.c: Remove 'user-regs.h' include. (pyuw_parse_register_id): Moved to python/py-registers.c. (unwind_infopy_add_saved_register): Update to use gdbpy_parse_register_id. (pending_framepy_read_register): Likewise. * python/python-internal.h (gdbpy_parse_register_id): Declare. gdb/testsuite/ChangeLog: * gdb.python/py-unwind.py: Update to make use of a register descriptor. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Update descriptions for PendingFrame.read_register and gdb.UnwindInfo.add_saved_register. (Frames In Python): Update description of Frame.read_register.
2020-07-28gdb: Add a find method for RegisterDescriptorIteratorAndrew Burgess2-0/+19
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class, this allows gdb.RegisterDescriptor objects to be looked up directly by register name rather than having to iterate over all registers. This will be of use for a later commit. I've documented the new function in the manual, but I don't think a NEWS entry is required here, as, since the last release, the whole register descriptor mechanism is new, and is already mentioned in the NEWS file. gdb/ChangeLog: * python/py-registers.c: Add 'user-regs.h' include. (register_descriptor_iter_find): New function. (register_descriptor_iterator_object_methods): New static global methods array. (register_descriptor_iterator_object_type): Add pointer to methods array. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: Add additional tests. gdb/doc/ChangeLog: * python.texi (Registers In Python): Document new find function.
2020-07-25gdb/fortran: resolve dynamic types when readjusting after an indirectionAndrew Burgess5-0/+186
After dereferencing a pointer (in value_ind) or following a reference (in coerce_ref) we call readjust_indirect_value_type to "fixup" the type of the resulting value object. This fixup handles cases relating to the type of the resulting object being different (a sub-class) of the original pointers target type. If we encounter a pointer to a dynamic type then after dereferencing a pointer (in value_ind) the type of the object created will have had its dynamic type resolved. However, in readjust_indirect_value_type, we use the target type of the original pointer to "fixup" the type of the resulting value. In this case, the target type will be a dynamic type, so the resulting value object, once again has a dynamic type. This then triggers an assertion later within GDB. The solution I propose here is that we call resolve_dynamic_type on the pointer's target type (within readjust_indirect_value_type) so that the resulting value is not converted back to a dynamic type. The test case is based on the original test in the bug report. gdb/ChangeLog: PR fortran/23051 PR fortran/26139 * valops.c (value_ind): Pass address to readjust_indirect_value_type. * value.c (readjust_indirect_value_type): Make parameter non-const, and add extra address parameter. Resolve original type before using it. * value.h (readjust_indirect_value_type): Update function signature and comment. gdb/testsuite/ChangeLog: PR fortran/23051 PR fortran/26139 * gdb.fortran/class-allocatable-array.exp: New file. * gdb.fortran/class-allocatable-array.f90: New file. * gdb.fortran/pointer-to-pointer.exp: New file. * gdb.fortran/pointer-to-pointer.f90: New file.
2020-07-25[gdb/symtab] Ignore zero line table entriesTom de Vries3-0/+208
The DWARF standard states for the line register in the line number information state machine the following: ... An unsigned integer indicating a source line number. Lines are numbered beginning at 1. The compiler may emit the value 0 in cases where an instruction cannot be attributed to any source line. ... So, it's possible to have a zero line number in the DWARF line table. This is currently not handled by GDB. The zero value is read in as any other line number, but internally the zero value has a special meaning: end-of-sequence, so the line table entry ends up having a different interpretation than intended in some situations. I've created a test-case where various aspects are tested, which has these 4 interesting tests. 1. Next-step through a zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next 2. Next-step through a zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next 3. Show source location at zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 4. Show source location at zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 And we have the following results: 8.3.1, 9.2: ... FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt field": ... PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting", master: FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243, where clang emits zero line numbers. The way to fix all tests is to make sure line number zero internally doesn't clash with special meaning values, and by handling it appropriately everywhere. That however looks too intrusive for the GDB 10 release. Instead, we decide to ensure defined behaviour for line number zero by ignoring it. This gives us back the test results from before commit d8cc8af6a1, fixing PR26243. We mark the FAILs for tests 3 and 4 as KFAILs. Test 4 was already failing for the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb 10 the cost for having defined behaviour. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line entries. gdb/testsuite/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * gdb.dwarf2/dw2-line-number-zero.c: New test. * gdb.dwarf2/dw2-line-number-zero.exp: New file.
2020-07-24[gdb/testsuite] Require gnatmake-8 for gdb.ada/mi_prot.expTom de Vries2-0/+8
With gcc-7, I run into: ... gcc -c -I./ -gnata -Isrc/gdb/testsuite/gdb.ada/mi_prot -g -lm -I- \ src/gdb/testsuite/gdb.ada/mi_prot/prot.adb^M prot.adb:21:04: info: "Obj_Type" is frozen here, aspects evaluated at this \ point^M prot.adb:23:09: visibility of aspect for "Obj_Type" changes after freeze \ point^M gnatmake: "src/gdb/testsuite/gdb.ada/mi_prot/prot.adb" compilation error^M compiler exited with status 1 ... FAIL: gdb.ada/mi_prot.exp: compilation prot.adb ... Fix this by requiring gnatmake-8 for this test-case. Tested on x86_64-linux, with gnatmake-7, gnatmake-8 and gnatmake-11. gdb/testsuite/ChangeLog: 2020-07-24 Tom de Vries <tdevries@suse.de> PR testsuite/26293 * gdb.ada/mi_prot.exp: Require gnatmake-8.
2020-07-23Don't touch frame_info objects if frame cache was reinitializedPedro Alves2-24/+98
This fixes yet another bug exposed by ASAN + multi-target.exp Running an Asan-enabled GDB against gdb.multi/multi-target.exp exposed yet another latent GDB bug. See here for the full log: https://sourceware.org/pipermail/gdb-patches/2020-July/170761.html As Simon described, the problem is: - We create a new frame_info object in restore_selected_frame (by calling find_relative_frame) - The frame is allocated on the frame_cache_obstack - In frame_unwind_try_unwinder, we try to find an unwinder for that frame - While trying unwinders, memory read fails because the remote target closes, because of "monitor exit" - That calls reinit_frame_cache (as shown above), which resets frame_cache_obstack - When handling the exception in frame_unwind_try_unwinder, we try to set some things on the frame_info object (like *this_cache, which in fact tries to write into frame_info::prologue_cache), but the frame_info object is no more, it went away with the obstack. Fix this by maintaining a frame cache generation counter. Then in exception handling code paths, don't touch frame objects if the generation is not the same as it was on entry. This commit generalizes the gdb.server/server-kill.exp testcase and reuses it to test the scenario in question. The new tests fail without the GDB fix. gdb/ChangeLog: * frame-unwind.c (frame_unwind_try_unwinder): On exception, don't touch THIS_CACHE/THIS_FRAME if the frame cache was cleared meanwhile. * frame.c (frame_cache_generation, get_frame_cache_generation): New. (reinit_frame_cache): Increment FRAME_CACHE_GENERATION. (get_prev_frame_if_no_cycle): On exception, don't touch PREV_FRAME/THIS_FRAME if the frame cache was cleared meanwhile. * frame.h (get_frame_cache_generation): Declare. gdb/testsuite/ChangeLog: * gdb.server/server-kill.exp (prepare): New, factored out from the top level. (kill_server): New. (test_tstatus, test_unwind_nosyms, test_unwind_syms): New. (top level) : Call test_tstatus, test_unwind_nosyms, test_unwind_syms.
2020-07-23gdb/disassembly: Update to handle non-statement addressesAndrew Burgess2-0/+210
After the introduction of support for non-statement addresses in the line table, the output for 'disassemble /m' can be broken in some cases. With the /m format disassembly GDB associates a set of addresses with each line, these addresses are then sorted and printed for each line. When the non-statement support was added GDB was incorrectly told to ignore non-statement instructions, and not add these to the result table. This means that these instructions are completely missing from the output. This commit removes the code that caused non-statement lines to be ignored. A result of this change is that GDB will now potentially include new line numbers in the 'disassemble /m' output, lines that previously were only in the line table as non-statement lines will now appear in the disassembly output. This feels like an improvement though. gdb/ChangeLog: * disasm.c (do_mixed_source_and_assembly_deprecated): Don't exclude non-statement entries. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-disasm-over-non-stmt.exp: New file.
2020-07-22Fix more bugs in gdb testglue wrapper handlingSandra Loosemore2-12/+22
In commit 24ac169ac5a918cd82b7485935f0c40a094c625e, this patch: 2020-02-21 Shahab Vahedi <shahab@synopsys.com> * lib/gdb.exp (gdb_wrapper_init): Reset "gdb_wrapper_initialized" to 0 if "wrapper_file" does not exist. attempted to fix problems finding the gdb test wrapper gdb_tg.o in some tests that cd to some non-default directory by rebuilding also the test wrapper in that directory. This had the side-effect of leaving these .o files in various places in the GDB source directory tree. Furthermore, while the tests that cd to some non-default directory cannot run on remote host, the code that was added to probe for the presence of the wrapper file was also specific to host == build. This patch reverts the problematic parts of that commit and replaces it with forcing use of an absolute (rather than relative) pathname to the .o file for linking when host == build. While debugging this patch, I also observed that use of the construct "[info exists gdb_wrapper_file]" was not reliable for detecting when that variable had been initialized by gdb_wrapper_init. I rewrote that so that the variable is always initialized and has a value of an empty string when no wrapper file is needed. 2020-07-22 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * lib/gdb.exp (gdb_wrapper_file, gdb_wrapper_flags): Initialize to empty string at top level. (gdb_wrapper_init): Revert check for file existence on build. Build the wrapper in its default place, not a build-specific location. When host == build, make the pathname absolute. (gdb_compile): Delete leftover declaration of gdb_wrapper_initialized. Check gdb_wrapper_file being an empty string instead of uninitialized.
2020-07-22New core file tests with mappings over existing program memoryKevin Buettner3-0/+340
This test case was inspired by Pedro's demonstration of a problem with my v2 patches. It can be found here: https://sourceware.org/pipermail/gdb-patches/2020-May/168826.html In a nutshell, my earlier patches could not handle the case in which a read-only mapping created with mmap() was created at an address used by other file-backed read-only memory in use by the process. This problem has been fixed (for Linux, anyway) by the commit "Use NT_FILE note section for reading core target memory". When I run this test without any of my recent corefile patches, I see these failures: FAIL: gdb.base/corefile2.exp: kernel core: print/x mbuf_ro[0]@4 FAIL: gdb.base/corefile2.exp: kernel core: print/x mbuf_ro[pagesize-4]@4 FAIL: gdb.base/corefile2.exp: kernel core: print/x mbuf_ro[-3]@6 FAIL: gdb.base/corefile2.exp: kernel core: print/x mbuf_rw[pagesize-3]@6 FAIL: gdb.base/corefile2.exp: kernel core: print/x mbuf_ro[pagesize-3]@6 FAIL: gdb.base/corefile2.exp: maint print core-file-backed-mappings FAIL: gdb.base/corefile2.exp: gcore core: print/x mbuf_ro[-3]@6 The ones involving mbuf_ro will almost certainly fail when run on non-Linux systems; I've used setup_xfail on those tests to prevent them from outright FAILing when not run on Linux. For a time, I had considered skipping these tests altogether when not run on Linux, but I changed my mind due to this failure... FAIL: gdb.base/corefile2.exp: print/x mbuf_rw[pagesize-3]@6 I think it *should* pass without my recent corefile patches. The fact that it doesn't is likely due to a bug in GDB. The following interaction with GDB demonstrates the problem: (gdb) print/x mbuf_rw[pagesize-3]@6 $1 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} (gdb) print/x mbuf_rw[pagesize]@3 $2 = {0x6b, 0x6b, 0x6b} The last three values in display of $1 should be the same as those shown by $2. Like this... (gdb) print/x mbuf_rw[pagesize-3]@6 $1 = {0x0, 0x0, 0x0, 0x6b, 0x6b, 0x6b} (gdb) print/x mbuf_rw[pagesize]@3 $2 = {0x6b, 0x6b, 0x6b} That latter output was obtained with the use of all of my current corefile patches. I see no failures on Linux when running this test with my current set of corefile patches. I tested 3 architectures: x86_64, s390x, and aarch64. I also tested on FreeBSD 12.1-RELEASE. I see the following results both with and without the current set of core file patches: # of expected passes 26 # of expected failures 8 Of particular interest is that I did *not* see the problematic mbuf_rw failure noted earlier (both with and without the core file patches). I still don't have an explanation for why this failure occurred on Linux. Prior to running the tests, I had hypothesized that I'd see this failure on FreeBSD too, but testing shows that this is not the case. Also of importance is that we see no FAILs with this test on FreeBSD which indicates that I XFAILed the correct tests. This version runs the interesting tests twice, once with a kernel created core file and another time with a gcore created core file. It also does a very minimal test of the new command "maint print core-file-backed-mappings". gdb/testsuite/ChangeLog: * gdb.base/corefile2.exp: New file. * gdb.base/coremaker2.exp: New file.
generated by cgit v1.1 at 2024-12-27 13:51:11 +0000