aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-01-02gdb: fix typos in comments in target-float.cSimon Marchi2-2/+6
gdb/ChangeLog: * target-float.c: Fix typos. Change-Id: Ib65e90746d0a7c77c3fbead81139facb40b91977
2021-01-02Fix pretty printer of main_type.flds_bnds.boundsHannes Domani2-5/+10
In struct dynamic_prop the members kind and data were renamed to m_kind and m_data. And flag_upper_bound_is_count is actually in bounds directly, not in its high member. gdb/ChangeLog: 2021-01-02 Hannes Domani <ssbssa@yahoo.de> * gdb-gdb.py.in: Fix main_type.flds_bnds.bounds pretty printer.
2021-01-01Manual updates of copyright year range not covered by gdb/copyright.pyJoel Brobecker5-5/+13
gdb/ChangeLog: * gdbarch.sh: Update copyright year range. gdb/doc/ChangeLog: * gdb.texinfo, refcard.tex: Update copyright year range.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker5433-5432/+5436
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2021-01-01gdb/copyright.py: Also update sources in "gdbserver" and "gdbsupport"Joel Brobecker2-1/+8
This commit adjusts GDB's copyright.py script, following two past changes: - gdb/gdbserver/ being move to the toplevel directory; - gdb/common/ being renamed to gdbsupport/. gdb/ChangeLog: * copyright.py (get_update_list): Add "gdbserver" and "gdbsupport" to the list of directories to update.
2021-01-01Update copyright year in version message for gdb, gdbserver and gdbreplayJoel Brobecker2-1/+5
gdb/ChangeLog: * top.c (print_gdb_version): Update copyright year. gdbserver/ChangeLog: * server.cc (gdbserver_version): Update copyright year. * gdbreplay.cc (gdbreplay_version): Likewise.
2021-01-01Rotate gdb/ChangeLogJoel Brobecker3-18741/+18755
As a results of the rotation, this introduces a new file which needed to be added to DJGPP's fnchange.lst. gdb/ChangeLog * config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2020.
2020-12-31Update gdb.rust tests for Rust 1.49Tom Tromey2-4/+14
Rust 1.49 was released today, and it includes some library changes which caused some gdb.rust tests to fail. This patch adapts the test suite to the new output. I also verified that this continues to work with Rust 1.48. gdb/testsuite/ChangeLog 2020-12-31 Tom Tromey <tom@tromey.com> * gdb.rust/simple.exp: Update output for Rust 1.49.
2020-12-31Fix passing debug options for gccBernd Edlinger2-1/+5
Fix a bug in the test where we were missing "additional_flags=", causing -gstatement-frontiers not to be passed to the compiler. The issue was introduced in eb24648c453c28f2898fb599311ba004394a8b41 ("Fix gdb.cp/step-and-next-inline.exp with Clang"). gdb/testsuite: 2020-12-31 Bernd Edlinger <bernd.edlinger@hotmail.de> * gdb.cp/step-and-next-inline.exp: Fix test case.
2020-12-30gdb/testsuite: de-duplicate test names in gdb.python/py-frame-args.expSimon Marchi2-22/+30
Use with_test_prefix to de-duplicate test names. gdb/testsuite/ChangeLog: * gdb.python/py-frame-args.exp: De-duplicate test names. Change-Id: I5cc8bee692a0d071cb78258aca80ea642e00e7a8
2020-12-29Fix wrong method nameHannes Domani2-1/+5
The objects returned by FrameDecorator.frame_args need to implement a method named symbol, not argument. gdb/doc/ChangeLog: 2020-12-29 Hannes Domani <ssbssa@yahoo.de> * python.texi (Frame Decorator API): Fix method name.
2020-12-27Simplify MULTI_SUBSCRIPT implementationTom Tromey2-29/+12
The MULTI_SUBSCRIPT code in evaluate_subexp_standard has a comment saying that perhaps the EVAL_SKIP handling is incorrect. This patch simplifies this code. In particular, it precomputes all the indices in a separate loop and removes some complicated flow-control. Tested using the gdb.modula2 and gdb.dlang test suites, as these are the only parsers that emit MULTI_SUBSCRIPT. gdb/ChangeLog 2020-12-27 Tom Tromey <tom@tromey.com> * eval.c (evaluate_subexp_standard) <case MULTI_SUBSCRIPT>: Simplify.
2020-12-24gdb: avoid resolving dynamic properties for non-allocated arraysAndrew Burgess7-24/+240
In PR gdb/27059 an issue was discovered where GDB would sometimes trigger undefined behaviour in the form of signed integer overflow. The problem here is that GDB was reading random garbage from the inferior memory space, assuming this data was valid, and performing arithmetic on it. This bug raises an interesting general problem with GDB's DWARF expression evaluator, which is this: We currently assume that the DWARF expressions being evaluated are well formed, and well behaving. As an example, this is the expression that the bug was running into problems on, this was used as the expression for a DW_AT_byte_stride of a DW_TAG_subrange_type: DW_OP_push_object_address; DW_OP_plus_uconst: 88; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_mul Two values are read from the inferior and multiplied together. GDB should not assume that any value read from the inferior is in any way sane, as such the implementation of DW_OP_mul should be guarding against overflow and doing something semi-sane here. However, it turns out that the original bug PR gdb/27059, is hitting a more specific case, which doesn't require changes to the DWARF expression evaluator, so I'm going to leave the above issue for another day. In the test mentioned in the bug GDB is actually trying to resolve the dynamic type of a Fortran array that is NOT allocated. A non-allocated Fortran array is one that does not have any data allocated for it yet, and even the upper and lower bounds of the array are not yet known. It turns out that, at least for gfortran compiled code, the data fields that describe the byte-stride are not initialised until the array is allocated. This leads me to the following conclusion: GDB should not try to resolve the bounds, or stride information for an array that is not allocated (or not associated, a similar, but slightly different Fortran feature). Instead, each of these properties should be set to undefined if the array is not allocated (or associated). That is what this commit does. There's a new flag that is passed around during the dynamic array resolution. When this flag is true the dynamic properties are resolved using the DWARF expressions as they currently are, but when this flag is false the expressions are not evaluated, and instead the properties are set to undefined. gdb/ChangeLog: PR gdb/27059 * eval.c (evaluate_subexp_for_sizeof): Handle not allocated and not associated arrays. * f-lang.c (fortran_adjust_dynamic_array_base_address_hack): Don't adjust arrays that are not allocated/associated. * gdbtypes.c (resolve_dynamic_range): Update header comment. Add new parameter which is used to sometimes set dynamic properties to undefined. (resolve_dynamic_array_or_string): Update header comment. Add new parameter which is used to guard evaluating dynamic properties. Resolve allocated/associated properties first. gdb/testsuite/ChangeLog: PR gdb/27059 * gdb.dwarf2/dyn-type-unallocated.c: New file. * gdb.dwarf2/dyn-type-unallocated.exp: New file.
2020-12-24gdb: include allocated/associated properties in 'maint print type'Andrew Burgess2-0/+23
Adds the allocated and associated dynamic properties into the output of the 'maintenance print type' command. gdb/ChangeLog: * gdbtypes (recursive_dump_type): Include allocated and associated properties.
2020-12-24gdb/gdbtypes.h: Fix comparison of uninitialized valuesLancelot SIX2-3/+10
When called with an array type of unknown dimensions, is_scalar_type_recursive ended up comparing uninitialized values. This was picked up by the following compiler warning: CXX gdbtypes.o /binutils-gdb/gdb/gdbtypes.c: In function int is_scalar_type_recursive(type*): /binutils-gdb/gdb/gdbtypes.c:3670:38: warning: high_bound may be used uninitialized in this function [-Wmaybe-uninitialized] 3670 | return high_bound == low_bound && is_scalar_type_recursive (elt_type); | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /binutils-gdb/gdb/gdbtypes.c:3670:38: warning: low_bound may be used uninitialized in this function [-Wmaybe-uninitialized] This patch makes sure that when dealing with an array of unknown size (or an array of more than 1 element), is_scalar_type_recursive returns false. gdb/ChangeLog: * gdbtypes.c (is_scalar_type_recursive): Prevent comparison between uninitialized values. Change-Id: Ifc005ced166aa7a065fef3e652977bae67625bf4
2020-12-23Clarify language for the '?' packetAlex Bennée2-3/+8
Both QEMU and kgdb make the assumption that the '?' packet is only sent during the initial setup of a gdbstub connection. Both use that knowledge to reset breakpoints and ensure the gdbstub is in a clean-state on a resumed connection. This can cause confusion for others implementing clients that speak to gdbstub devices. To avoid that make the language clearer that this is a start-up query packet that you only expect to see once. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> gdb/doc/ChangeLog: * gdb.texinfo (Packets): Clarify language for ? packet. Change-Id: Iae25d3110fe28b8d2467704962a6889e55224ca5
2020-12-23gdb: remove some uses of LA_PRINT_STRINGAndrew Burgess6-21/+33
This commit removes some, but not all, uses of LA_PRINT_STRING. In this commit I've removed those uses where there is an obvious language object on which I can instead call the printstr method. In the remaining 3 uses it is harder to know if the correct thing is to call printstr on the current language, or on a specific language. Currently obviously, we always call on the current language (as that's what LA_PRINT_STRING does), and clearly this behaviour is good enough right now, but is it "right"? I've left them for now and will give them more thought in the future. gdb/ChangeLog: * expprint.c (print_subexp_standard): Replace uses of LA_PRINT_STRING. * f-valprint.c (f_language::value_print_inner): Likewise. * guile/scm-pretty-print.c (ppscm_print_string_repr): Likewise. * p-valprint.c (pascal_language::value_print_inner): Likewise. * python/py-prettyprint.c (print_string_repr): Likewise.
2020-12-23gdb: move rust_language into rust-lang.hAndrew Burgess4-281/+346
Move the rust_language class declaration into the rust-lang.h header file. This allows for the function implementations called directly in rust-lang.c and rust-exp.y without the need for trampoline functions. There should be no user visible changes after this commit. gdb/ChangeLog: * rust-exp.y (rust_parse): Rename to... (rust_language::parser): ...this. * rust-lang.c (-rust_printstr): Rename to... (rust_language::printstr): ...this. (rust_value_print_inner): Delete declaration. (val_print_struct): Rename to... (rust_language::val_print_struct): ...this. Update calls to member functions. (rust_print_enum): Rename to... (rust_language::print_enum): ...this. Update calls to member functions. (rust_value_print_inner): Rename to... (rust_language::value_print_inner): ...this. Update calls to member functions. (exp_descriptor_rust): Rename to... (rust_language::exp_descriptor_tab): ...this. (class rust_language): Move to rust-lang.h. (rust_language::language_arch_info): Implementation moved to here from class declaration. (rust_language::print_type): Likewise. (rust_language::emitchar): Likewise. (rust_language::is_string_type_p): Likewise. * rust-lang.h: Add 'demangle.h', 'language.h', 'value.h', and 'c-lang.h' includes. (rust_parse): Delete declaration. (class rust_language): Class declaration moved here from rust-lang.c.
2020-12-23gdb/objc: fix bug in objc_language::opcode_print_tableAndrew Burgess2-1/+6
In this commit: commit b7c6e27dbbbbe678b2e2f0bf617605e055e1b378 Date: Tue Aug 4 17:07:59 2020 +0100 gdb: Convert language_data::la_op_print_tab to a method A bug was introduced, the objc language now returns the wrong op_print table. Fixed in this commit. gdb/ChangeLog: * objc-lang.c (objc_language::opcode_print_table): Return objc_op_print_tab.
2020-12-23gdb: move pascal_language into p-lang.hAndrew Burgess6-436/+506
Move the pascal_language class declaration into the p-lang.h header file. This allows for the function implementations to be spread over the different p-*.c files without the need for global trampoline functions. As a consequence of this change many of the Pascal value and type printing helper functions have become member functions within the pascal_language class. There should be no user visible changes after this commit. gdb/ChangeLog: * p-exp.y (exp): Update call to pascal_is_string_type. (pascal_parse): Rename to... (pascal_language::parser): ...this. * p-lang.c (is_pascal_string_type): Rename to... (pascal_is_string_type): ...this. (pascal_one_char): Rename to... (pascal_language::print_one_char): ...this. (pascal_printchar): Rename to... (pascal_language::printchar): ...this. Update call to print_one_char member function. (pascal_op_print_tab): Rename to... (pascal_language::op_print_tab): ...this. (class pascal_language): Moved to p-lang.h. (pascal_language::language_arch_info): Function implementation moved out of class declaration. (pascal_language::printstr): Likewise. * p-lang.h (pascal_parse): Delete declaration. (pascal_is_string_type): Declare. (pascal_print_type): Delete declaration. (pascal_print_typedef): Delete declaration. (pascal_value_print_inner): Delete declaration. (pascal_value_print): Delete declaration. (pascal_type_print_method_args): Delete declaration. (is_pascal_string_type): Delete declaration. (pascal_printchar): Delete declaration. (pascal_builtin_types): Delete declaration. (pascal_type_print_base): Delete declaration. (pascal_type_print_varspec_prefix): Delete declaration. (class pascal_language): Moved here from p-lang.c. * p-typeprint.c (pascal_type_print_varspec_suffix): Delete declaration. (pascal_type_print_derivation_info): Delete declaration. (pascal_print_type): Rename to... (pascal_language::print_type): ...this. Update calls to member functions. (pascal_print_typedef): Rename to... (pascal_language::print_typedef): ...this. Update calls to member functions. (pascal_type_print_derivation_info): Rename to... (pascal_language::type_print_derivation_info): ...this. (pascal_type_print_method_args): Rename to... (pascal_language::type_print_method_args): ...this. (pascal_type_print_varspec_prefix): Rename to... (pascal_language::type_print_varspec_prefix): ...this. Update calls to member functions. (pascal_print_func_args): Rename to... (pascal_language::print_func_args): ...this. Update calls to member functions. (pascal_type_print_func_varspec_suffix): Rename to... (pascal_language::type_print_func_varspec_suffix): ...this. Update calls to member functions. (pascal_type_print_varspec_suffix): Rename to... (pascal_language::type_print_varspec_suffix): ...this. Update calls to member functions. (pascal_type_print_base): Rename to... (pascal_language::type_print_base): ...this. Update calls to member functions. * p-valprint.c (pascal_value_print_inner): Rename to... (pascal_language::value_print_inner): ...this. Update calls to member functions. (pascal_value_print): Rename to... (pascal_language::value_print): ...this. Update calls to member functions.
2020-12-23gdb: move go_language class declaration into header fileAndrew Burgess7-140/+161
Move the go_language class into go-lang.h, this allows us to have member functions implemented directly in the different go-*.c files instead of having to trampoline out to global functions. There should be no user visible changes after this commit. gdb/ChangeLog: * go-exp.y (go_parse): Rename to... (go_language::parser): ...this. * go-lang.c (go_demangle): Rename to... (go_language::demangle_symbol): ...this. (go_language::expression_ops): Implementation moved here out of class declaration. (go_op_print_tab): Rename to... (go_language::op_print_tab): ...this, update comment. (class go_language): Declaration moved to go-lang.h. (go_language::language_arch_info): Implementation moved here out of class declaration. * go-lang.h (go_parse): Delete declaration. (go_demangle): Delete declaration. (go_print_type): Delete declaration. (go_value_print_inner): Delete declaration. (class go_language): Declaration moved here from go-lang.c. * go-typeprint.c (go_print_type): Rename to... (go_language::print_type): ...this. * go-valprint.c (go_value_print_inner): Rename to... (go_language::value_print_inner): ...this. * symtab.c (demangle_for_lookup): Call demangle_symbol method on the go_language object.
2020-12-23gdb: remove LA_EMIT_CHAR macroAndrew Burgess5-5/+12
Now that every use of the LA_EMIT_CHAR macro is within a language_defn member function we can simply call the emitchar member function directly instead of using the LA_EMIT_CHAR macro. If we are ever inside a language object, for example, cplus_language, while current_language points at something other than cplus_language then this commit will result in a change in behaviour. However, I believe if we did have such a difference then this would be a bug in GDB. AS such I'm going to claim there _should_ be no user visible changes from this commit. gdb/ChangeLog: * c-lang.c (language_defn::printchar): Call emitchar, not LA_EMIT_CHAR. * f-lang.h (f_language::printchar): Likewise. * language.h (LA_EMIT_CHAR): Delete macro. * rust-lang.c (rust_language::printchar): Call emitchar, not LA_EMIT_CHAR.
2020-12-23gdb: rename c_printchar as language_defn::printcharAndrew Burgess4-12/+12
This commit removes the global function c_printchar and moves the implementation into language_defn::printchar. There should be no user visible changes after this commit. gdb/ChangeLog: * c-lang.c (c_printchar): Rename to... (language_defn::printchar): ...this. * c-lang.h (c_printchar): Delete declaration. * language.c (language_defn::printchar): Delete this implementation. Is now implemented in c-lang.c.
2020-12-23gdb: avoid accessing global C++ language implementation functionsAndrew Burgess2-3/+9
The function c_printchar is called from two places; it provides the implementation of language_defn::printchar and it is called from dwarf2_compute_name. It would be nice to rename c_printchar as language_defn::printchar and so avoid the trampoline. To achieve this, instead of calling c_printchar directly from the DWARF code, I lookup the C++ language object and call the printchar member function. In a later commit I can then rename c_printchar. There should be no user visible changes after this commit. gdb/ChangeLog: * dwarf2/read.c (dwarf2_compute_name): Call methods on C++ language object instead of calling global functions directly.
2020-12-23gdb: delete unused function print_char_charsAndrew Burgess3-40/+5
Spotted that print_char_chars appears to be unused, delete it. There should be no user visible changes after this commit. gdb/ChangeLog: * valprint.c (print_char_chars): Delete definition. * valprint.h (print_char_chars): Delete declaration.
2020-12-23Add myself to gdb/MAINTAINERSSamuel Thibault2-0/+3
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add myself.
2020-12-23hurd: Add changelog for dca11eb872c9Samuel Thibault1-0/+8
2020-12-23hurd: Fix getting VM_MIN/MAX_ADDRESSSamuel Thibault1-0/+1
gnu-nat.c was getting the inclusion of vm_param.h only by luck. We need to explicitly include it to be sure to get the definitions of VM_MIN/MAX_ADDRESS. gdb/ChangeLog: * gnu-nat.c: Include <mach/vm_param.h>.
2020-12-23Remove trailing white spaces in gdb/frame.{c,h}Shahab Vahedi3-8/+13
gdb/ChangeLog: * frame.c: Remove trailing white spaces. * frame.h: Likewise.
2020-12-22arc: Make variable name in comments uppercaseShahab Vahedi2-2/+6
The word "regnum" in comments should be uppercase, because it reflects a variable name in the code. gdb/ChangeLog * arc-linux-tdep.c: Replace "regnum" with "REGNUM" in comments.
2020-12-22gdb: Add native support for ARC in GNU/LinuxAnton Kolesov5-0/+335
With this patch in place it is possible to build a GDB that can run on ARC (GNU/Linux) hosts for debugging ARC targets. The "arc-linux-nat.c" is a rather small one that mostly deals with registers and a few thread related hooks. v2 [1]: - Remove "void" from the input of "_initialize_arc_linux_nat ()" [1] Tom's remark after the first patch https://sourceware.org/pipermail/gdb-patches/2020-November/173223.html gdb/ChangeLog: * Makefile.in (ALLDEPFILES): Add arc-linux-nat.c. * configure.host (host to gdb names): Add arc*-*-linux*. * configure.nat (gdb_host_cpu): Add arc. * arc-linux-nat.c: New.
2020-12-22arc: Take into account the REGNUM in supply/collect gdb hooksShahab Vahedi2-9/+38
All the arc_linux_supply_*() target operations and the arc_linux_collect_v2_regset() in arc-linux-tdep.c were supplying/collecting all the registers in regcache as if the REGNUM was set to -1. The more efficient behavior is to examine the REGNUM and act accordingly. That is what this patch does. gdb/ChangeLog: * arc-linux-tdep.c (supply_register): New. (arc_linux_supply_gregset, arc_linux_supply_v2_regset, arc_linux_collect_v2_regset): Consider REGNUM.
2020-12-22arc: Add support for signal frames for Linux targetsAnton Kolesov2-0/+188
Implement functions needed to unwind signal frames on ARC Linux targets. gdb/ChangeLog * arc-linux-tdep.c (arc_linux_sc_reg_offsets): New static variable. (arc_linux_is_sigtramp): New function. (arc_linux_sigcontext_addr): Likewise. (arc_linux_init_osabi): Use them.
2020-12-22arc: Add support for signal handlersAnton Kolesov3-0/+147
This patch adds the necessary infrastructure to handle signal frames for ARC architecture. It is fairly similar to what any other architecture would have. Linux specific parts will be in a separate patch. v2 [1]: - Make the logic of "arc_sigtramp_frame_sniffer ()" simpler. [1] Tom's remark for the first version https://sourceware.org/pipermail/gdb-patches/2020-November/173221.html gdb/ChangeLog: * arc-tdep.c (arc_make_sigtramp_frame_cache): New function. (arc_sigtramp_frame_this_id): Likewise. (arc_sigtramp_frame_prev_register): Likewise. (arc_sigtramp_frame_sniffer): Likewise. (arc_siftramp_frame_unwind): New global variable. (arc_gdbarch_init): Use sigtramp capabilities. (arc_dump_tdep): Print sigtramp fields. * arc-tdep.h (gdbarch_tdep): Add sigtramp fields.
2020-12-21Move enum noside earlier in expression.hTom Tromey2-22/+26
For the expression rewrite series, I needed to move enum noside earlier in expression.h. Because this is a pure move, and because it seems harmless and uncontroversial to move an enum definition earlier in a file, I'm pushing it in early, to reduce the size of that series. Tested by rebuilding. gdb/ChangeLog 2020-12-21 Tom Tromey <tom@tromey.com> * expression.h (enum noside): Move earlier.
2020-12-21Preserve gdb_std{out, err, log, targ, targerr} across interpreter_exec_cmdPeter Waller5-0/+85
Calls through interpreter_exec_cmd can cause the output state to be modified in a way which doesn't get back after the execution. It looks like the intent is that interp::resume should put things back how they should be, however, mi_interp::resume modifies gdb_stdout and nothing currently restores it to the previous state. To see the broken behaviour: gdb -ex starti -ex bt -ex 'interpreter-exec mi echo' -ex bt -ex q echo <<<'' Prior to this patch, on a terminal environment, the first backtrace is coloured, and the second backtrace is not. The reason is that stdio_file::can_emit_style_escape becomes false, because the gdb_stdout gets overwritten in mi_interp::resume and not replaced. gdb/ChangeLog: * interps.c (interpreter_exec_cmd): Restore streams pointers. gdb/testsuite/ChangeLog: * gdb.base/style-interp-exec-mi.exp: New. * gdb.base/style-interp-exec-mi.c: New. Signed-off-by: Peter Waller <p@pwaller.net> Change-Id: Id87423b262d058857ea9dca5866ca6471741e512
2020-12-21gdb/testsuite: use gdb_test in gdb.base/list.expSimon Marchi2-151/+35
Use gdb_test instead of send_gdb + gdb_expect. Use proc_with_prefix to help with name uniqueness. gdb/testsuite/ChangeLog: * gdb.base/list.exp: Replace send_gdb + gdb_expect with gdb_test. Use proc_with_prefix. Change-Id: Ieee8fb2c80f596f60397fab7633773a7f8c8c879
2020-12-21testsuite, gdb.btrace: fix 32-bit PIE false positivesMarkus Metzger4-5/+19
For 32-bit position independent executables, GCC generates an extra call to __x86.get_pc_thunk.<reg> which appears in the function call history. It is correct to appear there but this confuses the tests, which check for an expected sequence of functions. Build with nopie to avoid this complication. gdb/testsuite/ChangeLog: 2020-12-04 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/exception.exp: Build with nopie. * gdb.btrace/function_call_history.exp: Likewise. * gdb.btrace/unknown_functions.exp: Likewise.
2020-12-21testsuite, gdb.btrace: skip multi-inferior.exp on gdbserver targetsMarkus Metzger2-0/+9
The gdb.btrace/multi-inferior.exp test creates multiple inferiors to check that recording is per-inferior. When run with the native-gdbserver board, this test hangs when trying to add the second inferior over the remote connection. Skip the test. Note that the test runs fine with the native-extended-gdbserver board file and we want to keep testing that configuration. gdb/testsuite/ChangeLog: 2020-12-11 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/multi-inferior.exp: Skip if use_gdb_stub.
2020-12-21testsuite, gdb.python: make py-record-*.exp test names uniqueMarkus Metzger3-4/+15
gdb/testsuite/ChangeLog: 2020-12-14 Markus Metzger <markus.t.metzger@intel.com> * gdb.python/py-record-btrace.exp: Make test names unique. * gdb.python/py-record-full.exp: Likewise.
2020-12-21testsuite, gdb.btrace: make test names uniqueMarkus Metzger11-140/+231
gdb/testsuite/ChangeLog: 2020-12-04 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/data.exp: Make test names unique. * gdb.btrace/delta.exp: Likewise. * gdb.btrace/enable.exp: Likewise. * gdb.btrace/function_call_history.exp: Likewise. * gdb.btrace/nohist.exp: Likewise. * gdb.btrace/non-stop.exp: Likewise. * gdb.btrace/rn-dl-bind.exp: Likewise. * gdb.btrace/step.exp: Likewise. * gdb.btrace/stepi.exp: Likewise. * gdb.btrace/tailcall.exp: Likewise.
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.
generated by cgit v1.1 at 2024-07-13 19:53:54 +0000