Commit graph

604 commits

Author SHA1 Message Date
Andrew Burgess
e0c23e11da gdb/python: don't allow the user to delete window title attributes
There's a bug in the python tui API.  If the user tries to delete the
window title attribute then this will trigger undefined behaviour in
GDB due to a missing nullptr check.

gdb/ChangeLog:

	* python/py-tui.c (gdbpy_tui_set_title): Check that the new value
	for the title is not nullptr.

gdb/testsuite/ChangeLog:

	* gdb.python/tui-window.exp: Add new tests.
	* gdb.python/tui-window.py (TestWindow) <__init__>: Store
	TestWindow object into global the_window.
	<remote_title>: New method.
	(delete_window_title): New function.
2021-02-08 11:55:05 +00:00
Andrew Burgess
2708dbbd58 gdb/python: reformat an error string
While working on another patch I noticed an oddly formatted error
message in the Python code.

When 'set python print-stack message' is in effect then consider this
Python script:

  class TestCommand (gdb.Command):
      def __init__ (self):
          gdb.Command.__init__ (self, "test-cmd", gdb.COMMAND_DATA)
      def invoke(self, args, from_tty):
          raise RuntimeError ("bad")
  TestCommand ()

And this GDB session:

  (gdb) source path/to/python/script.py
  (gdb) test-cmd
  Python Exception <class 'RuntimeError'> bad:
  Error occurred in Python: bad

The line 'Python Exception <class 'RuntimeError'> bad:' doesn't look
terrible in this situation, the colon at the end of the first line
makes sense given the second line.

However, there are places in GDB where there is no second line
printed, for example consider this python script:

  def stop_listener (e):
      raise RuntimeError ("bad")
  gdb.events.stop.connect (stop_listener)

Then this GDB session:

  (gdb) file helloworld.exe
  (gdb) start
  Temporary breakpoint 1 at 0x40112a: file hello.c, line 6.
  Starting program: helloworld.exe

  Temporary breakpoint 1, main () at hello.c:6
  6	  printf ("Hello World\n");
  Python Exception <class 'RuntimeError'> bad:
  (gdb) si
  0x000000000040112f	6	  printf ("Hello World\n");
  Python Exception <class 'RuntimeError'> bad:

In this case there is no auxiliary information displayed after the
warning, and the line ending in the colon looks weird to me.

A quick survey of the code seems to indicate that it is not uncommon
for there to be no auxiliary information line printed, its not just
the one case I found above.

I propose that the line that currently looks like this:

  Python Exception <class 'RuntimeError'> bad:

Be reformatted like this:

  Python Exception <class 'RuntimeError'>: bad

I think this looks fine then in either situation.  The first now looks
like this:

  (gdb) test-cmd
  Python Exception <class 'RuntimeError'>: bad
  Error occurred in Python: bad

And the second like this:

  (gdb) si
  0x000000000040112f	6	  printf ("Hello World\n");
  Python Exception <class 'RuntimeError'>: bad

There's just two tests that needed updating.  Errors are checked for
in many more tests, but most of the time the pattern doesn't care
about the colon.

gdb/ChangeLog:

	* python/python.c (gdbpy_print_stack): Reformat an error message.

gdb/testsuite/ChangeLog:

	* gdb.python/py-framefilter.exp: Update expected results.
	* gdb.python/python.exp: Update expected results.
2021-02-08 11:03:54 +00:00
Hannes Domani
325d39e4e0 Add Python support for hardware breakpoints
This allows the creation of hardware breakpoints in Python with
gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT)
And they are included in the sequence returned by gdb.breakpoints().

gdb/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

	PR python/19151
	* python/py-breakpoint.c (bppy_get_location): Handle
	bp_hardware_breakpoint.
	(bppy_init): Likewise.
	(gdbpy_breakpoint_created): Likewise.

gdb/doc/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

	PR python/19151
	* python.texi (Breakpoints In Python): Document
	gdb.BP_HARDWARE_BREAKPOINT.

gdb/testsuite/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

	PR python/19151
	* gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.
2021-01-21 18:55:45 +01:00
Tom de Vries
7c794afd54 [gdb/testsuite] Fix gdb.python/py-format-string.exp with -m32
When running test-case gdb.python/py-format-string.exp with target board
unix/-m32, we run into:
...
(gdb) python print \
  (gdb.parse_and_eval ('a_base_ref').format_string (deref_refs=True))^M
@0xffffc468: {_vptr.Base = 0x80487e0 <vtable for Deriv+8>, a = 42, \
              static a_static_member = 2019}^M
(gdb) FAIL: gdb.python/py-format-string.exp: format_string: \
  lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...
while with -m64, we have instead:
...
@0x7fffffffd170: {_vptr.Base = 0x400910 <vtable for Deriv+16>, a = 42, \
                  static a_static_member = 2019}^M
(gdb) PASS: gdb.python/py-format-string.exp: format_string: \
  lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...

The vtable contains pointer entries which are 4-byte for -m32 and 8-byte for
-m64, so it's not surprising the offsets (Deriv+8 vs. Deriv+16) differ.

Fix this by allow Deriv+$decimal.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-20  Tom de Vries  <tdevries@suse.de>

	* gdb.python/py-format-string.exp: Allow Deriv+$decimal as vtable
	offset.
2021-01-20 22:02:33 +01:00
Joel Brobecker
3666a04883 Update copyright year range in all GDB files
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-01 12:12:21 +04:00
Simon Marchi
391750c355 gdb/testsuite: de-duplicate test names in gdb.python/py-frame-args.exp
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-30 23:45:36 -05:00
Markus Metzger
493d2172ac testsuite, gdb.python: make py-record-*.exp test names unique
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-21 08:58:25 +01:00
Markus Metzger
98d837f0ef gdb, record: rephrase the 'not recording' error message
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-21 08:56:26 +01:00
Hannes Domani
fa639f555a Don't compare types of enum fields
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-19 13:41:44 +01:00
Hannes Domani
4aea001fd8 Add address keyword to Value.format_string
This makes it possible to disable the address in the result string:

const char *str = "alpha";

(gdb) py print(gdb.parse_and_eval("str").format_string())
0x404000 "alpha"
(gdb) py print(gdb.parse_and_eval("str").format_string(address=False))
"alpha"

gdb/ChangeLog:

2020-12-18  Hannes Domani  <ssbssa@yahoo.de>

	* python/py-value.c (valpy_format_string): Implement address keyword.

gdb/doc/ChangeLog:

2020-12-18  Hannes Domani  <ssbssa@yahoo.de>

	* python.texi (Values From Inferior): Document the address keyword.

gdb/testsuite/ChangeLog:

2020-12-18  Hannes Domani  <ssbssa@yahoo.de>

	* gdb.python/py-format-string.exp: Add tests for address keyword.
2020-12-18 22:04:16 +01:00
Hannes Domani
b3f9469bfa Fix accessing a method's fields from Python
Considering this example:

struct C
{
  int func() { return 1; }
} c;
int main()
{
  return c.func();
}

Accessing the fields of C::func, when requesting the function by its
type, works:

(gdb) py print(gdb.parse_and_eval('C::func').type.fields()[0].type)
C * const

But when trying to do the same via a class instance, it fails:

(gdb) py print(gdb.parse_and_eval('c')['func'].type.fields()[0].type)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: Type is not a structure, union, enum, or function type.
Error while executing Python code.

The difference is that in the former the function type is TYPE_CODE_FUNC:

(gdb) py print(gdb.parse_and_eval('C::func').type.code == gdb.TYPE_CODE_FUNC)
True

And in the latter the function type is TYPE_CODE_METHOD:

(gdb) py print(gdb.parse_and_eval('c')['func'].type.code == gdb.TYPE_CODE_METHOD)
True

So this adds the functionality for TYPE_CODE_METHOD as well.

gdb/ChangeLog:

2020-12-18  Hannes Domani  <ssbssa@yahoo.de>

	* python/py-type.c (typy_get_composite): Add TYPE_CODE_METHOD.

gdb/testsuite/ChangeLog:

2020-12-18  Hannes Domani  <ssbssa@yahoo.de>

	* gdb.python/py-type.exp: Add tests for TYPE_CODE_METHOD.
2020-12-18 22:02:13 +01:00
Andrew Burgess
50a5f1878e gdb: introduce new 'maint flush ' prefix command
We currently have two flushing commands 'flushregs' and 'maint
flush-symbol-cache'.  I'm planning to add at least one more so I
thought it might be nice if we bundled these together into one place.

And so I created the 'maint flush ' command prefix.  Currently there
are two commands:

  (gdb) maint flush symbol-cache
  (gdb) maint flush register-cache

Unfortunately, even though both of the existing flush commands are
maintenance commands, I don't know how keen we about deleting existing
commands for fear of breaking things in the wild.  So, both of the
existing flush commands 'maint flush-symbol-cache' and 'flushregs' are
still around as deprecated aliases to the new commands.

I've updated the testsuite to use the new command syntax, and updated
the documentation too.

gdb/ChangeLog:

	* NEWS: Mention new commands, and that the old commands are now
	deprecated.
	* cli/cli-cmds.c (maintenanceflushlist): Define.
	* cli/cli-cmds.h (maintenanceflushlist): Declare.
	* maint.c (_initialize_maint_cmds): Initialise
	maintenanceflushlist.
	* regcache.c: Add 'cli/cli-cmds.h' include.
	(reg_flush_command): Add header comment.
	(_initialize_regcache): Create new 'maint flush register-cache'
	command, make 'flushregs' an alias.
	* symtab.c: Add 'cli/cli-cmds.h' include.
	(_initialize_symtab): Create new 'maint flush symbol-cache'
	command, make old command an alias.

gdb/doc/ChangeLog:

	* gdb.texinfo (Symbols): Document 'maint flush symbol-cache'.
	(Maintenance Commands): Document 'maint flush register-cache'.

gdb/testsuite/ChangeLog:

	* gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...'
	commands.
	* gdb.base/killed-outside.exp: Likewise.
	* gdb.opt/inline-bt.exp: Likewise.
	* gdb.perf/gmonster-null-lookup.py: Likewise.
	* gdb.perf/gmonster-print-cerr.py: Likewise.
	* gdb.perf/gmonster-ptype-string.py: Likewise.
	* gdb.python/py-unwind.exp: Likewise.
2020-12-13 12:36:15 +00:00
Tom de Vries
99cc6b2abf [gdb/testsuite] Fix gdb.python/py-symbol.exp with -readnow
When running test-case gdb.python/py-symbol.exp with target board readnow, we
get:
...
FAIL: gdb.python/py-symbol.exp: print line number of rr
FAIL: gdb.python/py-symbol.exp: print value of rr
...

These are FAILs due to PR25857.

Mark these FAILs as KFAILs.

gdb/testsuite/ChangeLog:

2020-10-28  Tom de Vries  <tdevries@suse.de>

	* gdb.python/py-symbol.exp: Add KFAILs for -readnow.
2020-10-28 21:04:12 +01:00
Gary Benson
934a176407 Fix gdb.python/py-format-string.exp with Clang
GDB includes the virtual table pointer when formatting polymorphic
C++ objects for printing, but GCC and Clang name these differently:
GCC emits a DW_AT_name of "_vptr.Base" when describing the virtual
table pointer of a type derived from type "Base", whereas Clang
will emit "_vptr$Base" in this situation.  This commit fixes a
testcase which failed because of this.

gdb/testsuite/ChangeLog:

	* gdb.python/py-format-string.exp (test_deref_refs): Treat
	"_vptr$Base" as correct, in addition to "_vptr.Base".
	(test_mixed): Likewise.
2020-10-27 17:02:39 +00:00
Pedro Alves
b75d55d4d2 Eliminate mi_run_to_main, introduce mi_clean_restart
Since we now have mi_runto_main which is like runto_main, eliminate
mi_run_to_main, in favor of a new MI clean_restart counterpart --
mi_clean_restart -- and mi_runto_main.

This makes MI testcases look a bit more like CLI testcases.

gdb/testsuite/ChangeLog:

	* lib/mi-support.exp (mi_clean_restart): New.
	(mi_run_to_main): Delete.
	All callers adjust to use mi_clean_restart / mi_runto_main.

Change-Id: I34920bab4fea1f23fb752928c2969c1f6ad714b6
2020-10-13 22:34:54 +01:00
Pedro Alves
e777225bfd gdb/testsuite/: Use "-qualified" in explicit "break main", etc.
Similar to the previous patch, but this time add "-q" to tests that do
"break main", "list main", etc. explicitly.

gdb/testsuite/ChangeLog:

	* config/monitor.exp: Use "list -q".
	* gdb.arch/gdb1558.exp: Use "break -q".
	* gdb.arch/i386-permbkpt.exp: Use "break -q".
	* gdb.arch/i386-prologue-skip-cf-protection.exp: Use "break -q".
	* gdb.base/break.exp: Use "break -q", "list -q" and "tbreak -q".
	* gdb.base/commands.exp: Use "break -q".
	* gdb.base/condbreak.exp: Use "break -q".
	* gdb.base/ctf-ptype.exp: Use "list -q".
	* gdb.base/define.exp: Use "break -q".
	* gdb.base/del.exp: Use "break -q".
	* gdb.base/fullname.exp: Use "break -q".
	* gdb.base/hbreak-in-shr-unsupported.exp: Use "hbreak -q".
	* gdb.base/hbreak-unmapped.exp: Use "hbreak -q".
	* gdb.base/hbreak2.exp: Use "hbreak -q" and "list -q".
	* gdb.base/hw-sw-break-same-address.exp: Use "break -q" and
	"hbreak -q".
	* gdb.base/included.exp: Use "list -q".
	* gdb.base/label.exp: Use "break -q".
	* gdb.base/lineinc.exp: Use "break -q".
	* gdb.base/list.exp: Use "list -q".
	* gdb.base/macscp.exp: Use "list -q".
	* gdb.base/pending.exp: Use "break -q".
	* gdb.base/prologue-include.exp: Use "break -q".
	* gdb.base/ptype.exp: Use "list -q".
	* gdb.base/sepdebug.exp: Use "break -q", "list -q" and "tbreak -q".
	* gdb.base/server-del-break.exp: Use "break -q".
	* gdb.base/style.exp: Use "break -q".
	* gdb.base/symbol-without-target_section.exp: Use "list -q".
	* gdb.base/watchpoint-reuse-slot.exp: Use "hbreak -q".
	* gdb.cp/exception.exp: Use "tbreak -q".
	* gdb.dwarf2/dw2-error.exp: Use "break -q".
	* gdb.dwarf2/fission-mix.exp: Use "break -q".
	* gdb.dwarf2/fission-reread.exp: Use "break -q".
	* gdb.dwarf2/pr13961.exp: Use "break -q".
	* gdb.linespec/explicit.exp: Use "list -q".
	* gdb.linespec/linespec.exp: Use "break -q".
	* gdb.mi/mi-simplerun.exp: Use "--qualified".
	* gdb.python/py-mi-objfile-gdb.py: Use "list -q".
	* gdb.server/bkpt-other-inferior.exp: Use "break -q".
	* gdb.server/connect-without-multi-process.exp: Use "break -q".
	* gdb.trace/change-loc.exp: Use "break -q".
	* gdb.trace/pending.exp: Use "break -q".
	* gdb.tui/basic.exp: Use "list -q".
	* gdb.tui/list-before.exp: Use "list -q".
	* gdb.tui/list.exp: Use "list -q".
	* lib/gdb.exp (gdb_has_argv0): Use "break -q".

Change-Id: Iab9408e90ed71cbb111cd737d2d81b5ba8adb108
2020-10-13 22:34:26 +01:00
Pedro Alves
f71e6719e1 Introduce mi_runto_main
This adds an mi_runto_main routine, very much like the runto_main CLI
counterpart.

Note there's already a mi_run_to_main (extra underscore in "run_to"),
but unlike its intro comment says, that does more than the CLI's
runto_main -- it also starts GDB.  I would like to eliminate that
other one by introducing a mi_clean_restart function instead.  That is
done later in the series.

gdb/testsuite/ChangeLog:

	* lib/mi-support.exp (mi_runto_main): New proc.
	(mi_run_to_main): Use it.
	* gdb.mi/mi-catch-cpp-exceptions.exp: Likewise.
	* gdb.mi/mi-var-cmd.exp: Likewise.
	* gdb.mi/mi-var-invalidate.exp: Likewise.
	* mi-var-list-children-invalid-grandchild.exp: Likewise.
	* gdb.mi/mi2-amd64-entry-value.exp: Likewise.
	* gdb.mi/new-ui-mi-sync.exp: Likewise.
	* gdb.mi/user-selected-context-sync.exp: Likewise.
	* gdb.opt/inline-cmds.exp: Likewise.
	* gdb.python/py-framefilter-mi.exp: Likewise.
	* gdb.python/py-mi.exp: Likewise.

Change-Id: I2e49ca7b0b61cea57c1202e5dfa32417e6a4403d
2020-10-13 22:28:03 +01:00
Pedro Alves
50441f0f8c 'runto main' -> 'runto_main' throughout
This commit does 's/runto main/runto_main/g' throughout.

gdb/testsuite/ChangeLog:

	* gdb.ada/fun_in_declare.exp: Use "runto_main" instead of
	"runto main".
	* gdb.ada/small_reg_param.exp: Likewise.
	* gdb.arch/powerpc-d128-regs.exp: Likewise.
	* gdb.base/annota1.exp: Likewise.
	* gdb.base/anon.exp: Likewise.
	* gdb.base/breakpoint-in-ro-region.exp: Likewise.
	* gdb.base/dprintf-non-stop.exp: Likewise.
	* gdb.base/dprintf.exp: Likewise.
	* gdb.base/gdb11530.exp: Likewise.
	* gdb.base/gdb11531.exp: Likewise.
	* gdb.base/gnu_vector.exp: Likewise.
	* gdb.base/interrupt-noterm.exp: Likewise.
	* gdb.base/memattr.exp: Likewise.
	* gdb.base/step-over-syscall.exp: Likewise.
	* gdb.base/watch-cond-infcall.exp: Likewise.
	* gdb.base/watch-read.exp: Likewise.
	* gdb.base/watch-vfork.exp: Likewise.
	* gdb.base/watch_thread_num.exp: Likewise.
	* gdb.base/watchpoint-stops-at-right-insn.exp: Likewise.
	* gdb.guile/scm-frame-inline.exp: Likewise.
	* gdb.linespec/explicit.exp: Likewise.
	* gdb.opt/inline-break.exp: Likewise.
	* gdb.python/py-frame-inline.exp: Likewise.
	* gdb.reverse/break-precsave.exp: Likewise.
	* gdb.reverse/break-reverse.exp: Likewise.
	* gdb.reverse/consecutive-precsave.exp: Likewise.
	* gdb.reverse/consecutive-reverse.exp: Likewise.
	* gdb.reverse/finish-precsave.exp: Likewise.
	* gdb.reverse/finish-reverse.exp: Likewise.
	* gdb.reverse/fstatat-reverse.exp: Likewise.
	* gdb.reverse/getresuid-reverse.exp: Likewise.
	* gdb.reverse/i386-precsave.exp: Likewise.
	* gdb.reverse/i386-reverse.exp: Likewise.
	* gdb.reverse/i386-sse-reverse.exp: Likewise.
	* gdb.reverse/i387-env-reverse.exp: Likewise.
	* gdb.reverse/i387-stack-reverse.exp: Likewise.
	* gdb.reverse/insn-reverse.exp: Likewise.
	* gdb.reverse/machinestate-precsave.exp: Likewise.
	* gdb.reverse/machinestate.exp: Likewise.
	* gdb.reverse/pipe-reverse.exp: Likewise.
	* gdb.reverse/readv-reverse.exp: Likewise.
	* gdb.reverse/recvmsg-reverse.exp: Likewise.
	* gdb.reverse/rerun-prec.exp: Likewise.
	* gdb.reverse/s390-mvcle.exp: Likewise.
	* gdb.reverse/solib-precsave.exp: Likewise.
	* gdb.reverse/solib-reverse.exp: Likewise.
	* gdb.reverse/step-precsave.exp: Likewise.
	* gdb.reverse/step-reverse.exp: Likewise.
	* gdb.reverse/time-reverse.exp: Likewise.
	* gdb.reverse/until-precsave.exp: Likewise.
	* gdb.reverse/until-reverse.exp: Likewise.
	* gdb.reverse/waitpid-reverse.exp: Likewise.
	* gdb.reverse/watch-precsave.exp: Likewise.
	* gdb.reverse/watch-reverse.exp: Likewise.
	* gdb.threads/kill.exp: Likewise.
	* gdb.threads/tid-reuse.exp: Likewise.

Change-Id: I70f457253836019880b4d7fb981936afa56724c2
2020-10-13 22:27:43 +01:00
Gary Benson
71e1b6b0ac Fix testcases with required but unreferenced functions and variables
A number of testcases define variables and/or functions which are
referenced by GDB during the test, but which are not referenced from
within the test executable.  Clang correctly recognizes that these
variables and functions are unused, and optimizes them out, causing
the testcases in question to fail.  This commit adds __attribute__
((used)) in various places to prevent this.

gdb/testsuite/ChangeLog:

	* gdb.base/msym-bp.c (foo): Add __attribute__ ((used)).
	* gdb.base/msym-bp-2.c (foo): Likewise.
	* gdb.base/msym-lang.c (foo): Likewise.
	* gdb.base/msym-lang-main.c (foo): Likewise.
	* gdb.base/symtab-search-order-1.c (static_global): Likewise.
	* gdb.guile/scm-pretty-print.c (eval_func): Likewise.
	* gdb.mi/mi-sym-info-1.c (global_f1): Likewise.
	* gdb.mi/mi-sym-info-2.c (global_f1, var1, var2): Likewise.
	* gdb.multi/watchpoint-multi-exit.c (globalvar): Likewise.
	* gdb.python/py-as-string.c (enum_valid, enum_invalid): Likewise.
	* gdb.python/py-objfile.c (static_var): Likewise.
	* gdb.python/py-symbol.c (rr): Likewise.
	* gdb.python/py-symbol-2.c (anon, rr): Likewise.
	* gdb.mi/mi-sym-info.exp (lineno1, lineno2): Updated.
2020-10-12 10:35:23 +01:00
Gareth Rees
8f9929bb97 gdb: Fix from_tty argument to gdb.execute in Python.
Prior to commit 56bcdbea2b, the from_tty keyword argument to the
Python function gdb.execute controlled whether the command took input
from the terminal. When from_tty=True, "starti" and similar commands
prompted the user:

    (gdb) python gdb.execute("starti", from_tty=True)
    The program being debugged has been started already.
    Start it from the beginning? (y or n) y
    Starting program: /bin/true

    Program stopped.

When from_tty=False, these commands did not prompt the user, and "yes"
was assumed:

    (gdb) python gdb.execute("starti", from_tty=False)

    Program stopped.

However, after commit 56bcdbea2b, the from_tty keyword argument no
longer had this effect. For example, as of commit 7ade7fba75:

    (gdb) python gdb.execute("starti", from_tty=True)
    The program being debugged has been started already.
    Start it from the beginning? (y or n) [answered Y; input not from terminal]
    Starting program: /bin/true

    Program stopped.

Note the "[answered Y; input not from terminal]" in the output even
though from_tty=True was requested.

Looking at commit 56bcdbea2b, it seems that the behaviour of the
from_tty argument was changed accidentally. The commit message said:

    Let gdb.execute handle multi-line commands

    This changes the Python API so that gdb.execute can now handle
    multi-line commands, like "commands" or "define".

and there was no mention of changing the effect of the from_tty
argument. It looks as though the code for setting the instream to
nullptr was accidentally moved from execute_user_command() to
execute_control_commands() along with the other scoped restores.

Accordingly, the simplest way to fix this is to partially reverse
commit 56bcdbea2b by moving the code for setting the instream to
nullptr back to execute_user_command() where it was to begin with.

Additionally, add a test case to reduce the risk of similar breakage
in future.

gdb/ChangeLog:

	PR python/26586
	* cli/cli-script.c (execute_control_commands): don't set
	instream to nullptr here as this breaks the from_tty argument
	to gdb.execute in Python.
	(execute_user_command): set instream to nullptr here instead.

gdb/testsuite/ChangeLog:

	PR python/26586
	* gdb.python/python.exp: add test cases for the from_tty
	argument to gdb.execute.
2020-09-26 11:01:45 -07:00
Pedro Alves
dd23068d52 gdb.python/py-frame-inline.exp and C++
Make the testcase work when built with a C++ compiler.

gdb/testsuite/ChangeLog:

	* gdb.python/py-frame-inline.exp: Adjust to optionally expect a
	full prototype.
2020-09-18 00:09:02 +01:00
Pedro Alves
0640a54339 gdb.python/py-as-string.exp C++ify
Make the testcase buildable with a C++ compiler.

gdb/testsuite/ChangeLog:

	* gdb.python/py-as-string.c: Add cast.
2020-09-18 00:08:44 +01:00
Pedro Alves
a83cdcb636 gdb.python/py-nested-maps.exp C++ify
This adjusts gdb.python/py-nested-maps.c to make it buildable as C++ program.

key_t is renamed because of:

  src/gdb/testsuite/gdb.python/py-nested-maps.c:23:8: error: definition of type 'key_t' conflicts with typedef of the same name
  struct key_t
	 ^
  /usr/include/x86_64-linux-gnu/sys/types.h:121:17: note: 'key_t' declared here
  typedef __key_t key_t;
		  ^

gdb/testsuite/ChangeLog:

	* gdb.python/py-nested-maps.c (struct key_t): Rename to...
	(struct my_key_t): ... this.  Adjust all references.
	(struct value_t): Rename to ...
	(struct my_value_t): ... this.  Adjust all references.
	(create_map, add_map_element, create_map_map)
	(add_map_map_element): Add casts.
2020-09-18 00:07:22 +01:00
Pedro Alves
d4bcee5ccc gdb.python/{py-framefilter-mi,py-framefilter}.c C++ify
This adjusts:

 gdb.python/{py-framefilter-mi,py-framefilter}.c

to make them buildable as C++ programs.

gdb/testsuite/ChangeLog:

	* gdb.python/py-framefilter-mi.c (funca): Add casts.
	* gdb.python/py-framefilter.c.c (funca, func2): Add casts.
2020-09-18 00:07:03 +01:00
Pedro Alves
dc3a371e83 gdb/testsuite: Explicitly return from main
I've been playing with a board file that forces every testcase to
include a header file that does something like:

  #define main __gdb_testcase_main

and then links an actual main() function that does some
initialization and then jumps to __gdb_testcase_main.

That runs into a number of testcases relying on main not having an
explicit return statement, like e.g.,:

 gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/catch-follow-exec.c:27:1: warning: non-void function does not return a value [-Wreturn-type]
 gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/catch-signal.c:47:1: warning: non-void function does not return a value [-Wreturn-type]

We don't get those warnings without my board because it is valid to
not explicitly return from main.  There's an implicit "return 0;".

Since it doesn't hurt to be explicit, I've went ahead and added the
explicit return statements.

Also, a couple testcases either don't explicitly specify main's return
type, or return void.  Those are tweaked to explicitly return int.

gdb/testsuite/ChangeLog:

	* gdb.base/catch-follow-exec.c (main): Add explicit return
	statement.
	* gdb.base/catch-signal.c (main): Likewise.
	* gdb.base/condbreak-call-false.c (main): Likewise.
	* gdb.base/consecutive.c (main): Add explicit return
	statement and return type.
	* gdb.base/cursal.c (main): Add explicit return statement.
	* gdb.base/cvexpr.c (main): Likewise.
	* gdb.base/display.c (main): Add explicit return statement and
	return type.
	* gdb.base/dprintf-detach.c (main): Add explicit return statement.
	* gdb.base/endianity.c (main): Likewise.
	* gdb.base/execd-prog.c (main): Likewise.
	* gdb.base/gdb1090.c (main): Likewise.
	* gdb.base/info_qt.c (main): Likewise.
	* gdb.base/lineinc.c (main): Likewise.
	* gdb.base/load-command.c (main): Likewise.
	* gdb.base/macscp1.c (main): Likewise.
	* gdb.base/pr10179-a.c (main): Likewise.
	* gdb.base/quit-live.c (main): Likewise.
	* gdb.base/scope0.c (main): Likewise.
	* gdb.base/settings.c (main): Likewise.
	* gdb.base/stack-checking.c (main): Return int.
	* gdb.base/varargs.c (main): Add explicit return statement.
	* gdb.cp/ambiguous.cc (main): Likewise.
	* gdb.cp/anon-struct.cc (main): Likewise.
	* gdb.cp/anon-union.cc (main): Likewise.
	* gdb.cp/bool.cc (main): Likewise.
	* gdb.cp/bs15503.cc (main): Likewise.
	* gdb.cp/cplusfuncs.cc (main): Likewise.
	* gdb.cp/cttiadd.cc (main): Likewise.
	* gdb.cp/extern-c.cc (main): Likewise.
	* gdb.cp/filename.cc (main): Likewise.
	* gdb.cp/formatted-ref.cc (main): Likewise.
	* gdb.cp/mb-ctor.cc (main): Likewise.
	* gdb.cp/member-ptr.cc (main): Likewise.
	* gdb.cp/minsym-fallback-main.cc (main): Likewise.
	* gdb.cp/overload-const.cc (main): Likewise.
	* gdb.cp/paren-type.cc (main): Likewise.
	* gdb.cp/parse-lang.cc (main): Likewise.
	* gdb.cp/pr-1023.cc (main): Likewise.
	* gdb.cp/psmang1.cc (main): Likewise.
	* gdb.cp/readnow-language.cc (main): Likewise.
	* gdb.cp/ref-params.cc (main): Likewise.
	* gdb.cp/rvalue-ref-params.cc (main): Likewise.
	* gdb.cp/virtbase2.cc (main): Likewise.
	* gdb.dwarf2/dw2-abs-hi-pc.c (main): Likewise.
	* gdb.dwarf2/dw2-namespaceless-anonymous.c (main): Likewise.
	* gdb.dwarf2/dw4-toplevel-types.cc (main): Likewise.
	* gdb.mi/mi-console.c (main): Likewise.
	* gdb.mi/mi-read-memory.c (main): Likewise.
	* gdb.modula2/multidim.c (main): Likewise.
	* gdb.opt/inline-small-func.c (main): Likewise.
	* gdb.python/py-rbreak.c (main): Likewise.
	* gdb.stabs/exclfwd1.c (main): Likewise.
	* gdb.trace/qtro.c (main): Likewise.
2020-09-13 22:47:01 +01:00
Andrew Burgess
43d5901ded gdb/python: make more use of RegisterDescriptors
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.

Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number.  I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind.  However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.

Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.

This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.

The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly.  However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.

As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.

After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.

gdb/ChangeLog:

	* python/py-frame.c: Remove 'user-regs.h' include.
	(frapy_read_register): Rewrite to make use of
	gdbpy_parse_register_id.
	* python/py-registers.c (gdbpy_parse_register_id): New function,
	moved here from python/py-unwind.c.  Updated the return type, and
	also accepts register descriptor objects.
	* python/py-unwind.c: Remove 'user-regs.h' include.
	(pyuw_parse_register_id): Moved to python/py-registers.c.
	(unwind_infopy_add_saved_register): Update to use
	gdbpy_parse_register_id.
	(pending_framepy_read_register): Likewise.
	* python/python-internal.h (gdbpy_parse_register_id): Declare.

gdb/testsuite/ChangeLog:

	* gdb.python/py-unwind.py: Update to make use of a register
	descriptor.

gdb/doc/ChangeLog:

	* python.texi (Unwinding Frames in Python): Update descriptions
	for PendingFrame.read_register and
	gdb.UnwindInfo.add_saved_register.
	(Frames In Python): Update description of Frame.read_register.
2020-07-28 10:27:54 +01:00
Andrew Burgess
14fa8fb307 gdb: Add a find method for RegisterDescriptorIterator
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class,
this allows gdb.RegisterDescriptor objects to be looked up directly by
register name rather than having to iterate over all registers.

This will be of use for a later commit.

I've documented the new function in the manual, but I don't think a
NEWS entry is required here, as, since the last release, the whole
register descriptor mechanism is new, and is already mentioned in the
NEWS file.

gdb/ChangeLog:

	* python/py-registers.c: Add 'user-regs.h' include.
	(register_descriptor_iter_find): New function.
	(register_descriptor_iterator_object_methods): New static global
	methods array.
	(register_descriptor_iterator_object_type): Add pointer to methods
	array.

gdb/testsuite/ChangeLog:

	* gdb.python/py-arch-reg-names.exp: Add additional tests.

gdb/doc/ChangeLog:

	* python.texi (Registers In Python): Document new find function.
2020-07-28 10:27:53 +01:00
Andrew Burgess
baf8791efb gdb/python: Reuse gdb.RegisterGroup objects where possible
Only create one gdb.RegisterGroup Python object for each of GDB's
reggroup objects.

I could have added a field into the reggroup object to hold the Python
object pointer for each reggroup, however, as reggroups are never
deleted within GDB, and are global (not per-architecture) a simpler
solution seemed to be just to hold a single global map from reggroup
pointer to a Python object representing the reggroup.  Then we can
reuse the objects out of this map.

After this commit it is possible for a user to tell that two
gdb.RegisterGroup objects are now identical when previously they were
unique, however, as both these objects are read-only I don't think
this should be a problem.

There should be no other user visible changes after this commit.

gdb/ChangeLog:

	* python/py-registers.c : Add 'unordered_map' include.
	(gdbpy_new_reggroup): Renamed to...
	(gdbpy_get_reggroup): ...this.  Update to only create register
	group descriptors when needed.
	(gdbpy_reggroup_iter_next): Update.

gdb/testsuite/ChangeLog:

	* gdb.python/py-arch-reg-groups.exp: Additional tests.
2020-07-21 21:57:08 +01:00
Andrew Burgess
f7306dac19 gdb/python: Reuse gdb.RegisterDescriptor objects where possible
Instead of having the gdb.RegisterDescriptorIterator creating new
gdb.RegisterDescriptor objects for each regnum, instead cache
gdb.RegisterDescriptor objects on the gdbarch object and reuse these.

This means that for every gdbarch/regnum pair there is a single unique
gdb.RegisterDescriptor, this feels like a neater implementation than
the existing one.

It is possible for a user to see (in Python code) that the descriptors
are now identical, but as the descriptors are read-only this should
make no real difference.

There should be no other user visible changes.

gdb/ChangeLog:

	* python/py-registers.c (gdbpy_register_object_data): New static
	global.
	(gdbpy_register_object_data_init): New function.
	(gdbpy_new_register_descriptor): Renamed to...
	(gdbpy_get_register_descriptor): ...this, and update to reuse
	existing register descriptors where possible.
	(gdbpy_register_descriptor_iter_next): Update.
	(gdbpy_initialize_registers): Register new gdbarch data.

gdb/testsuite/ChangeLog:

	* gdb.python/py-arch-reg-names.exp: Additional tests.
2020-07-21 21:57:08 +01:00
Andrew Burgess
9fc501fdfe gdb: Python unwinders, inline frames, and tail-call frames
This started with me running into the bug described in python/22748,
in summary, if the frame sniffing code accessed any registers within
an inline frame then GDB would crash with this error:

  gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.

The problem is that, when in the Python unwinder I write this:

  pending_frame.read_register ("register-name")

This is translated internally into a call to `value_of_register',
which in turn becomes a call to `value_of_register_lazy'.

Usually this isn't a problem, `value_of_register_lazy' requires the
next frame (more inner) to have a valid frame_id, which will be the
case (if we're sniffing frame #1, then frame #0 will have had its
frame-id figured out).

Unfortunately if frame #0 is inline within frame #1, then the frame-id
for frame #0 can't be computed until we have the frame-id for #1.  As
a result we can't create a lazy register for frame #1 when frame #0 is
inline.

Initially I proposed a solution inline with that proposed in bugzilla,
changing value_of_register to avoid creating a lazy register value.
However, when this was discussed on the mailing list I got this reply:

  https://sourceware.org/pipermail/gdb-patches/2020-June/169633.html

Which led me to look at these two patches:

  [1] https://sourceware.org/pipermail/gdb-patches/2020-April/167612.html
  [2] https://sourceware.org/pipermail/gdb-patches/2020-April/167930.html

When I considered patches [1] and [2] I saw that all of the issues
being addressed here were related, and that there was a single
solution that could address all of these issues.

First I wrote the new test gdb.opt/inline-frame-tailcall.exp, which
shows that [1] and [2] regress the inline tail-call unwinder, the
reason for this is that these two patches replace a call to
gdbarch_unwind_pc with a call to get_frame_register, however, this is
not correct.  The previous call to gdbarch_unwind_pc takes THIS_FRAME
and returns the $pc value in the previous frame.  In contrast
get_frame_register takes THIS_FRAME and returns the value of the $pc
in THIS_FRAME; these calls are not equivalent.

The reason these patches appear (or do) fix the regressions listed in
[1] is that the tail call sniffer depends on identifying the address
of a caller and a callee, GDB then looks for a tail-call sequence that
takes us from the caller address to the callee, if such a series is
found then tail-call frames are added.

The bug that was being hit, and which was address in patch [1] is that
in order to find the address of the caller, GDB ended up creating a
lazy register value for an inline frame with to frame-id.  The
solution in patch [1] is to instead take the address of the callee and
treat this as the address of the caller.  Getting the address of the
callee works, but we then end up looking for a tail-call series from
the callee to the callee, which obviously doesn't return any sane
results, so we don't insert any tail call frames.

The original patch [1] did cause some breakage, so patch [2] undid
patch [1] in all cases except those where we had an inline frame with
no frame-id.  It just so happens that there were no tests that fitted
this description _and_ which required tail-call frames to be
successfully spotted, as a result patch [2] appeared to work.

The new test inline-frame-tailcall.exp, exposes the flaw in patch [2].

This commit undoes patch [1] and [2], and replaces them with a new
solution, which is also different to the solution proposed in the
python/22748 bug report.

In this solution I propose that we introduce some special case logic
to value_of_register_lazy.  To understand what this logic is we must
first look at how inline frames unwind registers, this is very simple,
they do this:

  static struct value *
  inline_frame_prev_register (struct frame_info *this_frame,
                              void **this_cache, int regnum)
  {
    return get_frame_register_value (this_frame, regnum);
  }

And remember:

  struct value *
  get_frame_register_value (struct frame_info *frame, int regnum)
  {
    return frame_unwind_register_value (frame->next, regnum);
  }

So in all cases, unwinding a register in an inline frame just asks the
next frame to unwind the register, this makes sense, as an inline
frame doesn't really exist, when we unwind a register in an inline
frame, we're really just asking the next frame for the value of the
register in the previous, non-inline frame.

So, if we assume that we only get into the missing frame-id situation
when we try to unwind a register from an inline frame during the frame
sniffing process, then we can change value_of_register_lazy to not
create lazy register values for an inline frame.

Imagine this stack setup, where #1 is inline within #2.

  #3 -> #2 -> #1 -> #0
        \______/
         inline

Now when trying to figure out the frame-id for #1, we need to compute
the frame-id for #2.  If the frame sniffer for #2 causes a lazy
register read in #2, either due to a Python Unwinder, or for the
tail-call sniffer, then we call value_of_register_lazy passing in
frame #2.

In value_of_register_lazy, we grab the next frame, which is #1, and we
used to then ask for the frame-id of #1, which was not computed, and
this was our bug.

Now, I propose we spot that #1 is an inline frame, and so lookup the
next frame of #1, which is #0.  As #0 is not inline it will have a
valid frame-id, and so we create a lazy register value using #0 as the
next-frame-id.  This will give us the exact same result we had
previously (thanks to the code we inspected above).

Encoding into value_of_register_lazy the knowledge that reading an
inline frame register will always just forward to the next frame
feels.... not ideal, but this seems like the cleanest solution to this
recursive frame-id computation/sniffing issue that appears to crop
up.

The following two commits are fully reverted with this commit, these
correspond to patches [1] and [2] respectively:

  commit 5939967b35
  Date:   Tue Apr 14 17:26:22 2020 -0300

      Fix inline frame unwinding breakage

  commit 991a3e2e99
  Date:   Sat Apr 25 00:32:44 2020 -0300

      Fix remaining inline/tailcall unwinding breakage for x86_64

gdb/ChangeLog:

	PR python/22748
	* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Remove
	special handling for inline frames.
	* findvar.c (value_of_register_lazy): Skip inline frames when
	creating lazy register values.
	* frame.c (frame_id_computed_p): Delete definition.
	* frame.h (frame_id_computed_p): Delete declaration.

gdb/testsuite/ChangeLog:

	PR python/22748
	* gdb.opt/inline-frame-tailcall.c: New file.
	* gdb.opt/inline-frame-tailcall.exp: New file.
	* gdb.python/py-unwind-inline.c: New file.
	* gdb.python/py-unwind-inline.exp: New file.
	* gdb.python/py-unwind-inline.py: New file.
2020-07-06 15:06:07 +01:00
Andrew Burgess
64cb3757a9 gdb/python: New method to access list of register groups
Add a new method gdb.Architecture.register_groups which returns a new
object of type gdb.RegisterGroupsIterator.  This new iterator then
returns objects of type gdb.RegisterGroup.

Each gdb.RegisterGroup object just wraps a single reggroup pointer,
and (currently) has just one read-only property 'name' that is a
string, the name of the register group.

As with the previous commit (adding gdb.RegisterDescriptor) I made
gdb.RegisterGroup an object rather than just a string in case we want
to add additional properties in the future.

gdb/ChangeLog:

	* NEWS: Mention additions to Python API.
	* python/py-arch.c (archpy_register_groups): New function.
	(arch_object_methods): Add 'register_groups' method.
	* python/py-registers.c (reggroup_iterator_object): New struct.
	(reggroup_object): New struct.
	(gdbpy_new_reggroup): New function.
	(gdbpy_reggroup_to_string): New function.
	(gdbpy_reggroup_name): New function.
	(gdbpy_reggroup_iter): New function.
	(gdbpy_reggroup_iter_next): New function.
	(gdbpy_new_reggroup_iterator): New function
	(gdbpy_initialize_registers): Register new types.
	(reggroup_iterator_object_type): Define new Python type.
	(gdbpy_reggroup_getset): New static global.
	(reggroup_object_type): Define new Python type.
	* python/python-internal.h

gdb/testsuite/ChangeLog:

	* gdb.python/py-arch-reg-groups.exp: New file.

gdb/doc/ChangeLog:

	* gdb.texi (Registers): Add @anchor for 'info registers
	<reggroup>' command.
	* python.texi (Architectures In Python): Document new
	register_groups method.
	(Registers In Python): Document two new object types related to
	register groups.
2020-07-06 15:06:06 +01:00
Andrew Burgess
0f767f942b gdb/python: Add gdb.Architecture.registers method
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator.  This
iterator returns objects of the new type gdb.RegisterDescriptor.

A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.

I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information.  By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.

Right now the only property of a register that a user can access is
the name of the register.

In future we might want to be able to ask the register about is
register groups, or its type.

gdb/ChangeLog:

	* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
	* python/py-arch.c (archpy_registers): New function.
	(arch_object_methods): Add 'registers' method.
	* python/py-registers.c: New file.
	* python/python-internal.h
	(gdbpy_new_register_descriptor_iterator): Declare.
	(gdbpy_initialize_registers): Declare.
	* python/python.c (do_start_initialization): Call
	gdbpy_initialize_registers.
	* NEWS: Mention additions to the Python API.

gdb/testsuite/ChangeLog:

	* gdb.python/py-arch-reg-names.exp: New file.

gdb/doc/ChangeLog:

	* python.texi (Python API): Add new section the menu.
	(Frames In Python): Add new @anchor.
	(Architectures In Python): Document new registers method.
	(Registers In Python): New section.
2020-07-06 15:06:06 +01:00
Andrew Burgess
87dbc77459 gdb/python: Add architecture method to gdb.PendingFrame
It could be useful to determine the architecture of a frame being
unwound during the frame unwind process, that is, before we have a
gdb.Frame, but when we only have a gdb.PendingFrame.

The PendingFrame already has a pointer to the gdbarch internally, this
commit just exposes an 'architecture' method to Python, and has this
return a gdb.Architecture object (list gdb.Frame.architecture does).

gdb/ChangeLog:

	* NEWS: Mention new Python API method.
	* python/py-unwind.c (pending_framepy_architecture): New function.
	(pending_frame_object_methods): Add architecture method.

gdb/testsuite/ChangeLog:

	* gdb.python/py-unwind.py (TestUnwinder::__call__): Add test for
	gdb.PendingFrame.architecture method.

gdb/doc/ChangeLog:

	* python.texi (Unwinding Frames in Python): Document
	PendingFrame.architecture method.
2020-07-06 15:06:05 +01:00
Philippe Waroquiers
2a17c803f6 Fix test breakages caused by removal of gdb_py_test_multiple.
Tom de Vries detected that some python tests were broken as
they were still using gdb_py_test_multiple that was replaced
by gdb_test_multiline.  Repair these tests by using the new function.

gdb/testsuite/ChangeLog
2020-06-30  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* gdb.python/py-breakpoint.exp: use gdb_test_multiline instead
	of gdb_py_test_multiple.
	* gdb.python/py-cmd.exp: Likewise.
	* gdb.python/py-events.exp: Likewise.
	* gdb.python/py-function.exp: Likewise.
	* gdb.python/py-inferior.exp: Likewise.
	* gdb.python/py-infthread.exp: Likewise.
	* gdb.python/py-linetable.exp: Likewise.
	* gdb.python/py-parameter.exp: Likewise.
	* gdb.python/py-value.exp: Likewise.
2020-06-30 18:40:21 +02:00
Philippe Waroquiers
c0b3b3bdc6 Make test names unique in python.exp and guile.exp
Version 2, handles the comments of Simon and Pedro.

Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.

2020-06-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
	have a input seq nr in each pass message.
        * lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
	* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
	* gdb.python/python.exp: Make test names unique,
	use gdb_test_multiline instead of gdb_py_test_multiple,
	use $gdb_test_name.
	* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-26 22:04:46 +02:00
Gary Benson
7e4b9c4cd3 Improve -Wunused-value testcase build failures fix
This commit improves upon my previous -Wunused-value fix by
replacing the various dummy variables with casts to void, as
suggested by Pedro.

gdb/testsuite/ChangeLog:

	* gdb.cp/namespace.cc: Improve -Wunused-value fix.
	* gdb.cp/nsimport.cc: Likewise.
	* gdb.cp/nsnested.cc: Likewise.
	* gdb.cp/nsnoimports.cc: Likewise.
	* gdb.cp/nsusing.cc: Likewise.
	* gdb.cp/smartp.cc: Likewise.
	* gdb.python/py-pp-integral.c: Likewise.
	* gdb.python/py-pp-re-notag.c: Likewise.
2020-06-23 15:11:27 +01:00
Gary Benson
2e573c0a3f Avoid testcase build failures with -Wunused-value
A number of testcases fail to build with -Wunused-value enabled.
This commit adds dummy values to avoid this.

gdb/testsuite/ChangeLog:

	* gdb.cp/namespace.cc: Avoid build failure with -Wunused-value.
	* gdb.cp/nsimport.cc: Likewise.
	* gdb.cp/nsnested.cc: Likewise.
	* gdb.cp/nsnoimports.cc: Likewise.
	* gdb.cp/nsusing.cc: Likewise.
	* gdb.cp/smartp.cc: Likewise.
	* gdb.python/py-pp-integral.c: Likewise.
	* gdb.python/py-pp-re-notag.c: Likewise.
2020-06-23 12:25:34 +01:00
Philippe Waroquiers
746ebfe8dd Add tests for new alias default-args related commands and arguments.
Test the new default-args behaviour and completion for the alias command.
Note that gdb.base/default-args.exp is somewhat copied from
with.exp (the test of the with command), while default-exp.c
is a plain copy of with.c.

gdb/testsuite/ChangeLog
2020-06-22  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* gdb.base/default-args.exp: New test.
	* gdb.base/default-args.c: New file.
	* gdb.base/alias.exp: Update expected error msg for alias foo=bar.
	* gdb.base/default.exp: Update to new help text.
	* gdb.base/help.exp: Likewise.
	* gdb.base/page.exp: Likewise.
	* gdb.base/style.exp: Likewise.
	* gdb.guile/guile.exp: Likewise.
	* gdb.python/python.exp: Likewise.
2020-06-22 21:15:14 +02:00
Sandra Loosemore
05e682e3be Fix TCL error in gdb.python/py-format-string.exp.
2020-06-17 Sandra Loosemore <sandra@codesourcery.com>

	gdb/testsuite/
	* gdb.python/py-format-string.exp: Move test for python support
	earlier, out of function body.
2020-06-17 13:43:32 -07:00
Tom Tromey
d2d1ea20ae Fix crash when TUI window creation fails
If a TUI window is written in Python, and if the window construction
function fails, then gdb will crash.  This patch fixes the crash.

gdb/ChangeLog
2020-06-16  Tom Tromey  <tom@tromey.com>

	* python/py-tui.c (tui_py_window::~tui_py_window): Handle case
	where m_window==nullptr.

gdb/testsuite/ChangeLog
2020-06-16  Tom Tromey  <tom@tromey.com>

	* gdb.python/tui-window.py (failwin): New function.  Register it
	as a TUI window type.
	* gdb.python/tui-window.exp: Create new "fail" layout.  Test it.
2020-06-16 17:48:38 -06:00
Gary Benson
c802e8a76c Add two missing return values in gdb.python/py-nested-maps.c
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-16 12:41:28 +01:00
Tom de Vries
8c74a764f2 [gdb/testsuite] Don't leak tuiterm.exp spawn override
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-06-12 13:29:43 +02:00
Gary Benson
86e4e63d7c Fix "control reaches end of non-void function" errors in testsuite
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-05-15 15:03:42 +01:00
Hannes Domani
d5cf82c0d7 Adjust array pretty printer tests to the new format
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-30 17:02:14 +02:00
Tom de Vries
6e4e3fe1b6 [gdb/testsuite] Add xfails for PR gcc/90232
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 15cd93d05e "[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-29 13:22:21 +02:00
Tom Tromey
bcfe6157ca Use the linkage name if it exists
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-04-24 15:35:03 -06:00
Tom Tromey
01b1af321f Allow TUI windows in Python
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-22 12:57:25 -07:00
Tom de Vries
c9c41e6d73 [gdb/testsuite] Fix xpass in gdb.python/lib-types.exp
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-02-19 22:57:19 +01:00
Tom Tromey
ff47f4f06d Fix valgrind error from gdb.decode_line
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-14 17:57:52 -07:00
Pedro Alves
121b3efd49 Add "info connections" command, "info inferiors" connection number/string
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-10 20:06:14 +00:00