aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.python
AgeCommit message (Collapse)AuthorFilesLines
2020-06-16Add two missing return values in gdb.python/py-nested-maps.cusers/luisgpm/testGary Benson1-0/+2
Two functions in gdb.python/py-nested-maps.c are missing return values. This causes clang to fail to compile the file with the following error: warning: control reaches end of non-void function [-Wreturn-type] This commit fixes, by causing the two functions to return pointers to the objects they've just allocated and initialized. I didn't investigate how this test had been passing with other compilers; I'm assuming serendipity, that in each function the value to be returned was already in the register it would need to be in to be the function's return value. gdb/testsuite/ChangeLog: * gdb.python/py-nested-maps.c (create_map): Add missing return value. (create_map_map): Likewise.
2020-06-12[gdb/testsuite] Don't leak tuiterm.exp spawn overrideTom de Vries1-1/+1
In lib/tuiterm.exp the builtin spawn is overridden by a tui-specific version. After running the first test-case that imports tuiterm.exp, the override remains active, so it can cause trouble in subsequent test-cases, even if they do not import tuiterm.exp. See f.i. commit c8d4f6dfd9 "[gdb/testsuite] Fix spawn in tuiterm.exp". Fix this by: - adding a variable gdb_finish_hooks which is a list of procs to run during gdb_finish - adding a proc tuiterm_env that is used in test-cases instead of "load_lib tuiterm.exp". - letting tuiterm_env: - install the tui-specific spawn version, and - use the gdb_finish_hooks to schedule restoring the builtin spawn version. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-06-12 Tom de Vries <tdevries@suse.de> * lib/tuiterm.exp (spawn): Rename to ... (tui_spawn): ... this. (toplevel): Move rename of spawn ... (gdb_init_tuiterm): ... here. New proc. (gdb_finish_tuiterm): New proc. * lib/gdb.exp (gdb_finish_hooks): New global var. (gdb_finish): Handle gdb_finish_hooks. (tuiterm_env): New proc. * gdb.python/tui-window.exp: Replace load_lib tuiterm.exp with tuiterm_env. * gdb.tui/basic.exp: Same. * gdb.tui/corefile-run.exp: Same. * gdb.tui/empty.exp: Same. * gdb.tui/list-before.exp: Same. * gdb.tui/list.exp: Same. * gdb.tui/main.exp: Same. * gdb.tui/new-layout.exp: Same. * gdb.tui/regs.exp: Same. * gdb.tui/resize.exp: Same. * gdb.tui/tui-layout-asm-short-prog.exp: Same. * gdb.tui/tui-layout-asm.exp: Same. * gdb.tui/tui-missing-src.exp: Same. * gdb.tui/winheight.exp: Same.
2020-05-15Fix "control reaches end of non-void function" errors in testsuiteGary Benson1-0/+1
When running the testsuite with clang, a number of testcases fail to build with the following errors: warning: control reaches end of non-void function [-Wreturn-type] warning: control may reach end of non-void function [-Wreturn-type] This prevents a number of testcases from executing. This commit fixes. gdb/testsuite/ChangeLog: * gdb.base/info-os.c (main): Add return statement. * gdb.base/info_minsym.c (minsym_fun): Likewise. * gdb.base/large-frame-2.c (func): Likewise. * gdb.base/pr10179-a.c (foo1, bar1): Likewise. * gdb.base/pr10179-b.c (foo2): Likewise. * gdb.base/valgrind-disp-step.c (foo): Likewise. * gdb.base/watch-cond.c (func): Likewise. * gdb.multi/goodbye.c (verylongfun): Likewise. * gdb.multi/hello.c (commonfun): Likewise. * gdb.python/py-finish-breakpoint.c (call_longjmp): Likewise. * gdb.threads/fork-plus-threads.c (thread_func): Likewise. * gdb.threads/forking-threads-plus-breakpoint.c (thread_forks): Likewise. * gdb.threads/hand-call-new-thread.c (foo): Likewise. * gdb.threads/interrupt-while-step-over.c (child_function): Likewise. * gdb.trace/actions-changed.c (end): Likewise.
2020-04-30Adjust array pretty printer tests to the new formatHannes Domani1-3/+3
gdb/testsuite/ChangeLog: 2020-04-30 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-format-string.exp: Adjust pretty_arrays expected output to the new format.
2020-04-29[gdb/testsuite] Add xfails for PR gcc/90232Tom de Vries1-1/+16
With target board debug-types, we have these FAILs: ... FAIL: gdb.guile/scm-symtab.exp: test simple_struct in static symbols FAIL: gdb.python/py-symtab.exp: test simple_struct in static symbols ... due to PR gcc/90232, as explained in commit 15cd93d05e8 "[gdb/symtab] Handle struct decl with DW_AT_signature". Marks these as XFAILs. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-04-29 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (debug_types): New proc. * gdb.guile/scm-symtab.exp: Add xfail for PR gcc/90232. * gdb.python/py-symtab.exp: Same.
2020-04-24Use the linkage name if it existsTom Tromey1-1/+1
The DWARF reader has had some odd code since the "physname" patches landed. In particular, these patches caused PR symtab/12707; namely, they made it so "set print demangle off" no longer works. This patch attempts to fix the problem. It arranges to store the linkage name on the symbol if it exists, and it changes the DWARF reader so that the demangled name is no longer (usually) stored in the symbol's "linkage name" field. c-linkage-name.exp needed a tweak, because it started working correctly. This conforms to what I think ought to happen, so this seems like an improvement here. compile-object-load.c needed a small change to use symbol_matches_search_name rather than directly examining the linkage name. Looking directly at the name does the wrong thing for C++. There is still some name-related confusion in the DWARF reader: * "physname" often refers to the logical name and not what I would consider to be the "physical" name; * dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and return different strings -- but this seems like at least one name too many. For example, Fortran requires dwarf2_full_name, but other languages do not. * To my surprise, dwarf2_physname prefers the form emitted by the demangler over the one that it computes. This seems backward to me, given that the partial symbol reader prefers the opposite, and it seems to me that this choice may perform better as well. I didn't attempt to clean up these things. It would be good to do, but whenever I contemplate it I get caught up in dreams of truly rewriting the DWARF reader instead. gdb/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> PR symtab/12707: * dwarf2/read.c (add_partial_symbol): Use the linkage name if it exists. (new_symbol): Likewise. * compile/compile-object-load.c (get_out_value_type): Use symbol_matches_search_name. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tom@tromey.com> PR symtab/12707: * gdb.python/py-symbol.exp: Update expected results for linkage_name test. * gdb.cp/print-demangle.exp: New file. * gdb.base/c-linkage-name.exp: Fix test. * gdb.guile/scm-symbol.exp: Update expected results for linkage_name test.
2020-02-22Allow TUI windows in PythonTom Tromey2-0/+88
This patch adds support for writing new TUI windows in Python. 2020-02-22 Tom Tromey <tom@tromey.com> * NEWS: Add entry for gdb.register_window_type. * tui/tui-layout.h (window_factory): New typedef. (tui_register_window): Declare. * tui/tui-layout.c (saved_tui_windows): New global. (tui_apply_current_layout): Use it. (tui_register_window): New function. * python/python.c (do_start_initialization): Call gdbpy_initialize_tui. (python_GdbMethods): Add "register_window_type" function. * python/python-internal.h (gdbpy_register_tui_window) (gdbpy_initialize_tui): Declare. * python/py-tui.c: New file. * Makefile.in (SUBDIR_PYTHON_SRCS): Add py-tui.c. gdb/doc/ChangeLog 2020-02-22 Tom Tromey <tom@tromey.com> * python.texi (Python API): Add menu item. (TUI Windows In Python): New node. gdb/testsuite/ChangeLog 2020-02-22 Tom Tromey <tom@tromey.com> * gdb.python/tui-window.exp: New file. * gdb.python/tui-window.py: New file. Change-Id: I85fbfb923a1840450a00a7dce113a05d7f048baa
2020-02-19[gdb/testsuite] Fix xpass in gdb.python/lib-types.expTom de Vries1-2/+9
When running gdb.python/lib-types.exp, we have an xpass: ... (gdb) python print (str (typedef_const_typedef_class1_ref_obj.type))^M typedef_const_typedef_class1_ref^M (gdb) XPASS: gdb.python/lib-types.exp: \ python print (str (typedef_const_typedef_class1_ref_obj.type)) \ (PRMS gcc/55641) ... When running the same with gcc 4.8, we have an xfail instead: ... (gdb) python print (str (typedef_const_typedef_class1_ref_obj.type))^M const typedef_const_typedef_class1_ref^M (gdb) XFAIL: gdb.python/lib-types.exp: \ python print (str (typedef_const_typedef_class1_ref_obj.type)) \ (PRMS gcc/55641) ... Fix the xpass by xfailing only for the gcc 4.8 pattern. Tested on x86_64-linux, with: - gcc 7.5.0 - gcc 4.8.5 - clang 5.0.2 gdb/testsuite/ChangeLog: 2020-02-19 Tom de Vries <tdevries@suse.de> * gdb.python/lib-types.exp: Make xfail more strict.
2020-01-14Fix valgrind error from gdb.decode_lineTom Tromey1-0/+4
PR symtab/12535 points out that gdb.decode_line("") will cause a valgrind report. I think the empty linespec does not really make sense. So, this patch changes gdb.decode_line to treat a whitespace-only linespec the same as a non-existing argument. gdb/ChangeLog 2020-01-14 Tom Tromey <tom@tromey.com> PR symtab/12535: * python/python.c (gdbpy_decode_line): Treat empty string the same as no argument. gdb/testsuite/ChangeLog 2020-01-14 Tom Tromey <tom@tromey.com> PR symtab/12535: * gdb.python/python.exp: Test decode_line with empty string argument. Change-Id: I1d95812b4b7a21d69a3e9afd05b9e3141a931897
2020-01-10Add "info connections" command, "info inferiors" connection number/stringPedro Alves1-2/+2
This commit extends the CLI a bit for multi-target, in three ways. #1 - New "info connections" command. This is a new command that lists the open connections (process_stratum targets). For example, if you're debugging two remote connections, a couple local/native processes, and a core dump, all at the same time, you might see something like this: (gdb) info connections Num What Description 1 remote 192.168.0.1:9999 Remote serial target in gdb-specific protocol 2 remote 192.168.0.2:9998 Remote serial target in gdb-specific protocol * 3 native Native process 4 core Local core dump file #2 - New "info inferiors" "Connection" column You'll also see a new matching "Connection" column in "info inferiors", showing you which connection an inferior is bound to: (gdb) info inferiors Num Description Connection Executable 1 process 18526 1 (remote 192.168.0.1:9999) target:/tmp/a.out 2 process 18531 2 (remote 192.168.0.2:9998) target:/tmp/a.out 3 process 19115 3 (native) /tmp/prog1 4 process 6286 4 (core) myprogram * 5 process 19122 3 (native) /bin/hello #3 - Makes "add-inferior" show the inferior's target connection "add-inferior" now shows you the connection you've just bound the inferior to, which is the current process_stratum target: (gdb) add-inferior [New inferior 2] Added inferior 2 on connection 1 (extended-remote localhost:2346) gdb/ChangeLog: 2020-01-10 Pedro Alves <palves@redhat.com> * Makefile.in (COMMON_SFILES): Add target-connection.c. * inferior.c (uiout_field_connection): New function. (print_inferior): Add new "connection-id" column. (add_inferior_command): Show connection number/string of added inferior. * process-stratum-target.h (process_stratum_target::connection_string): New virtual method. (process_stratum_target::connection_number): New field. * remote.c (remote_target::connection_string): New override. * target-connection.c: New file. * target-connection.h: New file. * target.c (decref_target): Remove process_stratum targets from the connection list. (target_stack::push): Add process_stratum targets to the connection list. gdb/testsuite/ChangeLog: 2020-01-10 Pedro Alves <palves@redhat.com> * gdb.base/kill-detach-inferiors-cmd.exp: Adjust expected output of "add-inferior". * gdb.base/quit-live.exp: Likewise. * gdb.base/remote-exec-file.exp: Likewise. * gdb.guile/scm-progspace.exp: Likewise. * gdb.linespec/linespec.exp: Likewise. * gdb.mi/new-ui-mi-sync.exp: Likewise. * gdb.mi/user-selected-context-sync.exp: Likewise. * gdb.multi/multi-target.exp (setup): Add "info connection" and "info inferiors" tests. * gdb.multi/remove-inferiors.exp: Adjust expected output of "add-inferior". * gdb.multi/watchpoint-multi.exp: Likewise. * gdb.python/py-inferior.exp: Likewise. * gdb.server/extended-remote-restart.exp: Likewise. * gdb.threads/fork-plus-threads.exp: Adjust expected output of "info inferiors". * gdb.threads/forking-threads-plus-breakpoint.exp: Likewise. * gdb.trace/report.exp: Likewise.
2020-01-01Update copyright year range in all GDB files.Joel Brobecker162-162/+162
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-12-11Implement 'print -raw-values' and 'set print raw-values on|off'Philippe Waroquiers1-0/+21
The option framework documentation was speaking about a 'print -raw' option, but this option does not exist. This patch implements -raw-values option that tells to ignore the active pretty printers when printing a value. As we already have -raw-frame-arguments, I thought -raw-values was more clear, in particular to differentiate set print raw-values and set print raw-frame-arguments. gdb/doc/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.texinfo (Command Options): Use -p and -pretty in the example, as -r is ambiguous. Update the print - TAB TAB completion result. (Data): Document new option -raw-values. Use -p and -pretty in the example, as -r is ambiguous. (Print Settings): Document set print raw values. (Pretty-Printer Commands): Document interaction between enabled pretty printers and -raw-values/-raw-frame-arguments. gdb/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * NEWS: Document -raw-values option and the related setting commands. * printcmd.c (print_command_parse_format): Do not set opts->raw off, only set it on when /r is given. * valprint.c (value_print_option_defs): New element raw-values. * Makefile.in: Add the new file. gdb/testsuite/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.base/options.exp: Add -raw-values in the print completion list. * gdb.python/py-prettyprint.exp: Add tests for -raw-values.
2019-12-09Fix scripted probe breakpointsGeorge Barrett2-0/+27
The documentation for make-breakpoint from the Guile API and the `spec' variant of the gdb.Breakpoint constructor from the Python API state that the format acceptable for location strings is the same as that accepted by the break command. However, using the -probe qualifier at the beginning of the location string causes a GDB internal error as it attempts to decode a probe location in the wrong code path. Without this functionality, there doesn't appear to be another way to set breakpoints on probe points from Python or Guile scripts. This patch introduces a new helper function that returns a breakpoint_ops instance appropriate for a parsed location and updates the Guile and Python bindings to use said function, rather than the current hard-coded use of bkpt_breakpoint_ops. Since this logic is duplicated in the handling of the `break' and `trace' commands, those are also updated to call into the new helper function. gdb/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Fix scripted probe breakpoints. * breakpoint.c (tracepoint_probe_breakpoint_ops): Move declaration forward. (breakpoint_ops_for_event_location_type) (breakpoint_ops_for_event_location): Add function definitions. (break_command_1, trace_command): Use breakpoint_ops_for_event_location. * breakpoint.h (breakpoint_ops_for_event_location): Add function declarations. * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use breakpoint_ops_for_event_location. * python/py-breakpoint.c (bppy_init): Use breakpoint_ops_for_event_location. gdb/testsuite/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Test scripted probe breakpoints. * gdb.guile/scm-breakpoint.c (main): Add probe point. * gdb.python/py-breakpoint.c (main): Likewise. * gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe specifier test. * gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
2019-11-20Add missing parentheses on 'print' (gdb.python/py-progspace.exp)Sergio Durigan Junior1-3/+3
Commit 33d569b709886a1208145806da80b689d9cae9da ("gdb/python: Return None from Progspace.block_for_pc on error") added a few tests on gdb.python/py-progspace.exp which use 'print', but forgot to use parentheses when passing the arguments to be printed. This fails on Python 3. This commit adds these missing parentheses. Pushed as obvious. gdb/testsuite/ChangeLog: 2019-11-20 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.python/py-progspace.exp: Add missing parentheses on some 'print' commands. Change-Id: Iac0a7578855d128bbee3b98e7ea5888dae55fc00
2019-11-10gdb/python: Introduce gdb.lookup_static_symbolsAndrew Burgess1-0/+17
If gdb.lookup_static_symbol is going to return a single symbol then it makes sense (I think) for it to return a context sensitive choice of symbol, that is the global static symbol that would be visible to the program at that point. However, if the user of the python API wants to instead get a consistent set of global static symbols, no matter where they stop, then they have to instead consider all global static symbols with a given name - there could be many. That is what this new API function offers, it returns a list (possibly empty) of all global static symbols matching a given name (and optionally a given symbol domain). gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbols): New function. * python/python-internal.h (gdbpy_lookup_static_symbols): Declare new function. * python/python.c (python_GdbMethods): Add gdb.lookup_static_symbols method. * NEWS: Mention gdb.lookup_static_symbols. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.exp: Add test for gdb.lookup_static_symbols. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Add documentation for gdb.lookup_static_symbols. Change-Id: I1153b0ae5bcbc43b3dcf139043c7a48bf791e1a3
2019-11-10gdb/python: smarter symbol lookup for gdb.lookup_static_symbolAndrew Burgess3-12/+56
When using gdb.lookup_static_symbol I think that GDB should find static symbols (global symbol with static linkage) from the current object file ahead of static symbols from other object files. This means that if we have two source files f1.c and f2.c, and both files contains 'static int foo;', then when we are stopped in f1.c a call to 'gdb.lookup_static_symbol ("foo")' will find f1.c::foo, and if we are stopped in f2.c we would find 'f2.c::foo'. Given that gdb.lookup_static_symbol always returns a single symbol, but there can be multiple static symbols with the same name GDB is always making a choice about which symbols to return. I think that it makes sense for the choice GDB makes in this case to match what a user would get on the command line if they asked to 'print foo'. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.c: Declare and call function from new py-symbol-2.c file. * gdb.python/py-symbol.exp: Compile both source files, and add new tests for gdb.lookup_static_symbol. * gdb.python/py-symbol-2.c: New file. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Extend documentation for gdb.lookup_static_symbol. gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbol): Lookup in static block of current object file first. Also fix typo in header comment. Change-Id: Ie55dbeb8806f35577b46015deecde27a0ca2ab64
2019-10-31[gdb/testsuite] Remove superfluous 3rd argument from gdb_test call (2)Tom de Vries5-12/+7
There's a pattern: ... gdb_test <command> <pattern> <command> ... that can be written shorter as: ... gdb_test <command> <pattern> ... Detect this pattern in proc gdb_test: ... global gdb_prompt upvar timeout timeout if [llength $args]>2 then { set message [lindex $args 2] + if { $message == [lindex $args 0] && [llength $args] == 3 } { + error "HERE" + } } else { set message [lindex $args 0] } ... and fix all occurrences in some gdb testsuite subdirs. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-10-31 Tom de Vries <tdevries@suse.de> * gdb.arch/amd64-disp-step-avx.exp: Drop superfluous 3rd argument to gdb_test. * gdb.arch/amd64-disp-step.exp: Same. * gdb.asm/asm-source.exp: Same. * gdb.btrace/buffer-size.exp: Same. * gdb.btrace/cpu.exp: Same. * gdb.btrace/enable.exp: Same. * gdb.dwarf2/count.exp: Same. * gdb.dwarf2/dw2-ranges-func.exp: Same. * gdb.dwarf2/dw2-ranges-psym.exp: Same. * gdb.fortran/vla-datatypes.exp: Same. * gdb.fortran/vla-history.exp: Same. * gdb.fortran/vla-ptype.exp: Same. * gdb.fortran/vla-value.exp: Same. * gdb.fortran/whatis_type.exp: Same. * gdb.guile/guile.exp: Same. * gdb.multi/tids.exp: Same. * gdb.python/py-finish-breakpoint.exp: Same. * gdb.python/py-framefilter.exp: Same. * gdb.python/py-pp-registration.exp: Same. * gdb.python/py-xmethods.exp: Same. * gdb.python/python.exp: Same. * gdb.server/connect-with-no-symbol-file.exp: Same. * gdb.server/no-thread-db.exp: Same. * gdb.server/run-without-local-binary.exp: Same. * gdb.stabs/weird.exp: Same. * gdb.threads/attach-many-short-lived-threads.exp: Same. * gdb.threads/thread-find.exp: Same. * gdb.threads/tls-shared.exp: Same. * gdb.threads/tls.exp: Same. * gdb.threads/wp-replication.exp: Same. * gdb.trace/ax.exp: Same. * lib/gdb.exp (gdb_test_exact, help_test_raw): Same. Change-Id: I2fa544c68f8c0099a77e03ff04ddc010eb2b6c7c
2019-10-26[gdb] Fix more typos in comments (2)Tom de Vries1-1/+1
Fix typos in comments. NFC. Tested on x86_64-linux. gdb/ChangeLog: 2019-10-26 Tom de Vries <tdevries@suse.de> * aarch64-linux-tdep.c: Fix typos in comments. * aarch64-tdep.c: Same. * ada-lang.c: Same. * amd64-nat.c: Same. * arc-tdep.c: Same. * arch/aarch64-insn.c: Same. * block.c: Same. * breakpoint.h: Same. * btrace.h: Same. * c-varobj.c: Same. * cli/cli-decode.c: Same. * cli/cli-script.c: Same. * cli/cli-utils.h: Same. * coff-pe-read.c: Same. * coffread.c: Same. * compile/compile-cplus-symbols.c: Same. * compile/compile-object-run.c: Same. * completer.c: Same. * corelow.c: Same. * cp-support.c: Same. * demangle.c: Same. * dwarf-index-write.c: Same. * dwarf2-frame.c: Same. * dwarf2-frame.h: Same. * eval.c: Same. * frame-base.h: Same. * frame.h: Same. * gdbcmd.h: Same. * gdbtypes.h: Same. * gnu-nat.c: Same. * guile/scm-objfile.c: Same. * i386-tdep.c: Same. * i386-tdep.h: Same. * infcall.c: Same. * infcall.h: Same. * linux-nat.c: Same. * m68k-tdep.c: Same. * macroexp.c: Same. * memattr.c: Same. * mi/mi-cmd-disas.c: Same. * mi/mi-getopt.h: Same. * mi/mi-main.c: Same. * minsyms.c: Same. * nat/aarch64-sve-linux-sigcontext.h: Same. * objfiles.h: Same. * ppc-linux-nat.c: Same. * ppc-linux-tdep.c: Same. * ppc-tdep.h: Same. * progspace.h: Same. * prologue-value.h: Same. * python/py-evtregistry.c: Same. * python/py-instruction.h: Same. * record-btrace.c: Same. * record-full.c: Same. * remote.c: Same. * rs6000-tdep.c: Same. * ser-tcp.c: Same. * sol-thread.c: Same. * sparc-sol2-tdep.c: Same. * sparc64-tdep.c: Same. * stabsread.c: Same. * symfile.c: Same. * symtab.h: Same. * target.c: Same. * tracepoint.c: Same. * tui/tui-data.h: Same. * tui/tui-io.c: Same. * tui/tui-win.c: Same. * tui/tui.c: Same. * unittests/rsp-low-selftests.c: Same. * user-regs.h: Same. * utils.c: Same. * utils.h: Same. * valarith.c: Same. * valops.c: Same. * valprint.c: Same. * valprint.h: Same. * value.c: Same. * value.h: Same. * varobj.c: Same. * x86-nat.h: Same. * xtensa-tdep.c: Same. gdb/gdbserver/ChangeLog: 2019-10-26 Tom de Vries <tdevries@suse.de> * linux-aarch64-low.c: Fix typos in comments. * linux-arm-low.c: Same. * linux-low.c: Same. * linux-ppc-low.c: Same. * proc-service.c: Same. * regcache.h: Same. * server.c: Same. * tracepoint.c: Same. * win32-low.c: Same. gdb/stubs/ChangeLog: 2019-10-26 Tom de Vries <tdevries@suse.de> * ia64vms-stub.c: Fix typos in comments. * m32r-stub.c: Same. * m68k-stub.c: Same. * sh-stub.c: Same. gdb/testsuite/ChangeLog: 2019-10-26 Tom de Vries <tdevries@suse.de> * gdb.base/bigcore.c: Fix typos in comments. * gdb.base/ctf-ptype.c: Same. * gdb.base/long_long.c: Same. * gdb.dwarf2/dw2-op-out-param.S: Same. * gdb.python/py-evthreads.c: Same. * gdb.reverse/i387-stack-reverse.c: Same. * gdb.trace/tfile.c: Same. * lib/compiler.c: Same. * lib/compiler.cc: Same. Change-Id: I8573d84a577894270179ae30f46c48d806fc1beb
2019-10-24gdb/python: Return None from Progspace.block_for_pc on errorAndrew Burgess1-0/+14
The documentation for Progspace.block_for_pc says: Return the innermost gdb.Block containing the given pc value. If the block cannot be found for the pc value specified, the function will return None. However, the implementation actually throws an error for invalid addresses, like this: (gdb) python print gdb.current_progspace ().block_for_pc (1) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Cannot locate object file for block. Error while executing Python code. (gdb) This has been the behaviour since the command was first added (when the documentation was still as above) in this commit: commit f3e9a8177c41893858fce2bdf339dbe90b3a4ef5 Date: Wed Feb 24 21:18:28 2010 +0000 Since that commit the code in question has moved around, but the important parts are largely unchanged. The function in question is now in py-progspace.c:pspy_block_for_pc. Examining the code shows that the real state is more complex than just the function throws an error instead of returning None, instead the real situation is: 1. If we can't find a compilation unit for the $pc value then we throw an error, but 2. If we can find a compilation unit, but can't find a block within the compilation unit for the $pc then return None. I suspect for most users of the Python API this distinction is irrelevant, and I propose that we standardise on one single failure mechanism. Given the function can currently return None in some cases, and is documented to return None on error, I propose we make that the case for all error paths, which is what this patch does. As the Progspace.block_for_pc method is currently untested, I've added some basic tests including for a call with an invalid $pc. This is potentially an API breaking change, though an undocumented part of the API. Also, users should have been checking and handling a None return value anyway, so my hope is that this shouldn't be too disruptive. gdb/ChangeLog: * python/py-progspace.c (pspy_block_for_pc): Return None for all error paths. gdb/testsuite/ChangeLog: * gdb.python/py-progspace.exp: Add tests for the Progspace.block_for_pc method. Change-Id: I9cea8d2132902bcad0013d1fd39080dd5423cc57
2019-10-03gdb/testsuite: Reduce test name duplication in gdb.python testsAndrew Burgess3-158/+225
This commit removes some, but not all, of the test name duplication within the gdb.python tests. On my local machine this takes the number of duplicate test names in this set of tests from 174 to 85. It is possible that different setups might encounter more duplicate tests. gdb/testsuite/ChangeLog: * gdb.python/py-parameter.exp: Make test names unique. * gdb.python/py-template.exp: Likewise. * gdb.python/py-value.exp: Likewise.
2019-10-02gdb/testsuite: Fix py-format-string.exp on big-endian platformsAndreas Arnez2-5/+9
GDB's py-format-string test case depends on endianness. In particular it relies on the first byte of the machine representation of 42 (as an int) to be 42 as well. While this is indeed the case for little-endian machines, big-endian machines store a zero in the first byte instead. The wrong assumption leads to lots of FAILs on such architectures. Fix this by filling the affected union with bytes of the same value, such that endianness does not matter. Use the value 42, to keep the character in the first byte unchanged. gdb/testsuite/ChangeLog: * gdb.python/py-format-string.c (string.h): New include. (main): Fill a_struct_with_union.the_union.an_int with bytes of the same value, for endianness-independence. * gdb.python/py-format-string.exp (default_regexp_dict) (test_pretty_structs, test_format): Adjust expected output to the changed initialization.
2019-08-26Use raw strings on gdb.python/py-xmethods.exp (and fix Python 3.8's ↵Sergio Durigan Junior1-18/+18
"SyntaxWarning: invalid escape sequence") The way unrecognized escape sequences are handled has changed in Python 3.8: users now see a SyntaxWarning message, which will eventually become a SyntaxError in future versions of Python: (gdb) source /blabla/gdb.python/py-xmethods/py-xmethods.py /blabla/gdb.python/py-xmethods/py-xmethods.py:204: SyntaxWarning: invalid escape seque nce \+ 'operator\+', /blabla/gdb.python/py-xmethods/py-xmethods.py:211: SyntaxWarning: invalid escape seque nce \+ 'operator\+\+', One of our testcases, gdb.python/py-xmethods.exp, contains strings in the form of "operator\+". This is not recognized by Python, but is still needed by the testsuite to work properly. The solution is simple: we just have to make sure these strings are marked as raw (i.e, r""). This is what this patch does. I took the opportunity to also convert other strings to raw, which, in two cases, allowed the removal of an extra backslash. I tested this using Python 3.7 and Python 3.8, and everything works fine. I think I could push this as obvious, but decided to send it to gdb-patches just in case. gdb/testsuite/ChangeLog: 2019-08-26 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.python/py-xmethods.exp: Use raw strings when passing arguments to SimpleXMethodMatcher.
2019-08-15Rename internal Python functions to start with an underscoreChristian Biesinger1-2/+2
I could not tell if GdbSetPythonDirectory is internal or not because I could not find any references to it, so I left it as-is. Tested by running the testsuite on gdb.python/*.exp; everything still passes. 2019-08-15 Christian Biesinger <cbiesinger@google.com> * python/lib/gdb/__init__.py (GdbOutputFile): Rename to have a leading underscore. (GdbOutputErrorFile): Likewise. (global scope): Adjust constructor calls to GdbOutput{,Error}File accordingly. (execute_unwinders): Rename to have a leading underscore. (auto_load_packages): Likewise. (global scope): Adjust call to auto_load_packages accordingly. (GdbSetPythonDirectory): Likewise. * python/py-unwind.c (pyuw_sniffer): Call _execute_unwinders instead of execute_unwinders. gdb/testsuite/ChangeLog: 2019-08-15 Christian Biesinger <cbiesinger@google.com> * gdb.python/python.exp: Expect a leading underscore on GdbOutput{,Error}File.
2019-08-13Fixes for gdb.python tests on remote Windows host.Sandra Loosemore13-71/+90
This patch fixes several test ERRORs and FAILs seen from running gdb.python tests on a remote Windows host. The problems fixed generally fall into these categories: - Failure to copy the .py script to the host. - Confusion between build and host pathnames. - Assuming pathnames printed on the host include "/" as a directory separator. - Tests that need to be conditionally disabled due to missing features on the host, etc. 2019-08-13 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.python/py-completion.exp: Download the .py file to the host and use its host pathname. Conditionalize tests that use tab completion and manipulate files on the build machine. * gdb.python/py-events.exp: Download the .py file to the host and use its host pathname. * gdb.python/py-evsignal.exp: Likewise. * gdb.python/py-evthreads.exp: Likewise. * gdb.python/py-framefilter-invalidarg.exp: Match Windows pathname syntax. * gdb.python/py-framefilter.exp: Download the .py file to the right place on the host. Match Windows pathname syntax. * gdb.python/py-mi-var-info-path-expression.exp: Download the .py file to the host and use its host pathname. * gdb.python/py-objfile-script.exp: Match Windows pathname syntax. * gdb.python/py-objfile.exp: Expect a host pathname, not a build pathname. Skip symlink test on Windows host. Add missing newline at end of file. * gdb.python/py-pp-maint.exp: Download the .py file to the host and use its host pathname. * gdb.python/py-pp-registration.exp: Match Windows pathname syntax. * gdb.python/py-section-script.exp: Use host location of binfile on safe-path. Use correct path separator on Windows host. Reorder alternatives in gdb_test_multiple to prevent matching the wrong alternative on success. * gdb.python/py-symtab.exp: Match Windows pathname syntax.
2019-08-05Add block['var'] accessorChristian Biesinger1-0/+5
Currently we support iteration on blocks; this patch extends that to make subscript access work as well. gdb/ChangeLog: 2019-08-05 Christian Biesinger <cbiesinger@google.com> * NEWS: Mention dictionary access on blocks. * python/py-block.c (blpy_getitem): New function. (block_object_as_mapping): New struct. (block_object_type): Use new struct for tp_as_mapping field. gdb/doc/ChangeLog: 2019-08-05 Christian Biesinger <cbiesinger@google.com> * python.texi (Blocks In Python): Document dictionary access on blocks. gdb/testsuite/ChangeLog: 2019-08-05 Christian Biesinger <cbiesinger@google.com> * gdb.python/py-block.exp: Test dictionary access on blocks.
2019-07-30[PR/24474] Add gdb.lookup_static_symbol to the python APIChristian Biesinger2-0/+29
Similar to lookup_global_symbol, except that it checks the STATIC_SCOPE. gdb/ChangeLog: 2019-07-30 Christian Biesinger <cbiesinger@google.com> PR/24474: Add a function to lookup static variables. * NEWS: Mention this new function. * python/py-symbol.c (gdbpy_lookup_static_symbol): New function. * python/python-internal.h (gdbpy_lookup_static_symbol): New function. * python/python.c (python_GdbMethods): Add new function. gdb/doc/ChangeLog: 2019-07-30 Christian Biesinger <cbiesinger@google.com> * python.texi (Symbols In Python): Document new function gdb.lookup_static_symbol. gdb/testsuite/ChangeLog: 2019-07-30 Christian Biesinger <cbiesinger@google.com> * gdb.python/py-symbol.c: Add a static variable and one in an anonymous namespace. * gdb.python/py-symbol.exp: Test gdb.lookup_static_symbol.
2019-07-29Fix misspelling (nonexistant -> nonexistent)Christian Biesinger1-2/+2
gdb/testsuite/ChangeLog: 2019-07-29 Christian Biesinger <cbiesinger@google.com> * gdb.python/py-objfile.exp: Fix misspelling (nonexistant -> nonexistent)
2019-07-29Add Objfile.lookup_{global,static}_symbol functionsChristian Biesinger2-0/+17
This is essentially the inverse of Symbol.objfile. This allows handling different symbols with the same name (but from different objfiles) and can also be faster if the objfile is known. gdb/ChangeLog: 2019-07-29 Christian Biesinger <cbiesinger@google.com> * NEWS: Mention new functions Objfile.lookup_{global,static}_symbol. * python/py-objfile.c (objfpy_lookup_global_symbol): New function. (objfpy_lookup_static_symbol): New function. (objfile_object_methods): Add new functions. gdb/doc/ChangeLog: 2019-07-29 Christian Biesinger <cbiesinger@google.com> * python.texi (Objfiles In Python): Document new functions Objfile.lookup_{global,static}_symbol. gdb/testsuite/ChangeLog: 2019-07-29 Christian Biesinger <cbiesinger@google.com> * gdb.python/py-objfile.c: Add global and static vars. * gdb.python/py-objfile.exp: Test new functions Objfile. lookup_global_symbol and lookup_static_symbol.
2019-07-29Test 'set print frame-info|frame-arguments presence'.Philippe Waroquiers2-5/+69
Updated tests to test the new options and new values. Test the default for print_what in python frame filtering. Updated the tests impacted by the default in python frame filtering which is now consistent with the backtrace command. gdb/testsuite/ChangeLog 2019-07-29 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.base/options.exp: Update backtrace - completion to new option -frame-info. * gdb.base/frame-args.exp: Test new 'frame-arguments presence'. Test new 'set print frame-info'. Test backtrace -frame-info overriding 'set print frame-info'. * gdb.python/py-framefilter.exp: Test new 'frame-arguments presence'. Test new 'set print frame-info'. Verify consistency of backtrace with and without filters, with and without -no-filters. * gdb.python/py-framefilter-invalidarg.exp: Update to new print_what default.
2019-07-29[gdb/testsuite] Fix python.exp with check-read1Tom de Vries1-2/+2
when running python/python.exp with check-read1, we get: ... (gdb) PASS: gdb.python/python.exp: prompt substitution readline - end python gdb.prompt_hook = error_prompt^M Python Exception <type 'exceptions.RuntimeError'> Python exception calledPASS: gdb.python/python.exp: set hook : ^M (gdb) PASS: gdb.python/python.exp: set the hook to default python gdb.prompt_hook = None^M (gdb) PASS: gdb.python/python.exp: set print-stack full for prompt error test set python print-stack full^M (gdb) FAIL: gdb.python/python.exp: set the hook python gdb.prompt_hook = error_prompt^M Traceback (most recent call last):^M File "<string>", line 3, in error_prompt^M RuntimeError: Python exception called^M (gdb) FAIL: gdb.python/python.exp: set the hook to default ... The problem is that gdb_test_multiple here: ... gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" { -re "Python Exception (exceptions.RuntimeError|<(type 'exceptions.|class ')RuntimeError'>) Python excepti on called.*" { pass "set hook" } } ... specifies a regexp that ends with ".*" but doesn't specify the expected $gdb_prompt. Consequently, due to check-read1, the ".*" is matched to "" and the remaining $gdb_prompt is read by the the following gdb_py_test_silent_cmd, which has its own $gdb_prompt read by the following gdb_py_test_silent_cmd, which has its own $gdb_prompt causing a mismatch for the following gdb_test_multiple: ... gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" { -re "Traceback.*File.*line.*RuntimeError.*Python exception called.*" { pass "set hook" } } ... which causes both FAILs. The second gdb_test_multiple has the same problem as the first, but it happens not to cause a FAIL because it's followed by a gdb_py_test_silent_cmd and a clean_restart. Fix the regexps in both gdb_test_multiple calls. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-07-29 Tom de Vries <tdevries@suse.de> * gdb.python/python.exp: Don't terminate gdb_test_multiple regexp with ".*".
2019-07-09"catch catch/throw/rethrow", breakpoint -> catchpointPedro Alves1-2/+3
Currently, with: (gdb) catch catch Catchpoint 1 (catch) (gdb) catch throw Catchpoint 2 (throw) (gdb) catch rethrow Catchpoint 3 (rethrow) You get: (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000b122af exception catch 2 breakpoint keep y 0x0000000000b1288d exception throw 3 breakpoint keep y 0x0000000000b12931 exception rethrow I think it doesn't make much sense usability-wise, to show a catchpoint as a breakpoint. The fact that GDB sets a breakpoint at some magic address in the C++ run time is an implementation detail, IMO. And as seen in the previous patch, such a catchpoint can end up with more than one location/address even, so showing a single address isn't entirely accurate. This commit hides the addresses from view, and makes GDB show "catchpoint" for type as well: (gdb) info breakpoints Num Type Disp Enb Address What 1 catchpoint keep y exception catch 2 catchpoint keep y exception throw 3 catchpoint keep y exception rethrow This comment in the code seems telling: /* We need to reset 'type' in order for code in breakpoint.c to do the right thing. */ cp->type = bp_breakpoint; It kind of suggests that the reason catchpoints end up shown as breakpoints was that it was easier to implement them that way, rather than a desired property. This commit fixes things up to make it possible to have bp_catch breakpoints have software/hardware breakpoint locations, thus eliminating the need for that hack: - redo breakpoint_address_is_meaningful in terms of the location's type rather than breakpoint type. - teach bpstat_what about stepping over the catchpoint locations. - install a allocate_location method for "catch catch/throw/rethrow", one that forces the location type. Note that this also reverts the gdb hunk from: commit 2a8be20359dba9cc684fd3ffa222d985399f3b18 Commit: Tom Tromey <tom@tromey.com> CommitDate: Sat Oct 6 22:17:45 2018 -0600 Fix Python gdb.Breakpoint.location crash because now "catch throw" catchpoints hit the if (obj->bp->type != bp_breakpoint) Py_RETURN_NONE; check above, and, adjusts the testcase to no longer expect to see the catchpoint in the gdb.breakpoints() list. (Note: might make sense to do the same to Ada exception catchpoints.) gdb/ChangeLog: 2019-07-09 Pedro Alves <palves@redhat.com> * break-catch-throw.c (print_one_exception_catchpoint): Skip the "addr" field. (allocate_location_exception_catchpoint): New. (handle_gnu_v3_exceptions): Don't reset 'type' to bp_breakpoint. (initialize_throw_catchpoint_ops): Install allocate_location_exception_catchpoint as allocate_location method. * breakpoint.c (bpstat_what) <bp_catch>: Set action to BPSTAT_WHAT_SINGLE if not stopping and the location's type is not bp_loc_other. (breakpoint_address_is_meaningful): Delete. (bl_address_is_meaningful): New. (breakpoint_locations_match): Adjust comment. (bp_location_from_bp_type): New, factored out of... (bp_location::bp_location(breakpoint *)): ... this. (bp_location::bp_location(breakpoint *, bp_loc_type)): New, factored out of... (bp_location::bp_location(breakpoint *)): ... this. Reimplement. (bp_loc_is_permanent): Use bl_address_is_meaningful instead of breakpoint_address_is_meaningful. (bp_locations_compare): Adjust comment. (update_global_location_list): Use bl_address_is_meaningful instead of breakpoint_address_is_meaningful. * breakpoint.h (bp_location::bp_location(breakpoint *)): New explicit. (bp_location::bp_location(breakpoint *, bp_loc_type)): Declare. * python/py-breakpoint.c (bppy_get_location): No longer check whether location is null. gdb/doc/ChangeLog: 2019-07-09 Pedro Alves <palves@redhat.com> * gdb.texinfo (C++ Exception GDB/MI Catchpoint Commands): Adjust examples to show type=catchpoint instead of type=breakpoint and an address. gdb/testsuite/ChangeLog: 2019-07-09 Pedro Alves <palves@redhat.com> * gdb.cp/catch-multi-stdlib.exp: Adjust expected "info breakpoints" output. * gdb.cp/exception.exp: Adjust expected "info breakpoints" output. * gdb.python/py-breakpoint.exp: No longer expect that "catch throw" creates breakpoint. * gdb.mi/mi-catch-cpp-exceptions.exp (setup_catchpoint): Expect 'type="catchpoint"'.
2019-06-13"set print raw frame-arguments" -> "set print raw-frame-arguments"Pedro Alves1-2/+2
A following patch will introduce options for the "backtrace" command, based on some "set print" and "set backtrace" settings. There's one setting in particular that is a bit annoying if we want to describe the backtrace options and the settings commands using the same data structures: "set print raw frame-arguments" The problem is that space between "raw" and "frame-arguments". Calling the option "bt -raw frame-arguments" would be odd. So I'm calling the option "bt -raw-frame-arguments" instead. And for consistency, this patch renames the set/show commands to: "set print raw-frame-arguments" "show print raw-frame-arguments" I.e., dash instead of space. The old commands are left in place, but marked deprecated. We need to adjust a couple testcases, because the relevant tests use gdb_test_no_output and the old commands are no longer silent: (gdb) set print raw frame-arguments on Warning: command 'set print raw frame-arguments' is deprecated. Use 'set print raw-frame-arguments'. gdb/ChangeLog: 2019-06-13 Pedro Alves <palves@redhat.com> * NEWS (Changed commands): Mention set/show print raw-frame-arguments, and that "set/show print raw frame-arguments" are now deprecated. * cli/cli-decode.c (add_setshow_boolean_cmd): Now returns the command. * command.h (add_setshow_boolean_cmd): Return cmd_list_element *. * stack.c (_initialize_stack): Install "set/show print raw-frame-arguments", and deprecate "set/show print raw frame-arguments". * valprint.c (_initialize_valprint): Deprecate "set/show print raw". gdb/doc/ChangeLog: 2019-06-13 Pedro Alves <palves@redhat.com> * gdb.texinfo (Print Settings): Document "set/show print raw-frame-arguments" instead of "set/show print raw frame-arguments". gdb/testsuite/ChangeLog: 2019-06-13 Pedro Alves <palves@redhat.com> * gdb.guile/scm-frame-args.exp: Use "set print raw-frame-arguments" instead of "set print raw frame-arguments". * gdb.python/py-frame-args.exp: Likewise.
2019-06-04Add an objfile getter to gdb.TypeChristian Biesinger via gdb-patches1-0/+4
This allows users of the Python API to find the objfile where a type was defined. gdb/ChangeLog: gdb/ChangeLog 2019-06-04 Christian Biesinger <cbiesinger@google.com> Add objfile property to gdb.Type. * gdb/NEWS: Mention Python API addition. * gdb/python/py-type.c (typy_get_objfile): New method. gdb/doc/ChangeLog 2019-06-04 Christian Biesinger <cbiesinger@google.com> * gdb/doc/python.texi: Document new gdb.Type.objfile property. gdb/testsuite/ChangeLog 2019-06-04 Christian Biesinger <cbiesinger@google.com> * gdb/testsuite/gdb.python/py-type.exp: Test for new gdb.Type.objfile property.
2019-06-03Update tests following changes to "help" and "apropos"Philippe Waroquiers1-1/+1
Factorizes the testing of the help output, by having a single place that defines the common help trailer and/or prefix messages.
2019-05-22[gdb/testsuite] Add missing mi_skip_python_tests to ↵Tom de Vries1-0/+3
py-mi-var-info-path-expression.exp Fix gdb.python/py-mi-var-info-path-expression.exp for a gdb build without python support. gdb/testsuite/ChangeLog: 2019-05-22 Tom de Vries <tdevries@suse.de> PR testsuite/24586 * gdb.python/py-mi-var-info-path-expression.exp: Call mi_skip_python_tests to check if python is supported.
2019-05-17testsuite: Disable some tests when loggingAlan Hayward1-1/+4
Fix up all failures encountered when running the testsuite with GDB_DEBUG="infrun". Some tests rely on enabling debugging for various components. With debugging on, this will be lost to the debug file. Disable separate tty for mi tests when debugging. This currently does not work. disasm.c should send errors to the stderr instead of the logfile. Note that enabling debug for other components might still cause additional errors above what has been fixed here. gdb/ChangeLog: * disasm.c (set_disassembler_options): Send errors to stderr. gdb/testsuite/ChangeLog: * gdb.base/breakpoint-in-ro-region.exp: Disable when debugging. * gdb.base/debug-expr.exp: Likewise. * gdb.base/foll-fork.exp: Likewise. * gdb.base/foll-vfork.exp: Likewise. * gdb.base/fork-print-inferior-events.exp: Likewise. * gdb.base/gdb-sigterm.exp: Likewise. * gdb.base/gdbinit-history.exp: Likewise. * gdb.base/osabi.exp: Likewise. * gdb.base/sss-bp-on-user-bp-2.exp: Likewise. * gdb.base/ui-redirect.exp: Likewise. * gdb.gdb/unittest.exp: Likewise. * gdb.mi/mi-break.exp: Disable separate-mi-tty when debugging. * gdb.mi/mi-watch.exp: Likewise. * gdb.mi/new-ui-mi-sync.exp: Likewise. * gdb.mi/user-selected-context-sync.exp: Likewise. * gdb.python/python.exp: Disable debug test when debugging. * gdb.threads/check-libthread-db.exp: Disable when debugging. * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Likewise. * gdb.threads/stepi-random-signal.exp: Likewise.
2019-05-08Correctly handle non-C-style arrays in c_get_stringTom Tromey1-0/+13
A user here noticed that the Python Value.string method did not work for Ada arrays. I tracked this down to an oddity in value_as_address -- namely, it calls coerce_array, but that function will not force array coercion when the language has c_style_arrays=false, as Ada does. This patch fixes the problem by changing c_get_string so that arrays take the "in GDB's memory" branch. The actual patch is somewhat more complicated than you might think, because the caller can request more array elements than the type allows. This is normal when the type is using the C struct hack. Tested on x86-64 Fedora 29. gdb/ChangeLog 2019-05-08 Tom Tromey <tromey@adacore.com> * c-lang.c (c_get_string): Handle non-C-style arrays. gdb/testsuite/ChangeLog 2019-05-08 Tom Tromey <tromey@adacore.com> * gdb.python/py-value.exp (test_value_in_inferior): Add Ada test.
2019-04-29gdb: Introduce 'print max-depth' featureAndrew Burgess4-0/+524
Introduce a new print setting max-depth which can be set with 'set print max-depth DEPTH'. The default value of DEPTH is 20, but this can also be set to unlimited. When GDB is printing a value containing nested structures GDB will stop descending at depth DEPTH. Here is a small example: typedef struct s1 { int a; } s1; typedef struct s2 { s1 b; } s2; typedef struct s3 { s2 c; } s3; typedef struct s4 { s3 d; } s4; s4 var = { { { { 3 } } } }; The following table shows how various depth settings affect printing of 'var': | Depth Setting | Result of 'p var' | |---------------+--------------------------------| | Unlimited | $1 = {d = {c = {b = {a = 3}}}} | | 4 | $1 = {d = {c = {b = {a = 3}}}} | | 3 | $1 = {d = {c = {b = {...}}}} | | 2 | $1 = {d = {c = {...}}} | | 1 | $1 = {d = {...}} | | 0 | $1 = {...} | Only structures, unions, and arrays are replaced in this way, scalars and strings are not replaced. The replacement is counted from the level at which you print, not from the top level of the structure. So, consider the above example and this GDB session: (gdb) set print max-depth 2 (gdb) p var $1 = {d = {c = {...}}} (gdb) p var.d $2 = {c = {b = {...}}} (gdb) p var.d.c $3 = {b = {a = 3}} Setting the max-depth to 2 doesn't prevent the user from exploring deeper into 'var' by asking for specific sub-fields to be printed. The motivation behind this feature is to try and give the user more control over how much is printed when examining large, complex data structures. The default max-depth of 20 means that there is a change in GDB's default behaviour. Someone printing a data structure with 20 levels of nesting will now see '{...}' instead of their data, they would need to adjust the max depth, or call print again naming a specific field in order to dig deeper into their data structure. If this is considered a problem then we could increase the default, or even make the default unlimited. This commit relies on the previous commit, which added a new field to the language structure, this new field was a string that contained the pattern that should be used when a structure/union/array is replaced in the output, this allows languages to use a syntax that is more appropriate, mostly this will be selecting the correct types of bracket '(...)' or '{...}', both of which are currently in use. This commit should have no impact on MI output, expressions are printed through the MI using -var-create and then -var-list-children. As each use of -var-list-children only ever displays a single level of an expression then the max-depth setting will have no impact. This commit also adds the max-depth mechanism to the scripting language pretty printers following basically the same rules as for the built in value printing. One quirk is that when printing a value using the display hint 'map', if the keys of the map are structs then GDB will hide the keys one depth level after it hides the values, this ensures that GDB produces output like this: $1 = map_object = {[{key1}] = {...}, [{key2}] = {...}} Instead of this less helpful output: $1 = map_object = {[{...}] = {...}, [{...}] = {...}} This is covered by the new tests in gdb.python/py-nested-maps.exp. gdb/ChangeLog: * cp-valprint.c (cp_print_value_fields): Allow an additional level of depth when printing anonymous structs or unions. * guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (ppscm_print_children): When printing the key of a map, allow one extra level of depth. * python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (print_children): When printing the key of a map, allow one extra level of depth. * python/py-value.c (valpy_format_string): Add max_depth keyword. * valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define. (user_print_options): Initialise max_depth field. (val_print_scalar_or_string_type_p): New function. (val_print): Check to see if the max depth has been reached. (val_print_check_max_depth): Define new function. (show_print_max_depth): New function. (_initialize_valprint): Add 'print max-depth' option. * valprint.h (struct value_print_options) <max_depth>: New field. (val_print_check_max_depth): Declare new function. * NEWS: Document new feature. gdb/doc/ChangeLog: * gdb.texinfo (Print Settings): Document 'print max-depth'. * guile.texi (Guile Pretty Printing API): Document that 'print max-depth' can effect the display of a values children. * python.texi (Pretty Printing API): Likewise. (Values From Inferior): Document max_depth keyword. gdb/testsuite/ChangeLog: * gdb.base/max-depth.c: New file. * gdb.base/max-depth.exp: New file. * gdb.python/py-nested-maps.c: New file. * gdb.python/py-nested-maps.exp: New file. * gdb.python/py-nested-maps.py: New file. * gdb.python/py-format-string.exp (test_max_depth): New proc. (test_all_common): Call test_max_depth. * gdb.fortran/max-depth.exp: New file. * gdb.fortran/max-depth.f90: New file. * gdb.go/max-depth.exp: New file. * gdb.go/max-depth.go: New file. * gdb.modula2/max-depth.exp: New file. * gdb.modula2/max-depth.c: New file. * lib/gdb.exp (get_print_expr_at_depths): New proc.
2019-04-08Rename python function thread_from_thread_handle to thread_from_handleKevin Buettner1-15/+15
This renaming was done to stay consistent with the naming of the new gdb.InferiorThread.handle method. I had initially named it "thread_handle" but Tom Tromey suggested just "handle". The old name (thread_from_thread_handle) still works, but is marked as deprecated in comments in the code as well as in the documentation. I have some code which uses these functions. I very much like the brevity of the new names. gdb/doc/ChangeLog: * python.texi (Inferiors In Python): Rename Inferior.thread_from_thread_handle to Inferior.thread_from_handle. Add note about the former being deprecated. gdb/ChangeLog: * python/py-inferior.c (infpy_thread_from_thread_handle): Adjust comments to reflect renaming of thread_from_thread_handle to thread_from_handle. Adjust keywords. Fix type error message. (inferior_object_methods): Add thread_from_handle. Retain thread_from_thread_handle, but mark it as deprecated. testsuite/ChangeLog: * gdb.python/py-thrhandle.exp: Adjust tests to call thread_from_handle instead of thread_from_thread_handle.
2019-04-08Tests for gdb.InferiorThread.handleKevin Buettner1-3/+39
gdb/testsuite/ChangeLog: * gdb.python/py-thrhandle.exp: Add tests for gdb.InferiorThread.handle.
2019-04-01gdb/fortran: Handle internal function callsAndrew Burgess1-1/+7
If an convenience function is defined in python (or guile), then currently this will not work in Fortran, instead the user is given this message: (gdb) set language fortran (gdb) p $myfunc (3) Cannot perform substring on this type Compare this to C: (gdb) set language c (gdb) p $myfunc (3) $1 = 1 After this patch we see the same behaviour in both C and Fortran. I've extended the test to check that all languages can call the convenience functions - only Fortran was broken. When calling convenience functions in Fortran we don't need to perform the same value preparation (passing by pointer) that we would for calling a native function - passing the real value is fine. gdb/ChangeLog: * eval.c (evaluate_subexp_standard): Handle internal functions during Fortran function call handling. gdb/testsuite/ChangeLog: * gdb.python/py-function.exp: Check calling helper function from all languages. * lib/gdb.exp (gdb_supported_languages): New proc.
2019-04-01Add gdb.Value.format_string ()Marco Barisione3-0/+1124
The str () function, called on a gdb.Value instance, produces a string representation similar to what can be achieved with the print command, but it doesn't allow to specify additional formatting settings, for instance disabling pretty printers. This patch introduces a new format_string () method to gdb.Value which allows specifying more formatting options, thus giving access to more features provided by the internal C function common_val_print (). gdb/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> Add gdb.Value.format_string (). * python/py-value.c (copy_py_bool_obj): (valpy_format_string): Add gdb.Value.format_string (). * NEWS: Document the addition of gdb.Value.format_string (). gdb/doc/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> * python.texi (Values From Inferior): Document gdb.Value.format_string (). gdb/testsuite/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> Test gdb.Value.format_string (). * gdb.python/py-format-string.exp: New test. * gdb.python/py-format-string.c: New file. * gdb.python/py-format-string.py: New file.
2019-03-26gdb: Make python display_hint None handling defined behaviourAndrew Burgess3-1/+22
The documentation say that the display_hint method must return a string to serve as a display hint, and then goes on to list some acceptable strings. However, if we don't supply the display_hint method then we get a default display style behaviour and there's currently no way (in the python api) to force this default behaviour. The guile api allows #f to be used in order to force the default display style behaviour, and this is documented. Currently, using None in the python api also forces the default display behaviour. This commit extends the documentation to make returning None from the display_hint method an official mechanism by which the user can get the default display style. I've extended one of the existing tests to cover this case. gdb/doc/ChangeLog: * python.texi (Pretty Printing API): Document use of None for the display_hint. gdb/testsuite/ChangeLog: * gdb.python/py-prettyprint.c (struct container) <is_map_p>: New field. (make_container): Initialise new field. * gdb.python/py-prettyprint.exp: Add new tests. * gdb.python/py-prettyprint.py (class ContainerPrinter) <display_hint>: New method.
2019-03-26gdb/testsuite: Make test names unique in gdb.python/py-prettyprint.expAndrew Burgess1-12/+14
This makes the test names unique in gdb.python/py-prettyprint.exp, it also switches to use gdb_breakpoint and gdb_continue_to_breakpoint more so that we avoid test names with the source line number in - this is bad if the test source ever changes as the test names will then change. One final change is to switch from using gdb_py_test_silent_cmd to use gdb_test_no_output, the former should be used for running python commands and can catch any thrown exception. However, in this case the command being run is not a python command, its just a normal GDB CLI command that produces no output, so lets use the appropriate wrapper function. gdb/testsuite/ChangeLog: * gdb.python/py-prettyprint.exp: Use gdb_breakpoint and gdb_continue_to_breakpoint more throughout this test. (run_lang_tests) Supply unique test names, and use gdb_test_no_output.
2019-02-27Remove Python 2.4 and 2.5 supportTom Tromey1-7/+0
This removes all the remainings spots I could find that work around issues in Python 2.4 and 2.5. I don't have a good way to test that Python 2.6 still works. Tested by the buildbot. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround. gdb/testsuite/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * lib/gdb.exp (skip_python_tests_prompt): Don't check for Python 2.4. * gdb.python/py-finish-breakpoint.exp: Remove Python 2.4 workaround. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround.
2019-02-26Fix new py-value.exp test caseTom Tromey1-1/+1
The new test case in py-value.exp fails -- the code was changed to throw ValueError, but the test still checks for TypeError. This patch fixes the problem. I'm checking this in. Tested on x86-64 Fedora 29. gdb/testsuite/ChangeLog 2019-02-26 Tom Tromey <tromey@adacore.com> * gdb.python/py-value.exp (test_value_from_buffer): Check for ValueError, not TypeError.
2019-02-26Add tests for gdb.Value(bufobj, type) constructorKevin Buettner1-0/+45
gdb/testsuite/ChangeLog: * gdb.python/py-value.exp (test_value_from_buffer): New proc with call from main program.
2019-01-27Remove duplicate skip_python_tests invocationTom Tromey1-3/+0
I noticed that py-finish-breakpoint.exp had two calls to skip_python_tests, in quick succession. This patch removes the second one. gdb/testsuite/ChangeLog 2019-01-27 Tom Tromey <tom@tromey.com> * gdb.python/py-finish-breakpoint.exp: Remove duplicate call to skip_python_tests.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker155-155/+155
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-12-27Translate PyExc_KeyboardInterrupt to gdb "quit"Tom Tromey1-0/+40
A while back I typed "info pretty-printers" with a large number of printers installed, and I typed "q" to stop the pagination. I noticed that gdb printed a Python exception in this case. It seems to me that, instead, quitting pagination (or control-c'ing a Python command generally) should be handled the same way that gdb normally handles a quit. This patch implements this idea by changing gdbpy_handle_exception to treat PyExc_KeyboardInterrupt specially. gdb/ChangeLog 2018-12-27 Tom Tromey <tom@tromey.com> * python/py-utils.c (gdbpy_handle_exception): Translate PyExc_KeyboardInterrupt to quit. gdb/testsuite/ChangeLog 2018-12-27 Tom Tromey <tom@tromey.com> * gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add pagination test.
generated by cgit v1.1 at 2025-02-03 02:04:38 +0000