aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2020-12-21gdb, record: rephrase the 'not recording' error messageMarkus Metzger8-13/+26
When trying to use one of the record commands without having enabled recording first, GDB gives the error message: (gdb) record function-call-history No record target is currently active. Use one of the "target record-<TAB><TAB>" commands first. In the record help, however, we say: (gdb) help record record, rec Start recording. List of record subcommands: record btrace, record b -- Start branch trace recording. record delete, record del, record d -- Delete the rest of execution log and start recording it anew. record full -- Start full execution recording. record function-call-history -- Prints the execution history at function granularity. record goto -- Restore the program to its state at instruction number N. record instruction-history -- Print disassembled instructions stored in the execution log. record save -- Save the execution log to a file. record stop, record s -- Stop the record/replay target. Change the above error message to (gdb) record function-call-history No recording is currently active. Use the "record full" or "record btrace" command first. to align with the help text. gdb/ChangeLog: 2020-12-03 Markus Metzger <markus.t.metzger@intel.com> * record.c (require_record_target): Rephrase error message. (info_record_command): Likewise. gdb/testsuite/ChangeLog: 2020-12-03 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/enable.exp: Update error message. * gdb.btrace/multi-inferior.exp: Likewise. * gdb.btrace/reconnect.exp: Likewise. * gdb.python/py-record-btrace.exp: Likewise. * gdb.python/py-record-full.exp: Likewise.
2020-12-21gdb.texinfo: Document GMP as mandatory requirement to build GDBJoel Brobecker2-0/+13
gdb/doc/ChangeLog * gdb.texinfo (Requirements): Add GMP to list of requirements.
2020-12-20[gdb/testsuite] Add save_target_board_infoTom de Vries2-19/+61
Add a proc save_target_board_info, similar to save_vars, such that we can do: ... save_target_board_info { multilib_flags } { global board set board [target_info name] unset_board_info multilib_flags set_board_info multilib_flags "$override_multilib_flags" ... } ... and use it in gdb_compile_shlib. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-20 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (save_target_board_info): New proc. (gdb_compile_shlib): Use save_target_board_info.
2020-12-19[gdb/testsuite] Introduce supports_scalar_storage_order_attributeTom de Vries4-4/+63
Introduce support test procs: - supports_scalar_storage_order_attribute, and - supports_gnuc and use them in test-case gdb.base/endianity.exp. Tested on x86_64-linux with gcc-7.5.0, gcc-4.8.5, and clang 10.0.1. gdb/testsuite/ChangeLog: 2020-12-19 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (supports_scalar_storage_order_attribute) (supports_gnuc): New proc. * gdb.base/endianity.exp: Define TEST_SSO. Eliminate test_compiler_info calls. Add unsupported message. * gdb.base/endianity.c: Use TEST_SSO.
2020-12-19Don't compare types of enum fieldsHannes Domani7-1/+119
Comparing types of enum fields results in a crash, because they don't have a type. It can be reproduced by comparing the types of 2 instances of the same enum type in different objects: enum.h: enum e { zero, one, }; enum-1.c: #include <enum.h> int func(); enum e e1; int main() { return e1 + func(); } enum-2.c: #include <enum.h> enum e e2; int func() { return e2; } $ gcc -g -oenum enum-1.c enum-2.c $ gdb -q enum.exe Reading symbols from enum.exe... (gdb) py print(gdb.parse_and_eval("e1").type==gdb.parse_and_eval("e2").type) Thread 1 received signal SIGSEGV, Segmentation fault. [Switching to Thread 6184.0x1cc4] check_typedef (type=0x0) at C:/src/repos/binutils-gdb.git/gdb/gdbtypes.c:2745 2745 while (type->code () == TYPE_CODE_TYPEDEF) gdb/ChangeLog: 2020-12-19 Hannes Domani <ssbssa@yahoo.de> PR exp/27070 * gdbtypes.c (check_types_equal): Don't compare types of enum fields. gdb/testsuite/ChangeLog: 2020-12-19 Hannes Domani <ssbssa@yahoo.de> PR exp/27070 * gdb.python/compare-enum-type-a.c: New test. * gdb.python/compare-enum-type-b.c: New test. * gdb.python/compare-enum-type.exp: New file. * gdb.python/compare-enum-type.h: New test.
2020-12-19Warn about static libs vs. source-highlight only when necessaryBernd Edlinger3-12/+18
Avoid the error message when source-highlight is actually available. 2020-12-19 Bernd Edlinger <bernd.edlinger@hotmail.de> * configure.ac: Move the static libs vs. source-highlight error message to a better place. * configure: Regenerate.
2020-12-18Fix name of main_type field type in pretty printerHannes Domani2-1/+5
It was renamed from type to m_type. gdb/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * gdb-gdb.py.in: Fix main_type field name.
2020-12-18Remove erroneous 'a' in gdb.register_window_type documentationHannes Domani2-1/+5
gdb/doc/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python.texi (TUI Windows In Python): Remove erroneous 'a'.
2020-12-18Add address keyword to Value.format_stringHannes Domani6-1/+66
This makes it possible to disable the address in the result string: const char *str = "alpha"; (gdb) py print(gdb.parse_and_eval("str").format_string()) 0x404000 "alpha" (gdb) py print(gdb.parse_and_eval("str").format_string(address=False)) "alpha" gdb/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python/py-value.c (valpy_format_string): Implement address keyword. gdb/doc/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python.texi (Values From Inferior): Document the address keyword. gdb/testsuite/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-format-string.exp: Add tests for address keyword.
2020-12-18Fix accessing a method's fields from PythonHannes Domani4-0/+12
Considering this example: struct C { int func() { return 1; } } c; int main() { return c.func(); } Accessing the fields of C::func, when requesting the function by its type, works: (gdb) py print(gdb.parse_and_eval('C::func').type.fields()[0].type) C * const But when trying to do the same via a class instance, it fails: (gdb) py print(gdb.parse_and_eval('c')['func'].type.fields()[0].type) Traceback (most recent call last): File "<string>", line 1, in <module> TypeError: Type is not a structure, union, enum, or function type. Error while executing Python code. The difference is that in the former the function type is TYPE_CODE_FUNC: (gdb) py print(gdb.parse_and_eval('C::func').type.code == gdb.TYPE_CODE_FUNC) True And in the latter the function type is TYPE_CODE_METHOD: (gdb) py print(gdb.parse_and_eval('c')['func'].type.code == gdb.TYPE_CODE_METHOD) True So this adds the functionality for TYPE_CODE_METHOD as well. gdb/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python/py-type.c (typy_get_composite): Add TYPE_CODE_METHOD. gdb/testsuite/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-type.exp: Add tests for TYPE_CODE_METHOD.
2020-12-18gdb: define COFF file offsets with file_ptrJameson Nash2-15/+25
The arguments to these functions are file_ptr, so these declarations were accidentally implicitly down-casting them to signed int. This allows for reading files between 2 and 4 GB in size in my testing (I don't have a larger dll currently to test). These may not be natively supported by Windows, but can appear when using split-dwarf information. This solves a "can't get string table" error resulting from attempting to pass a negative offset to bfd_seek. I encountered this occuring while trying to use a debug file for libLLVM.dll, but searching online reveals at least one other person may have run into a similar problem with Firefox? https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CA+cU71k2bU0azQxjy4-77ynQj1O+TKmgtaTKe59n7Bjub1y7Tg@mail.gmail.com/ With this patch, the debug file appears to load successfully and I can see debug information in gdb for the library. gdb/ChangeLog: * coffread.c (linetab_offset): Change type to file_ptr. (linetab_size): Likewise. (enter_linenos): Change parameter type to file_ptr. (init_lineno): Likewise. (init_stringtab): Likewise. (coff_symtab_read): Likewise. (coff_symfile_read): Change variable types to file_ptr. Change-Id: I6ae3bf31efc51c826734ade6731ea6b1c32129f3
2020-12-18Run fixed_points.exp with -fgnat-encodings=minimalTom Tromey2-61/+78
This changes the test case gdb.ada/fixed_points.exp to also be run with -fgnat-encodings=minimal. This change pointed out that the test case had a few incorrect expected outputs; these are fixed as well. Note that the Overprecise_Object test only uses the non-legacy output with GCC trunk. gdb/testsuite/ChangeLog 2020-12-18 Tom Tromey <tromey@adacore.com> * gdb.ada/fixed_points.exp: Also run with -fgnat-encodings=minimal. Update expected output.
2020-12-17Remove a use of n_spacesTom Tromey2-1/+5
While removing printfi_filtered, I found a spot that used n_spaces where the now-ordinary "%*s" approach would do. This patch makes this change. Tested on x86-64 Fedora 32. gdb/ChangeLog 2020-12-17 Tom Tromey <tromey@adacore.com> * printcmd.c (print_variable_and_value): Don't use n_spaces.
2020-12-17Remove printfi_filtered and fprintfi_filteredTom Tromey11-215/+212
After seeing Simon's patch, I thought maybe it was finally time to remove printfi_filtered and fprintfi_filtered, in favor of using the "%*s" approach to indenting. In this patch I took the straightforward approach of always adding a leading "%*s", even when the format already started with "%s", to avoid the trickier form of: printf ("%*s", -indent, string) Regression tested on x86-64 Fedora 32. Let me know what you think. gdb/ChangeLog 2020-12-17 Tom Tromey <tromey@adacore.com> * gdbtypes.c (print_args, dump_fn_fieldlists, print_cplus_stuff) (print_gnat_stuff, print_fixed_point_type_info) (recursive_dump_type): Update. * go32-nat.c (go32_sysinfo, display_descriptor): Update. * c-typeprint.c (c_type_print_base_struct_union) (c_type_print_base_1): Update. * rust-lang.c (rust_internal_print_type): Update. * f-typeprint.c (f_language::f_type_print_base): Update. * utils.h (fprintfi_filtered, printfi_filtered): Remove. * m2-typeprint.c (m2_record_fields): Update. * p-typeprint.c (pascal_type_print_base): Update. * compile/compile-loc2c.c (push, pushf, unary, binary) (do_compile_dwarf_expr_to_c): Update. * utils.c (fprintfi_filtered, printfi_filtered): Remove.
2020-12-17gdb/doc: fix "show check range" command nameSimon Marchi2-1/+7
gdb/doc/ChangeLog: PR gdb/27088 * gdb.texinfo (Range Checking): Fix "show check range" command name. Change-Id: I0248ef76d205ac49ed71b813aafe3e630c2ffc2e
2020-12-16Change parameters to language_defn::post_parserTom Tromey6-17/+29
In the expression rewrite, Ada type resolution will be done at parse time rather than in a post-parse pass. At this point, language_defn::post_parser will be removed. However, for this to work, the information available to post_parser must be made available during the actual parse. This patch refactors this code slightly to make this possible. In particular, "void_context_p" is passed to the parser_state constructor, and the parser state is then passed to the post_parser method. gdb/ChangeLog 2020-12-16 Tom Tromey <tom@tromey.com> * rust-exp.y (rust_lex_tests): Update. * parser-defs.h (parser_state): Add void_p parameter. <void_context_p>: New member. * parse.c (parse_exp_in_context): Update. * language.h (language_defn::post_parser): Remove void_context_p, completing, tracker parameters. Add parser state. * ada-lang.c (ada_language::post_parser): Update.
2020-12-16Change void_context_p to boolTom Tromey4-6/+14
This patch changes void_context_p to bool, as a prerequisite to the change to post_parser that I submitted here: https://sourceware.org/pipermail/gdb-patches/2020-December/174080.html Tested by rebuilding. Note that nothing in-tree passes true here. I don't know why this is, but there is a use of this internally in AdaCore's tree. I will try to submit that patch, if it is needed. (And if not, I will come back around and remove this.) gdb/ChangeLog 2020-12-16 Tom Tromey <tom@tromey.com> * parse.c (parse_exp_1, parse_expression_for_completion): Update. (parse_exp_in_context): Change void_context_p to bool. * language.h (struct language_defn) <post_parser>: Change void_context_p to bool. * ada-lang.c (class ada_language) <post_parser>: Update.
2020-12-16gdb/testsuite: make some tests in gdb.base enable non-stop using GDBFLAGSSimon Marchi5-13/+27
For the same reason as explained in commit 7cb2893dfab1 ("gdb/testsuite: gdb.mi/mi-nonstop-exit.exp: enable non-stop using GDBFLAGS"). Note that the use of set GDBFLAGS "$GDBFLAGS ..." instead of append GDBFLAGS "..." is intentional. "append" is silent when appending to a non-existent variable. So if this code if moved to a proc (as is the case already for step-sw-breakpoint-adjust-pc.exp) and we forget to add "global GDBFLAGS", the flag won't be added to the global GDBFLAGS, and we won't actually enable non-stop, and it might go unnoticed. Using the "set" version will turn into an error if we forget the "global". This makes these test work correctly with native-extended-gdbserver. Some of them were silently failing because we runto_main is silent when it fails. gdb/testsuite/ChangeLog: * gdb.base/async-shell.exp: Enable non-stop through GDBFLAGS. * gdb.base/continue-all-already-running.exp: Likewise. * gdb.base/moribund-step.exp: Likewise. * gdb.base/step-sw-breakpoint-adjust-pc.exp: Likewise. Change-Id: I19ef05d07a0ec4a9c9476af2ba6e1ea1159ee437
2020-12-16[gdb/testsuite] Fix prompt regexp in batch-preserve-term-settings.expTom de Vries2-1/+5
On openSUSE Leap 15.2, when running test-case gdb.base/batch-preserve-term-settings.exp I get: ... spawn /bin/sh^M PS1="gdb-subshell$ "^M sh-4.4$ PS1="gdb-subshell$ "^M gdb-subshell$ PASS: gdb.base/batch-preserve-term-settings.exp: batch run: \ spawn shell ... but on Ubuntu 18.04.5, I get instead: ... spawn /bin/sh^M PS1="gdb-subshell$ "^M $ gdb-subshell$ FAIL: gdb.base/batch-preserve-term-settings.exp: batch run: \ spawn shell (timeout) ... Fix this by making the regexp recognize the second pattern as well. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-16 Tom de Vries <tdevries@suse.de> * gdb.base/batch-preserve-term-settings.exp:
2020-12-16[gdb] Print progress for debuginfodMartin Liska2-10/+21
Prints progress like: Downloading 4.89 MB separate debug info for /usr/lib64/libgcrypt.so.20. Downloading 1.10 MB separate debug info for /usr/lib64/liblzma.so.5. Downloading 1.31 MB separate debug info for /usr/lib64/liblz4.so.1. Downloading 0.96 MB separate debug info for /usr/lib64/libsmime3.so. [### ] Tested on x86_64-linux. ChangeLog: 2020-12-16 Martin Liska <mliska@suse.cz> Tom de Vries <tdevries@suse.de> * gdb/debuginfod-support.c (struct user_data): Remove has_printed field. Add meter field. (progressfn): Print progress using meter.
2020-12-16[gdb/cli] Add a progress meterTom Tromey7-0/+224
Add a progress meter. It's not used anywhere yet. gdb/ChangeLog: 2020-12-16 Tom Tromey <tom@tromey.com> Tom Tromey <tromey@redhat.com> Tom de Vries <tdevries@suse.de> * utils.h (get_chars_per_line): Declare. * utils.c (get_chars_per_line): New function. (fputs_maybe_filtered): Handle '\r'. * ui-out.h (ui_out::progress_meter): New class. (ui_out::progress, ui_out::do_progress_start) (ui_out::do_progress_notify, ui_out::do_progress_end): New methods. * ui-out.c (do_progress_end) (make_cleanup_ui_out_progress_begin_end, ui_out_progress): New functions. * mi/mi-out.h (mi_ui_out::do_progress_start) (mi_ui_out::do_progress_notify, mi_ui_out::do_progress_end): New methods. * cli-out.h (struct cli_ui_out) <do_progress_start, do_progress_notify, do_progress_end>: New methods. <enum meter_stat, struct cli_progress_info>: New. <m_meters>: New member. * cli-out.c (cli_ui_out::do_progress_start) (cli_ui_out::do_progress_notify, cli_ui_out::do_progress_end): New methods.
2020-12-16[gdb/testsuite] Fix shlib compilation with target board unix/-pie/-fPIETom de Vries2-1/+43
When running test-case gdb.base/info-shared.exp with target board unix/-pie/-fPIE, we run into: ... spawn -ignore SIGHUP gcc -fno-stack-protector \ outputs/gdb.base/info-shared/info-shared-solib1.c.o \ -fdiagnostics-color=never -fPIC -shared -Wl,-soname,info-shared-solib1.so \ -lm -fPIE -pie -o outputs/gdb.base/info-shared/info-shared-solib1.so^M ld: Scrt1.o: in function `_start':^M start.S:104: undefined reference to `main'^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 ... The intention of the -pie/-fPIE flags is to build and test PIE executables on platforms where that is not the default. However, the flags clash with the flags required to build shared libraries. Fix this by filtering out PIE-related flags out of the multilib_flags settings in compile_shared_lib. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-16 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_shlib_1): Factor out of ... (gdb_compile_shlib): ... here. Filter out PIE-related flags.
2020-12-16Record FPSR for SIMD/FP data instructionsLuis Machado2-1/+12
I noticed this failure in gdb.reverse/reverse-insn.exp: FAIL: gdb.reverse/insn-reverse.exp: adv_simd_vect_shift: compare registers on insn 0:fcvtzs s0, s0, #1 Turns out we're not recording changes to the FPSR. The SIMD/FP data instructions may set bits in the FPSR, so it needs to be recorded for proper reverse operations. gdb/ChangeLog: 2020-12-16 Luis Machado <luis.machado@linaro.org> * aarch64-tdep.c (aarch64_record_data_proc_simd_fp): Record FPSR.
2020-12-16Fix TBI handling for watchpointsLuis Machado5-12/+43
When inserting hw watchpoints, we take care of masking off the top byte of the address (and sign-extending it if needed). This guarantees we won't pass tagged addresses to the kernel via ptrace. However, from the kernel documentation on tagged pointers... "Non-zero tags are not preserved when delivering signals. This means that signal handlers in applications making use of tags cannot rely on the tag information for user virtual addresses being maintained for fields inside siginfo_t. One exception to this rule is for signals raised in response to watchpoint debug exceptions, where the tag information will be preserved." So the stopped data address after a hw watchpoint hit can be potentially tagged, and we don't handle this in GDB at the moment. This results in GDB missing a hw watchpoint hit and attempting to step over an unsteppable hw watchpoint, causing it to spin endlessly. The following patch fixes this by adjusting the stopped data address and adds some tests to expose the problem. gdb/ChangeLog: 2020-12-16 Luis Machado <luis.machado@linaro.org> * aarch64-linux-nat.c (aarch64_linux_nat_target::stopped_data_address): Handle the TBI. gdbserver/ChangeLog: 2020-12-16 Luis Machado <luis.machado@linaro.org> * linux-aarch64-low.cc (address_significant): New function. (aarch64_target::low_stopped_data_address): Handle the TBI. gdb/testsuite/ChangeLog: 2020-12-16 Luis Machado <luis.machado@linaro.org> * gdb.arch/aarch64-tagged-pointer.c (main): Add a few more pointer-based memory accesses. * gdb.arch/aarch64-tagged-pointer.exp: Exercise additional hw watchpoint cases.
2020-12-15gdb: multi-line support for "document" commandRae Kim5-7/+89
"document" command executed in python, gdb.execute("document <comname>\n...\nend\n"), will wait for user input. Python extension stops working from that point. multi-line suport was introduced in commit 56bcdbea2. But "document" support seem to be implemented. gdb/ChangeLog: 2020-12-02 Rae Kim <rae.kim@gmail.com> * cli/cli-script.c (do_document_command): Rename from document_command. Handle multi-line input. (multi_line_command_p): Handle document_control. (build_command_line): Likewise. (execute_control_command_1): Likewise. (process_next_line): Likewise. (document_command): Call do_document_command. * cli/cli-script.h (enum command_control_type): Add document_control. gdb/testsuite/ChangeLog: 2020-12-02 Rae Kim <rae.kim@gmail.com> * gdb.base/document.exp: New test. Change-Id: Ice262b980c05051de4c106af9f3fde5b2a6df6fe
2020-12-15Add expected type parameter to evaluate_expressionTom Tromey6-15/+26
While working on the expression rewrite, I found a few spots that called the internal functions of the expression evaluator, just to pass in an expected type. This patch adds a parameter to evaluate_expression so that these functions can avoid this dependency. Regression tested on x86-64 Fedora 28. gdb/ChangeLog 2020-12-15 Tom Tromey <tom@tromey.com> * stap-probe.c (stap_probe::evaluate_argument): Use evaluate_expression. * dtrace-probe.c (dtrace_probe::evaluate_argument): Use evaluate_expression. * value.h (evaluate_expression): Add expect_type parameter. * objc-lang.c (print_object_command): Call evaluate_expression. * eval.c (evaluate_expression): Add expect_type parameter.
2020-12-15Introduce expression::first_opcodeTom Tromey9-11/+31
This adds a new helper method, expression::first_opcode, that extracts the outermost opcode of an expression. This simplifies some patches in the expression rewrite series. Note that this patch requires the earlier patch to avoid manual dissection of OP_TYPE operations. 2020-12-15 Tom Tromey <tom@tromey.com> * varobj.c (varobj_create): Use first_opcode. * value.c (init_if_undefined_command): Use first_opcode. * typeprint.c (whatis_exp): Use first_opcode. * tracepoint.c (validate_actionline): Use first_opcode. (encode_actions_1): Use first_opcode. * stack.c (return_command): Use first_opcode. * expression.h (struct expression) <first_opcode>: New method. * eval.c (parse_and_eval_type): Use first_opcode. * dtrace-probe.c (dtrace_process_dof_probe): Use first_opcode.
2020-12-15Clean up arguments to evaluate_subexp_do_callTom Tromey4-19/+28
I noticed hat evaluate_subexp_do_call takes an array of arguments and a count -- but, unlike the usual convention, the count does not include the first element. This patch changes this function to match call_function_by_hand -- passing the callee separately, and using an array_view for the arguments. This makes it simpler to understand. Regression tested on x86-64 Fedora 28. gdb/ChangeLog 2020-12-15 Tom Tromey <tom@tromey.com> * f-lang.c (evaluate_subexp_f): Update. * expression.h (evaluate_subexp_do_call): Update. * eval.c (evaluate_subexp_do_call): Add callee parameter. Replace nargs, argvec with array_view. (evaluate_funcall): Update.
2020-12-15C++-ify Ada component interval handlingTom Tromey2-74/+43
The Ada component interval handling code, used for aggregate assignments, does a pre-pass over the sub-expressions so that it can size an array. For my expression rewrite, it was handy to C++-ify this. gdb/ChangeLog 2020-12-15 Tom Tromey <tom@tromey.com> * ada-lang.c (num_component_specs): Remove. (assign_aggregate): Update. (aggregate_assign_positional, aggregate_assign_from_choices) (aggregate_assign_others, add_component_interval): Change arguments.
2020-12-15Highlight deprecated commands using title styleTom Tromey4-7/+32
After Andrew's latest patch, I noticed that the deprecation warnings could use the (so-called) title style when printing command names. This patch implements this idea. gdb/ChangeLog 2020-12-15 Tom Tromey <tromey@adacore.com> * cli/cli-decode.c (deprecated_cmd_warning): Use title style for command names. gdb/testsuite/ChangeLog 2020-12-15 Tom Tromey <tromey@adacore.com> * gdb.base/style.exp: Add deprecation tests.
2020-12-15[gdb/testsuite] Handle PS1 quirk in gdb.base/multi-line-starts-subshell.expTom de Vries1-3/+3
On SLE-11, I run into: ... (gdb) if 1^M >shell HOME=/dev/null PS1="gdb-subshell$ " /bin/sh^M >end^M hostname:/dir> FAIL: gdb.base/multi-line-starts-subshell.exp: \ spawn subshell from multi-line (timeout) ... The problem is that the PS1 setting has no effect, due to a bug on older openSUSE/SLE version. The mechanism there is: - /etc/profile sets ENV=/etc/bash.bashrc - /bin/sh is started - /bin/sh executes ENV, in other words /etc/bash.bashrc - during the execution of /etc/bash.bashrc, PS1 is set unconditionally Fix this by setting PS1 after spawning the subshell. Tested on x86_64-linux. 2020-12-15 Tom de Vries <tdevries@suse.de> PR testsuite/26952 * gdb.base/multi-line-starts-subshell.exp: Set PS1 after spawning shell.
2020-12-14gdb/testsuite: fix typo in gdb_test_multiple docSimon Marchi2-1/+5
gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_multiple): Fix typo in doc. Change-Id: Ieb188b3382395ce951bfba5a5f25aaea0f89ebf9
2020-12-14Add form used for SPECIAL_expr as comment in testsuite Dwarf AssemblerMark Wielaard2-1/+16
Replace the "SPECIAL_expr" comment with either "DW_FORM_block" or "DW_FORM_exprloc" in the abbrev. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::_handle_attribute): Handle SPECIAL_expr specially, set attr_form_comment to the actual FORM string used.
2020-12-14Use DW_FORM_exprloc in testsuite Dwarf Assembler for DWARF version 4+.Mark Wielaard2-5/+16
Since DWARF version 4 expressions are represented by DW_FORM_exprloc instead of a block form. Support this in the testsuite Dwarf Assembler by setting the SPECIAL_expr form once we know the CU version. This doesn't change any testsuite results, it just makes the produced DWARF valid. gdb also accepts expressions in block form for DWARF version 4 and above, but this is technically incorrect. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::_read_constants): Don't set _constants(SPECIAL_expr) here, but set it... (Dwarf::cu): ...here based on _cu_version.
2020-12-14[gdb/testsuite] Don't pass -fPIC to gdb_compile_shlibTom de Vries12-23/+38
When running test-case gdb.base/info-shared.exp, I see in gdb.log: ... Executing on host: \ gcc ... -fPIC -fpic -c -o info-shared-solib1.c.o info-shared-solib1.c ... The -fPIC comes from the test-case: ... if { [gdb_compile_shlib $srcfile_lib1 $binfile_lib1 \ [list additional_flags=-fPIC]] != "" } { ... but the -fpic, which overrides the -fPIC comes from gdb_compile_shlib. The proc gdb_compile_shlib adds the -fpic or similar dependent on platform and compiler. However, in some cases it doesn't add anything, which is probably why all those test-case pass -fPIC. Fix this by removing -fPIC from all the calls to gdb_compile_shlib, and ensuring that gdb_compile_shlib takes care of adding it, if required. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_shlib): Make sure it's not necessary to pass -fPIC. * gdb.ada/catch_ex_std.exp: Don't pass -fPIC to gdb_compile_shlib. * gdb.base/break-probes.exp: Same. * gdb.base/ctxobj.exp: Same. * gdb.base/dso2dso.exp: Same. * gdb.base/global-var-nested-by-dso.exp: Same. * gdb.base/info-shared.exp: Same. * gdb.base/jit-reader-simple.exp: Same. * gdb.base/print-file-var.exp: Same. * gdb.base/skip-solib.exp: Same. * gdb.btrace/dlopen.exp: Same.
2020-12-14Do not manually dissect OP_TYPE operationsTom Tromey3-29/+15
Some code in GDB will examine the structure of an expression to see if it starts with OP_TYPE, and then proceed to extract the type by hand. There is no need to do this dissection manually. evaluate_type does the same thing via an "allowed" API. This patch changes such code to use evaluate_type. In two cases this simplifies the code. Regression tested on x86-64 Fedora 28. gdb/ChangeLog 2020-12-14 Tom Tromey <tom@tromey.com> * dtrace-probe.c (dtrace_process_dof_probe): Use value_type. * typeprint.c (whatis_exp): Always use evaluate_type. (maintenance_print_type): Likewise. Simplify.
2020-12-14[gdb/testsuite] Handle missing xz in gdb.base/gnu-debugdata.expTom de Vries2-1/+10
When running test-case gdb.base/gnu-debugdata.exp on SLE-11, I run into: ... FAIL: gdb.base/gnu-debugdata.exp: xz ... The fact that xz is not installed does not mean there's a fail, merely that the test is unsupported. Fix this by detecting the "spawn failed" reply in run_on_host and issuing UNSUPPORTED instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> PR testsuite/26963 * lib/gdb.exp (run_on_host): Declare test unsupported if spawn fails.
2020-12-14[gdb/testsuite] Handle no glibc debuginfo in gdb.base/solib-corrupted.expTom de Vries2-1/+17
When running test-case gdb.base/solib-corrupted.exp on SLE-11, I get: ... (gdb) PASS: gdb.base/solib-corrupted.exp: normal list p/x _r_debug->r_map->l_next = _r_debug->r_map^M '_r_debug' has unknown type; cast it to its declared type^M (gdb) FAIL: gdb.base/solib-corrupted.exp: make solibs looping ... The reason that _r_debug has unknown type is that glibc debuginfo is not installed. The test-case attempts to detect this but doesn't handle this particular error string. Fix this by adding the "unknown type" line to the regexp detecting missing glibc debuginfo. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> PR testsuite/26962 * gdb.base/solib-corrupted.exp: Handle "'_r_debug' has unknown type; cast it to its declared type".
2020-12-14[gdb/testsuite] Handle shell prompt in batch-preserve-term-settings.expTom de Vries2-3/+12
On SLE-11, I run into: ... FAIL: gdb.base/batch-preserve-term-settings.exp: batch run: spawn shell \ (timeout) ... The problem is that the shell prompt has PS1="\h:\w> ", but the test expects a shell prompt ending in a space preceded by either '$' or '#': ... set shell_prompt_re "\[$#\] " ... We could easily fix this by adding '>' to shell_prompt_re, but this wouldn't work for other PS1 setting. Fix this instead by setting the shell prompt to "gdb-subshell$ " (as in gdb.base/multi-line-starts-subshell.exp). Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-14 Tom de Vries <tdevries@suse.de> PR testsuite/26951 * gdb.base/batch-preserve-term-settings.exp: Use "gdb-subshell$ " as shell prompt.
2020-12-14Handle block-local names for AdaTom Tromey6-25/+92
GNAT can generate a mangled name with "B_N" (where N is a number) in the middle, like "hello__B_1__fourth.0". This is used for names local to a block. Multiple levels of block-local name can also occur, a possibility that was neglected by v1 of this patch. This patch changes gdb to handle these names. The wild name matcher is updated a straightforward way. The full matcher is rewritten. The hash function is updated to ensure that this works. This version does not seem to have the performance problems that affected v1. In particular, the previously-slow "bt" problem has been fixed. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * dictionary.c (language_defn::search_name_hash): Ignore "B". * ada-lang.c (advance_wild_match): Ignore "B". (full_match): Remove. (do_full_match): Rewrite. gdb/testsuite/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * gdb.ada/nested.exp: Add new tests. * gdb.ada/nested/hello.adb (Fourth, Fifth): New procedures.
2020-12-14Use exact match in get_var_valueTom Tromey2-3/+9
get_var_value is only used when an exact match is needed. This changes this function to ensure this sort of matching is done. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * ada-lang.c (get_var_value): Only consider exact matches.
2020-12-14Be more careful when rewriting thick pointer array typeTom Tromey4-13/+162
To handle thick pointers with -fgnat-encodings=minimal, gdb will rewrite the underlying array type to remove the bounds. However, if the same DWARF type is used both for a thick pointer and for an ordinary array, this will have the side effect of removing the bounds from the array. This breaks the printing of objects of this type. This patch fixes the problem by copying the array type, its range, and its bounds. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (rewrite_array_type): New function. (quirk_ada_thick_pointer_struct): Use rewrite_array_type. gdb/testsuite/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/ada-thick-pointer.exp: New file.
2020-12-14Handle fixed-point division by zeroTom Tromey4-0/+13
fixed_point_binop did not account for division by zero. This would lead to gdb getting SIGFPE and subsequently cause some test cases to hang. gdb/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * valarith.c (fixed_point_binop): Call error on division by zero. gdb/testsuite/ChangeLog 2020-12-14 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/dw2-fixed-point.exp: Add test for division by zero.
2020-12-13Constify parse_and_eval_typeTom Tromey4-3/+9
I noticed that the argumen to parse_and_eval_type could be "const". This patch implements this change. I wonder if this could be removed. It's only called via check_stub_method_group, which seems questionable to me. However, I didn't look into doing this. gdb/ChangeLog 2020-12-13 Tom Tromey <tom@tromey.com> * gdbtypes.c (safe_parse_type): Make argument const. * value.h (parse_and_eval_type): Make argument const. * eval.c (parse_and_eval_type): Make argument const.
2020-12-13[gdb/testsuite] Fix gdb.base/endianity.exp with gcc-4.8Tom de Vries2-4/+13
When running test-case gdb.base/endianity.exp using gcc-4.8, we get: ... (gdb) x/x &o.v^M 0x7fffffffd120: 0x00000004^M (gdb) XFAIL: gdb.base/endianity.exp: x/x &o.v x/xh &o.w^M 0x7fffffffd124: 0x0003^M (gdb) FAIL: gdb.base/endianity.exp: x/xh &o.w ... The gcc 4.8 compiler does not support the scalar_storage_order attribute, so the testcase is compiled without that attribute, and the expected results are different. Fix this by rather than xfailing, skipping the tests if the compiler does not support the scalar_storage_order attribute. Tested on x86_64-linux, with gcc-4.8, gcc-7, and clang-10. gdb/testsuite/ChangeLog: 2020-12-13 Tom de Vries <tdevries@suse.de> PR testsuite/26953 * gdb.base/endianity.exp: Skip tests requiring scalar_storage_order attribute support if compiler doesn't support it.
2020-12-13[gdb/testsuite] Handle ada in gdb_compile_shlibTom de Vries3-23/+45
The single test-case in the testsuite that creates an ada shared library is gdb.ada/catch_ex_std.exp. The test-case does use gdb_compile_shlib, but with a few tweaks that make sure things are properly handled for ada. Move the ada-specific code to gdb_compile_shlib, such that gdb_compile_sh can be used for ada shared libs without tweaks. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-13 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_shlib): Handle ada. * gdb.ada/catch_ex_std.exp: Use gdb_compile_shlib to compile from source to shared lib. Add ada to options.
2020-12-13[gdb/testsuite] Avoid gnatbind/gnatlink in gdb.ada/catch_ex_std.expTom de Vries2-48/+28
There's a single test-case in the testsuite that explicitly calls gnatbind and gnatlink: gdb.ada/catch_ex_std.exp. Instead, use gnatmake and pass specific gnatbind and gnatlink options using gnatmake passthrough options -bargs and -largs. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-13 Tom de Vries <tdevries@suse.de> * gdb.ada/catch_ex_std.exp: Use gnatmake -bargs and -largs instead of calling gnatbind and gnatlink.
2020-12-13gdb: new command 'maint flush dcache'Andrew Burgess8-0/+143
Add a new command to flush the dcache. gdb/ChangeLog: * NEWS: Mention new commands. * target-dcache.c: Add 'cli/cli-cmds.h' include. (maint_flush_dcache_command): New function. (_initialize_target_dcache): Create new 'maint flush dcache' command. gdb/doc/ChangeLog: * gdb.texinfo (Caching Target Data): Document 'maint flush dcache'. gdb/testsuite/ChangeLog: * gdb.base/dcache-flush.c: New file. * gdb.base/dcache-flush.exp: New file.
2020-12-13gdb: introduce new 'maint flush ' prefix commandAndrew Burgess17-17/+96
We currently have two flushing commands 'flushregs' and 'maint flush-symbol-cache'. I'm planning to add at least one more so I thought it might be nice if we bundled these together into one place. And so I created the 'maint flush ' command prefix. Currently there are two commands: (gdb) maint flush symbol-cache (gdb) maint flush register-cache Unfortunately, even though both of the existing flush commands are maintenance commands, I don't know how keen we about deleting existing commands for fear of breaking things in the wild. So, both of the existing flush commands 'maint flush-symbol-cache' and 'flushregs' are still around as deprecated aliases to the new commands. I've updated the testsuite to use the new command syntax, and updated the documentation too. gdb/ChangeLog: * NEWS: Mention new commands, and that the old commands are now deprecated. * cli/cli-cmds.c (maintenanceflushlist): Define. * cli/cli-cmds.h (maintenanceflushlist): Declare. * maint.c (_initialize_maint_cmds): Initialise maintenanceflushlist. * regcache.c: Add 'cli/cli-cmds.h' include. (reg_flush_command): Add header comment. (_initialize_regcache): Create new 'maint flush register-cache' command, make 'flushregs' an alias. * symtab.c: Add 'cli/cli-cmds.h' include. (_initialize_symtab): Create new 'maint flush symbol-cache' command, make old command an alias. gdb/doc/ChangeLog: * gdb.texinfo (Symbols): Document 'maint flush symbol-cache'. (Maintenance Commands): Document 'maint flush register-cache'. gdb/testsuite/ChangeLog: * gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...' commands. * gdb.base/killed-outside.exp: Likewise. * gdb.opt/inline-bt.exp: Likewise. * gdb.perf/gmonster-null-lookup.py: Likewise. * gdb.perf/gmonster-print-cerr.py: Likewise. * gdb.perf/gmonster-ptype-string.py: Likewise. * gdb.python/py-unwind.exp: Likewise.
2020-12-11gdb: improve the warning given for deprecated aliases with a prefixAndrew Burgess4-43/+59
Consider this GDB session: (gdb) define set xxx_yyy Type commands for definition of "set xxx_yyy". End with a line saying just "end". >echo in set xxx_yyy command\n >end (gdb) alias set qqq_aaa=set xxx_yyy (gdb) maintenance deprecate set qqq_aaa (gdb) set qqq_aaa Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated. No alternative known. in set xxx_yyy command (gdb) Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this to be wrong. I think the proper warning should read: (gdb) set qqq_aaa Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy', is deprecated. No alternative known. With the 'set' prefixes added and a comma before the final 'is deprecated'. That is what this patch does. The expected results are updated as needed. gdb/ChangeLog: * cli/cli-decode.c (deprecated_cmd_warning): Ignore the prefix result from lookup_cmd_composition_1, use the prefixes from both the command and the alias instead. (lookup_cmd_composition_1): Initial prefix command is the based on the search list being passed in. Simplify the logic for tracking the prefix command. Replace a use of alloca with a local std::string. gdb/testsuite/ChangeLog: * gdb.base/commands.exp: Update expected results.