Commit Graph

45130 Commits

Author SHA1 Message Date
Alok Kumar Sharma
9cdf98207c Allow reference form for DW_AT_associated and DW_AT_allocated attributes
Currently, GDB rejects the (die) reference form while it accepts exprloc
form. It is allowed in DWARF standard. "Table 7.5: Attribute encodings"
in DWARF5 standard. Flang compiler assigns (die) reference to
DW_AT_associated and DW_AT_allocated for some cases.

gdb/ChangeLog

	* dwarf2/read.c (set_die_type): Removed conditions to restrict
	forms for DW_AT_associated and DW_AT_allocated attributes,
	which is already checked in function attr_to_dynamic_prop.
2020-07-01 16:57:17 +05:30
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
Tom Tromey
a1520ad8fc Fix bug in quirk_rust_enum
Tom de Vries pointed out that some Rust tests were failing after the
variant part rewrite.  He sent an executable, which helped track down
this bug.

quirk_rust_enum was passing 1 to alloc_rust_variant in one case.
However, a comment earlier says:

      /* We don't need a range entry for the discriminant, but we do
	 need one for every other field, as there is no default
	 variant.  */

In this case, we must pass -1 for this parameter.  That is what this
patch implements.

gdb/ChangeLog
2020-06-30  Tom Tromey  <tromey@adacore.com>

	* dwarf2/read.c (quirk_rust_enum): Correctly call
	alloc_rust_variant for default-less enum.
2020-06-30 07:57:35 -06:00
Tom Tromey
5ac588997c Do not define basic_string_view::to_string
gdb's copy of basic_string_view includes a to_string method.  However,
according to cppreference, this is not a method on the real
std::basic_string_view:

https://en.cppreference.com/w/cpp/string/basic_string_view

This difference matters because gdb_string_view.h will use the
standard implementation when built with a C++17 or later.  This caused
PR build/26183.

This patch fixes the problem by changing the method to be a standalone
helper function, and then rewriting the uses.  Tested by rebuilding
with a version of GCC that defaults to C++17.

(Note that the build still is not clean; and also I noticed that the
libstdc++ string_view forbids the use of nullptr ... I wonder if gdb
violates that.)

gdb/ChangeLog
2020-06-30  Tom Tromey  <tromey@adacore.com>

	PR build/26183:
	* ada-lang.c (ada_lookup_name_info::ada_lookup_name_info): Use
	gdb::to_string.

gdbsupport/ChangeLog
2020-06-30  Tom Tromey  <tromey@adacore.com>

	PR build/26183:
	* gdb_string_view.h (basic_string_view::to_string): Remove.
	(gdb::to_string): New function.
2020-06-30 07:53:03 -06:00
Tom de Vries
b011fe1a72 [gdb/testsuite] Handle early_flags in gdb_default_target_compile
In gdb_default_target_compile, we use dejagnu's default_target_compile, unless
we need support for languages that are not yet support in the used dejagnu
version, in which case we use a local default_target_compile:
gdb_default_target_compile_1.

However, there's another reason to use the local default_target_compile: when
early_flags is used, because there's no dejagnu release available yet
supporting this.

Fix this by detecting and handling early_flags in gdb_default_target_compile.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-06-30  Tom de Vries  <tdevries@suse.de>

	PR testsuite/26175
	* lib/future.exp (gdb_default_target_compile): Detect and handle
	early_flags.
2020-06-30 09:23:09 +02:00
Simon Marchi
19b187a978 gdb: fix documentation of gdbarch_displaced_step_copy_insn
I spotted something that looks wrong in the doc of
gdbarch_displaced_step_copy_insn.

It says that if the function returns NULL, it means that it has emulated
the behavior of the instruction and written the result to REGS.
However, it says below that the function may return NULL to indicate
that the instruction can't be single-stepped out-of-line, in which case
the core steps the instruction in-line.  The two are contradictory.

The right one is the latter, if the function returns NULL, the core
falls back to in-line stepping. I checked all the implementations of
this function and they all agree with this.

gdb/ChangeLog:

	* gdbarch.sh (displaced_step_copy_insn): Update doc.
	* gdbarch.h: Re-generate.

Change-Id: I98163cdd38970cde4c77680e249b10f5d2d5bf9b
2020-06-29 11:27:46 -04:00
Simon Marchi
df5b887608 gdb/testsuite: better handle failures in simavr board, reap simavr process
This patch makes a few adjustments to the simavr.exp to handle tests
that error out more gracefully.  I put all the changes in the same patch
because right now it's in a very bad shape, so it's very painful to do
small incremental adjustements.  I found that with these changes, it
becomes reasonably stable.

For example, the gdb.base/step-over-syscall.exp test is a bit buggy
(stuff for another patch...), in that it calls gdb_load (through
clean_restart) with a file that doesn't exist.  The gdb_load
implementation in simavr.exp gets called with a file that doesn't exist,
and simavr (expectedly) fails to start.

When this happens, we currently leave the $simavr_spawn_id variable set.
However, because the simavr process has terminated, its spawn id is
closed.  When the next test tries to close the previous connection to
simavr, it fails to, and this error is thrown:

    ERROR: close: spawn id exp86 not open
        while executing
    "close -i $simavr_spawn_id"
        (procedure "gdb_load" line 18)
        invoked from within

In other words, any test ran after step-over-syscall.exp will have
simavr.exp's gdb_load fail on it.

This patch tries to make sure that simavr.exp's gdb_load only leaves
simavr_spawn_id set if everything went fine.  If we couldn't start
simavr, don't see the expected output, or fail to connect to it, we
close the spawn id (if needed) and unset simavr_spawn_id.

As an additional precaution, I added a catch around the "close the
previous connection" code.  Ideally, this shouldn't be necessary, but I
bet there are other similar scenarios where we might try to close an
already close spawn id.  So I think displaying a warning is better than
messing up all following tests.

Also, the board never wait'ed for the simavr process, resulting in tons
of zombie simavr processes hanging around.  This patch adds some calls
to "wait" whenever we close the connection (or realize it is already
closed), which seems to fix the problem.

Finally I switched a `gdb_expect` to bare `expect`, where we wait for
the "listening" message from simavr.  I found it necessary because
gdb_expect (through remote_expect) adds a `-i <gdb spawn id> -timeout
10`.  So if for some reason the GDB process has crashed in the mean
time, this expect will unexpectedly error out with a `spawn id <gdb
spawn id> not open`.  Therefore, change `gdb_expect` to `expect` so that
we only deal with simavr's spawn id here.

Here are the results on TESTS="gdb.base/*.exp" before:

    # of expected passes		4816
    # of unexpected failures	4433
    # of known failures		2
    # of unresolved testcases	300
    # of untested testcases		143
    # of unsupported tests		7
    # of paths in test names	2
    # of duplicate test names	10

and after:

    # of expected passes		21957
    # of unexpected failures	1564
    # of expected failures		8
    # of unknown successes		1
    # of known failures		31
    # of unresolved testcases	532
    # of untested testcases		153
    # of unsupported tests		28
    # of paths in test names	2
    # of duplicate test names	32

I tested using simavr's current master (7c254e2081b5).

gdb/testsuite/ChangeLog:

	* boards/simavr.exp (gdb_load): Catch errors when closing
	previous connection.  Close connection, wait for process and
	unset simavr_spawn_id on failure.

Change-Id: I695fc765e1c22e1d1dc0b08e0f5141244986b868
2020-06-29 10:19:43 -04:00
Tom de Vries
a3ca48cdda [gdb/testsuite] Emit unresolved for unknown proc
Since commit 26783bce15 "[gdb/testsuite] Don't abort testrun for invalid
command in test-case" we don't abort the testrun when encountering an invalid
command.  However, since we don't report errors in the summary, there's a
chance that the error goes unnoticed.

Make the invalid command error more visible by marking the test-case
unresolved, such that we have f.i.:
...
PASS: gdb.python/py-breakpoint.exp: test_bkpt_internal: Test watchpoint write
UNRESOLVED: gdb.python/py-breakpoint.exp: test_bkpt_eval_funcs: \
  testcase aborted due to invalid command name: gdb_py_test_multiple
ERROR: tcl error sourcing py-breakpoint.exp.
ERROR: invalid command name "gdb_py_test_multiple"
    while executing
  ...
                === gdb Summary ===

nr of expected passes            56
nr of unresolved testcases       1
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-06-29  Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (unknown): Make test-case unresolved.
2020-06-29 13:59:19 +02:00
Tom de Vries
b0237c0eab [gdb/testsuite] Expect conformation question in gdb.server/solib-list.exp
Before commit a8654e7d78 'Fixes PR 25475: ensure exec-file-mismatch "ask"
always asks in case of mismatch', there was a difference in behaviour in
test-case gdb.server/solib-list.exp.

If the executable did not contain debug info (as is usually the case), gdb
would detect a mismatch but not ask for confirmation:
...
(gdb) target remote localhost:2346^M
Remote debugging using localhost:2346^M
warning: Mismatch between current exec-file solib-list^M
and automatically determined exec-file /lib64/ld-2.26.so^M
exec-file-mismatch handling is currently "ask"^M
Reading symbols from /lib64/ld-2.26.so...^M
Reading symbols from /usr/lib/debug/lib64/ld-2.26.so.debug...^M
0x00007ffff7dd7ea0 in _start () at rtld.c:745^M
745     }^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: target remote
...

If the executable did contain debug info (as happens to be the case for
openSUSE), gdb would detect a mismatch and ask for confirmation:
...
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile
target remote localhost:2346^M
Remote debugging using localhost:2346^M
warning: Mismatch between current exec-file solib-list^M
and automatically determined exec-file /lib64/ld-2.26.so^M
exec-file-mismatch handling is currently "ask"^M
Load new symbol table from "/lib64/ld-2.26.so"? (y or n) y^M
Reading symbols from /lib64/ld-2.26.so...^M
Reading symbols from /usr/lib/debug/lib64/ld-2.26.so.debug...^M
0x00007ffff7dd7ea0 in _start () at rtld.c:745^M
745     }^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: target remote
...

After commit a8654e7d78, the confirmation is now also asked in case there's
no debug info.

Tighten the test-case by verifying that the confirmation question is asked, as
suggested in the log message of commit a8654e7d78:
...
we can remove the bypass introduced by Tom in 6b9374f1, in order to always
answer to the 'load' question.
...

gdb/testsuite/ChangeLog:

2020-06-29  Tom de Vries  <tdevries@suse.de>

	PR gdb/25475
	* gdb.server/solib-list.exp: Verify that the symbol reload
	confirmation question is asked.
2020-06-29 11:02:06 +02:00
Tom Tromey
cd4c4c07f4 Remove "cmd_type" function
The cmd_type function only has a single caller, which is in the CLI
implementation code.  This patch removes the function, and moves the
cmd_types enum definition from command.h to cli-decode.h, fixing an 18
year old FIXME.

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

	* command.h (cmd_types): Remove.
	(cmd_type): Don't declare.
	* cli/cli-decode.h (enum cmd_types): Uncomment.  No longer a
	typedef.
	* cli/cli-cmds.c (setting_cmd): Use cmd->type directly.
	* cli/cli-decode.c (cmd_type): Remove.
2020-06-28 10:33:07 -06:00
Pedro Alves
05779d57f9 Make {get,set}_inferior_io_terminal inferior methods
This converts the get_inferior_io_terminal and
set_inferior_io_terminal free functions to inferior methods.

Since the related commands are called "tty", "{set,show}
inferior-tty", and MI's "-inferior-tty-{set,show}", to make the
connection between the commands and the code more obvious, the methods
are named set_tty/tty instead of set_io_terminal/io_terminal.

gdb/ChangeLog:

	* fork-child.c (prefork_hook): Adjust.
	* infcmd.c (set_inferior_io_terminal, get_inferior_io_terminal):
	Delete.
	(set_inferior_tty_command, show_inferior_tty_command): Adjust.
	* inferior.c (inferior::set_tty, inferior::tty): New methods.
	* inferior.h (set_inferior_io_terminal, get_inferior_io_terminal):
	Remove declarations.
	(struct inferior) <set_tty, tty>: New methods.
	(struct inferior) <terminal>: Rename to ...
	(struct inferior) <m_terminal>: ... this and make private.
	* main.c (captured_main_1): Adjust.
	* mi/mi-cmd-env.c (mi_cmd_inferior_tty_set): Adjust.
	(mi_cmd_inferior_tty_show): Adjust.
	* nto-procfs.c (nto_procfs_target::create_inferior): Adjust.
	* windows-nat.c (windows_nat_target::create_inferior): Adjust.
2020-06-27 14:56:05 +01: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
Nick Alcock
1776e3e59c Fix --enable-libctf and --disable-static
This fixes test runs and compilation when --disable-libctf,
--disable-static, or --enable-shared are passed.

Changes since v2: Use GCC_ENABLE and fix indentation.  Fix prototype
using 'void'.  Use 'unsupported' and gdb_caching_proc.

Changes since v3: Adapt to upstream changes providing skip_ctf_tests.

Changes since v4: Adapt to upstream changes in the seven months (!)
since I last looked at this.

gdb/ChangeLog
	* configure.ac: Add --enable-libctf: handle --disable-static
	properly.
	* acinclude.m4: sinclude ../config/enable.m4.
	* Makefile.in (aclocal_m4_deps): Adjust accordingly.
	(LIBCTF): Substitute in.
	(CTF_DEPS): New, likewise.
	(CLIBS): libctf needs symbols from libbfd: move earlier.
	(CDEPS): Use CTF_DEPS, not LIBCTF, now LIBCTF can include rpath
	flags.
	* ctfread.c: Surround in ENABLE_LIBCTF.
	(elfctf_build_psymtabs) [!ENABLE_LIBCTF]: New stub.
	* configure: Regenerate.
	* config.in: Likewise.

gdb/testsuite/ChangeLog
	* configure.ac: Add --enable-libctf.
	* aclocal.m4: sinclude ../config/enable.m4.
	* Makefile.in (site.exp): Add enable_libctf to site.exp.
	* lib/gdb.exp (skip_ctf_tests): Use it.
	* gdb.base/ctf-constvars.exp: Error message tweak.
	* gdb.base/ctf-ptype.exp: Likewise.
	* configure: Regenerate.
2020-06-26 15:56:38 +01:00
Gary Benson
f53b3eeb67 Fix -Wstring-compare testcase build failure
Clang fails to compile the file gdb/testsuite/gdb.cp/try_catch.cc
with the following error:
  warning: result of comparison against a string literal is
  unspecified (use strncmp instead) [-Wstring-compare]

This commit fixes the error, replacing the pointer comparison with
a call to strcmp.  This commit also adds a final check: the test
program is run to the final return statement, and the value of
"test" is checked to ensure it is still "true" at that point.

gdb/testsuite/ChangeLog:

	* gdb.cp/try_catch.cc: Include string.h.
	(main): Replace comparison against string literal with
	strcmp, avoiding build failure with -Wstring-compare.
	Add "marker test-complete".
	* gdb.cp/try_catch.exp: Run the test to the above marker,
	then verify that the value of "test" is still true.
2020-06-26 14:53:28 +01:00
Eli Zaretskii
edf92af0fb Improve documentation of which shell is used by GDB's shell commands
gdb/doc/ChangeLog:

2020-06-26  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Shell Commands): More accurate description of use
	of $SHELL.  Reported by Sandra Loosemore <sandra@codesourcery.com>.
2020-06-26 09:51:45 +03:00
Simon Marchi
58373b80f3 gdb: use make_unique_xstrdup in set_inferior_io_terminal
gdb/ChangeLog:

	* infcmd.c (set_inferior_io_terminal): Use make_unique_xstrdup.

Change-Id: I38b6e753f58947531fe4a293d574bc27ec128f47
2020-06-25 17:06:18 -04:00
Simon Marchi
277474eea0 gdb: make inferior::terminal a unique ptr
This changes the inferior::terminal field to be a unique pointer, so its
deallocation is automatically managed.

gdb/ChangeLog:

	* inferior.h (struct inferior) <terminal>: Change type to
	gdb::unique_xmalloc_ptr<char>.
	* inferior.c (inferior::~inferior): Don't free inf->terminal.
	* infcmd.c (set_inferior_io_terminal): Don't free terminal
	field, adjust to unique pointer.
	(get_inferior_io_terminal): Adjust to unique pointer.

Change-Id: Iedb6459b4f9eeae812b0cb9d514b5707d5107cdb
2020-06-25 14:44:35 -04:00
Andrew Burgess
6d74da72da gdb/riscv: Loop over all registers for 'info all-registers'
Currently the 'info all-registers' command only loops over those
registers that are known to GDB.  Any registers that are unknown, that
is, are mentioned in the target description, but are not something GDB
otherwise knows, will not be displayed.

This feels wrong, so this commit fixes this mistake.  The output of
'info all-registers' now matches 'info registers all'.

gdb/ChangeLog:

	* riscv-tdep.c (riscv_print_registers_info): Loop over all
	registers, not just the known core set of registers.

gdb/testsuite/ChangeLog:

	* gdb.arch/riscv-tdesc-regs.exp: New test cases.
2020-06-25 18:07:33 +01:00
Andrew Burgess
2e52d03824 gdb/riscv: Record information about unknown tdesc registers
Making use of the previous commit, record information about unknown
registers in the target description, and use this to resolve two
issues.

1. Some targets (QEMU) are reporting three register fflags, frm, and
   fcsr, twice, once in the FPU feature, and once in the CSR feature.
   GDB does create two registers with identical names, but this
   is (sort of) fine, we only ever use the first one, and as both
   registers access the same target state things basically work OK.
   The only real problem is that the register names show up twice in
   'info registers all' output.

   In this commit we spot the duplicates of these registers and then
   return NULL when asked for the name of these registers.  This
   causes GDB to hide these registers from the user, fixing this
   problem.

2. Some targets (QEMU) advertise CSRs that GDB then can't read.  The
   problem is these targets also say these CSRs are part of the
   save/restore register groups.

   This means that before an inferior call GDB tries to save all of
   these CSRs, and a failure to read one causes the inferior call to
   be abandoned.

   We already work around this issue to some degree, known CSRs are
   removed from the save/restore groups, despite what the target might
   say.  However, any unknown CSRs are (currently) not removed in this
   way.

   After this commit we keep a log of the register numbers for all
   unknown CSRs, then when asked about the register groups, we
   override the group information for unknown CSRs, removing them from
   the save and restore groups.

gdb/ChangeLog:

	* riscv-tdep.c (riscv_register_name): Return NULL for duplicate
	fflags, frm, and fcsr registers.
	(riscv_register_reggroup_p): Remove unknown CSRs from save and
	restore groups.
	(riscv_tdesc_unknown_reg): New function.
	(riscv_gdbarch_init): Pass riscv_tdesc_unknown_reg to
	tdesc_use_registers.
	* riscv-tdep.h (struct gdbarch_tdep): Add
	unknown_csrs_first_regnum, unknown_csrs_count,
	duplicate_fflags_regnum, duplicate_frm_regnum, and
	duplicate_fcsr_regnum fields.

gdb/testsuite/ChangeLog:

	* gdb.arch/riscv-tdesc-regs.exp: Extend test case.
2020-06-25 18:07:32 +01:00
Andrew Burgess
be64fd0776 gdb: Extend target description processing of unknown registers
This commit adds a new step to the processing of a target description
done in tdesc_use_registers, this new step is about how unknown
registers are processed.

Currently an architecture looks through the target description and
calls tdesc_numbered_register for each register is was expecting (or
hoping) to find.  This builds up a map from GDB's register numbers to
the tdesc_reg object.  Later the architecture calls
tdesc_use_registers.

In tdesc_use_registers we build a hash with keys being all the
tdesc_reg object pointers, from this hash we remove all of the
tdesc_reg objects that were assigned register numbers using
tdesc_numbered_register.

Finally we walk through all of the tdesc_reg objects, and if it was
not already assigned a number we assign that register the next
available number.

The problem with this is that the architecture has no visibility of
which unknown registers exist, and which tdesc_feature the register
came from, in some cases this might be important.

For example, on RISC-V GDB overrides the use of
tdesc_register_reggroup_p, with riscv_register_reggroup_p to modify
some of the register group choices.  In this function GDB wants to
treat all registers from a particular feature in a certain way.  This
is fine for registers that GDB knows might be in that feature, but for
unknown registers the RISC-V parts of GDB have no easy way to figure
out which unknown registers exist, and what numbers they were
assigned.

We could figure this information out by probing the register
structures after calling tdesc_use_registers, but this would be
horrible, much better to have tdesc_use_registers tell the
architecture about unknown registers.

This is what this commit does.  A new phase of tdesc_use_registers,
just before the unknown registers are assigned a number, we loop over
each tdesc_reg object, if it has not been assigned a number then we
figure out what number would be assigned and then call back into the
architecture passing the tdesc_feature, register name, and the
proposed register number.

The architecture is free to return the proposed register number, or it
can return a different number (which has a result identical to having
called tdesc_numbered_register).  Alternatively the architecture can
return -1 to indicate the register should be numbered later.

After calling the callback for every tdesc_reg object any registers
still don't have a number assigned (because the architecture returned
-1), then a new register number is assigned, which might be different
from the proposed number that was suggested earlier.

This commit adds the general target-description parts of this
mechanism.  No targets are currently using this code.  The RISC-V
target will make use of this in the next commit.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* target-descriptions.c (tdesc_use_registers): Add new parameter a
	callback, use the callback (when not null) to help number unknown
	registers.
	* target-descriptions.h (tdesc_unknown_register_ftype): New typedef.
	(tdesc_use_registers): Add extra parameter to declaration.
2020-06-25 18:07:31 +01:00
Andrew Burgess
3b9fce9660 gdb/riscv: Improve support for matching against target descriptions
For the RISC-V target it is desirable if the three floating pointer
status CSRs fflags, frm, and fcsr can be placed into either the FPU
feature or the CSR feature.  This allows different targets to build
the features in a way that better reflects their target.

The change to support this within GDB is fairly simple, so this is
done in this commit, and some tests added to check this new
functionality.

gdb/ChangeLog:

	* riscv-tdep.c (value_of_riscv_user_reg): Moved to here from later
	in the file.
	(class riscv_pending_register_alias): Likewise.
	(riscv_register_feature::register_info): Change 'required_p' field
	to 'required', and change its type.  Add 'check' member function.
	(riscv_register_feature::register_info::check): Define new member
	function.
	(riscv_xreg_feature): Change initialisation of 'required' field.
	(riscv_freg_feature): Likewise.
	(riscv_virtual_feature): Likewise.
	(riscv_csr_feature): Likewise.
	(riscv_check_tdesc_feature): Take extra parameter, the csr
	tdesc_feature, rewrite the function to use the new
	riscv_register_feature::register_info::check function.
	(riscv_gdbarch_init): Pass the csr tdesc_feature where needed.

gdb/testsuite/ChangeLog:

	* gdb.arch/riscv-tdesc-loading-01.xml: New file.
	* gdb.arch/riscv-tdesc-loading-02.xml: New file.
	* gdb.arch/riscv-tdesc-loading-03.xml: New file.
	* gdb.arch/riscv-tdesc-loading-04.xml: New file.
	* gdb.arch/riscv-tdesc-loading.exp: New file.
2020-06-25 18:07:31 +01:00
Andrew Burgess
865bad2602 gdb/riscv: Remove CSR feature file
There is currently a bug in the RISC-V CSR/FPU feature files.  The
CSRs containing the FPU status registers are mentioned in both the FPU
feature file and the CSR feature file.

My original thinking when adding the FPU feature file was that it made
more sense to group the FPU status registers with the other FPU
state.  This opened up the possibility of debugging very
simple (possibly simulator only) targets that had little more than CPU
and FPU available for GDB to access.

When I then added code to automatically generate the CSR XML file I
forgot to filter out the FPU status CSRs, so these registers were
mentioned twice.

Now for GDB's default RISC-V target descriptions this doesn't actually
matter.  I did consider adding the CSRs to the default target
description, but in the end I didn't bother.  The reasoning again was
simplicity; the default target description is only to be used when the
target doesn't supply its own description, and NOT supplying the CSRs
actually serves to encourage targets to supply an accurate
description.  Combine this with the fact that the CSRs change from
revision to revision, sometimes in non-backward compatible ways, then
having a "default" set of CSRs just feels like a path to confusion and
complaints.

However, having a broken CSR XML file in the GDB source tree has had
one negative effect, QEMU has copied this file into its source tree,
and is using this as its description that it passes to GDB.  That is
QEMU announces the FPU status registers twice, once in the FPU
feature, and once in the CSR feature.

This commit starts along the path back to sanity by deleting the
default CSR XML files from within GDB.  These files were not used in
any way by current GDB, so there is absolutely no loss of
functionality with this change.

gdb/ChangeLog:

	* features/Makefile: Remove all references to the deleted files
	below.
	* features/riscv/32bit-csr.c: Deleted.
	* features/riscv/32bit-csr.xml: Deleted.
	* features/riscv/64bit-csr.c: Deleted.
	* features/riscv/64bit-csr.xml: Deleted.
	* features/riscv/rebuild-csr-xml.sh: Deleted.
2020-06-25 18:07:30 +01:00
Andrew Burgess
ed69cbc8ef gdb/riscv: Take CSR names from target description
First, consider the RISC-V register $x1.  This register has an alias
$ra.  When GDB processes an incoming target description we allow the
target to use either register name to describe the target.

However, within GDB's UI we want to use the $ra alias in preference to
the $x1 architecture name.

To achieve this GDB overrides the tdesc_register_name callback with
riscv_register_name.  In riscv_register_name we ensure that we always
return the preferred name, so in this case "ra".

To ensure the user can still access the register as $x1 if they want
to, when in riscv_check_tdesc_feature we spot that the target has
supplied the register, we add aliases for every name except the
preferred one, so in this case we add the alias "x1".

This scheme seems to work quite well, the targets have the flexibility
to be architecture focused if they wish (using x0 - x31) while GDB is
still using the ABI names ra, sp, gp, etc.

When this code was originally added there was an attempt made to
include the CSRs in the same scheme.  At the time the CSRs only had
two names, one pulled from riscv-opc.h, and one generated in GDB that
had the pattern csr%d.

The idea was that if the remote targets description described the CSRs
as csr%d then GDB would rename these back to the real CSR name.  This
code was only included because if followed the same pattern as the
x-regs and f-regs, not because I was actually aware of any target that
did this.

However, recent changes to add additional CSR aliases has made me
rethink the position here.

Lets consider the CSR $dscratch0.  This register has an alias
'csr1970' (1970 is 0x7b2, which is the offset of the CSR register into
the CSR address space).  However, this register was originally called
just 'dscratch', and so, after recent commits, this register also has
the alias 'dscratch'.

As the riscv-opc.h file calls this register 'dscratch0' GDB's
preferred name for this register is 'dscratch0'.

So, if the remote target description includes the register
'dscratch0', then GDB will add the aliases 'dscratch', and 'csr1970'.
In the UI GDB will describe the register as 'dscratch0', and all it
good.

The problem I see in this case is where the target describes the
register as 'dscratch'.  In this case GDB will still spot the register
and add the aliases 'dscratch', and 'csr1970', GDB will then give the
register the preferred name 'dscratch0'.

I don't like this.  For the CSRs I think that we should stick with the
naming scheme offered by the remote target description.  As the RISC-V
specification evolves and CSR register names evolve, insisting on
referring to registers by the most up to date name makes it harder for
a target to provide a consistent target description for an older
version of the RISC-V architecture spec.

In this precise case the target offers 'dscratch', which is from an
older version of the RISC-V specification, the newer version of the
spec has two registers 'dscratch0' and 'dscratch1'.  If we insist on
using 'dscratch0' it is then a little "weird" (or seems so to me) when
'dscratch1' is missing.

This patch makes a distinction between the x and f registers and the
other register sets.  For x and f we still make use of the renaming
scheme, forcing GDB to prefer the ABI name.  But after this patch the
CSR register group, and also the virtual register group, will always
prefer to use the name given in the target description, adding other
names as aliases, but not making any other name the preferred name.

gdb/ChangeLog:

	* riscv-tdep.c (struct riscv_register_feature::register_info): Fix
	whitespace error for declaration of names member variable.
	(struct riscv_register_feature): Add new prefer_first_name member
	variable, and fix whitespace error in declaration of registers.
	(riscv_xreg_feature): Initialize prefer_first_name field.
	(riscv_freg_feature): Likewise.
	(riscv_virtual_feature): Likewise.
	(riscv_csr_feature): Likewise.
	(riscv_register_name): Expand on comments.  Remove register name
	modifications for CSR and virtual registers.

gdb/testsuite/ChangeLog:

	* gdb.arch/riscv-tdesc-regs.exp: Extend test case.
2020-06-25 18:07:30 +01:00
Andrew Burgess
4445e8f59a gdb/riscv: Fix whitespace error
Should be 'std::vector<type>' not 'std::vector <type>'.

gdb/ChangeLog:

	* riscv-tdep.c (struct riscv_register_feature): Fix whitespace
	errors.
2020-06-25 18:07:29 +01:00
Andrew Burgess
767a879e31 gdb/riscv: Improved register alias name creation
This commit does two things:

 1. Makes use of the DECLARE_CSR_ALIAS definitions in riscv-opc.h to
 add additional aliases for CSRs.

 2. Only creates aliases for registers that are actually present on
 the target (as announced in the target XML description).

This means that the 'csr%d' aliases that exist will only be created
for those CSRs the target actually has, which is a nice improvement,
as accessing one of the CSRs that didn't exist would cause GDB to
crash with this error:

  valprint.c:1560: internal-error: bool maybe_negate_by_bytes(const gdb_byte*, unsigned int, bfd_endian, gdb::byte_vector*): Assertion `len > 0' failed.

When we look at the DECLARE_CSR_ALIAS lines in riscv-opc.h, these can
be split into three groups:

 DECLARE_CSR_ALIAS(misa, 0xf10, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P9P1)

The 'misa' register used to exist of offset 0xf10, but was moved to
its current offset (0x301) in with privilege spec 1.9.1.  We don't
want GDB to create an alias called 'misa' as we will already have a
'misa' register created by the DECLARE_CSR(misa ....) call earlier in
riscv-opc.h

 DECLARE_CSR_ALIAS(ubadaddr, CSR_UTVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
 DECLARE_CSR_ALIAS(sbadaddr, CSR_STVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
 DECLARE_CSR_ALIAS(sptbr, CSR_SATP, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
 DECLARE_CSR_ALIAS(mbadaddr, CSR_MTVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)
 DECLARE_CSR_ALIAS(mucounteren, CSR_MCOUNTINHIBIT, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10)

These aliases are all CSRs that were removed in privilege spec 1.10,
and whose addresses were reused by new CSRs.  The names meaning of the
old names is totally different to the new CSRs that have taken their
place.  I don't believe we should add these as aliases into GDB.  If
the new CSR exists in the target then that should be enough.

 DECLARE_CSR_ALIAS(dscratch, CSR_DSCRATCH0, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P11)

In privilege spec 1.11 the 'dscratch' register was renamed to
'dscratch0', however the meaning of the register didn't change.
Adding the 'dscratch' alias makes sense I think.

Looking then at the final PRIV_SPEC_CLASS_* field for each alias then
we can see that currently we only want to take the alias from
PRIV_SPEC_CLASS_1P11.  For now then this is what I'm using to filter
the aliases within GDB.

In the future there's no telling how DECLARE_CSR_ALIAS will be used.
I've heard it said that future RISC-V privilege specs will not reuse
CSR offsets again.  But it could happen.  We just don't know.

If / when it does we may need to revisit how aliases are created for
GDB, but for now this seems to be OK.

gdb/ChangeLog:

	* riscv-tdep.c (riscv_create_csr_aliases): Handle csr aliases from
	riscv-opc.h.
	(class riscv_pending_register_alias): New class.
	(riscv_check_tdesc_feature): Take vector of pending aliases and
	populate it as appropriate.
	(riscv_setup_register_aliases): Delete.
	(riscv_gdbarch_init): Create vector of pending aliases and pass it
	to riscv_check_tdesc_feature in all cases.  Use the vector to
	create the register aliases.

gdb/testsuite/ChangeLog:

	* gdb.arch/riscv-tdesc-regs-32.xml: New file.
	* gdb.arch/riscv-tdesc-regs-64.xml: New file.
	* gdb.arch/riscv-tdesc-regs.c: New file.
	* gdb.arch/riscv-tdesc-regs.exp: New file.
2020-06-25 18:07:29 +01:00
Rainer Orth
bb6e55f3ee Remove obsolete gdbarch_static_transform_name
gdbarch_static_transform_name is completely Solaris-specific or rather
specific to the Studio compilers.  Studio cc has deprecated Stabs support
in the 12.4 release back in 2015, GCC has defaulted to DWARF-2 on Solaris
7+ since 2004 and Stabs themselves are pretty much obsolete, so the whole
code can go.

Tested on sparcv9-sun-solaris2.11 and x86_64-pc-linux-gnu with
--enable-targets=all.

	* sol2-tdep.c (sol2_static_transform_name): Remove.
	(sol2_init_abi): Don't register it.
	* gdbarch.sh (static_transform_name): Remove.
	* gdbarch.c, gdbarch.h: Regenerate.

	* dbxread.c (read_dbx_symtab) <'S'>: Remove call to
	gdbarch_static_transform_name.
	* mdebugread.c (parse_partial_symbols) <'S'>: Likewise.
	* stabsread.c (define_symbol) <'X'>: Remove.
	(define_symbol) <'S'>: Remove gdbarch_static_transform_name
	handling.
	<'V'>: Likewise.
	* xcoffread.c (scan_xcoff_symtab): Remove gdbarch.
	<'S'>: Remove call to gdbarch_static_transform_name.
2020-06-25 17:56:12 +02:00
Rainer Orth
c6d3683661 Use fork instead of vfork on Solaris
The gdb.mi/mi-exec-run.exp test never completed/timed out on Solaris for
quite some time:

FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected (timeout)

This is for gdb trying to exec mi-exec-run.nox, a copy of mi-exec-run
with execute permissions removed.

The process tree at this point looks like this:

          21254 /vol/gcc/bin/expect -- /vol/gcc/share/dejagnu/runtest.exp GDB_PARALLEL=yes --outdir=outputs/gdb.mi/mi-exec-run-vfork gdb.mi/mi-exec-run.exp
            21300 <defunct>
            21281 <defunct>
            21294 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi
              21297 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi

The parent gdb hangs here:

21294:  $obj/gdb/testsuite/../../gdb/gdb -nw
------------  lwp# 1 / thread# 1  ---------------
 0000000000000000 SYS#0    ()
 0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853)
 0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187)
 0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584)
 0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96)
 0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113)
 0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657)
 0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187)
 0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473)

with these process flags

21294:	$obj/gdb/testsuite/../../gdb/gdb -nw
	data model = _LP64  flags = VFORKP|ORPHAN|MSACCT|MSFORK
	sigpend = 0x00004103,0x00000000,0x00000000
 /1:	flags = 0
	sigmask = 0xffbffeff,0xffffffff,0x000000ff
	cursig = SIGKILL
 /2:	flags = DETACH|STOPPED|ASLEEP  lwp_park(0x0,0x0,0x0)
	why = PR_SUSPENDED
	sigmask = 0x000a2002,0x00000000,0x00000000
[...]

while the child sits at

21297:  $obj/gdb/testsuite/../../gdb/gdb -nw
 00007fffbf078a0b execve   (7fffbffff756, 7fffbfffec58, 7fffbfffec90, 0)
 00007fffbef84cf6 execvpex () + f6
 00007fffbef84f45 execvp () + 15
 0000000000d60a44 fork_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), gdb::function_view<void (int)>, void (*)(), char const*, void (*)(char const*, char* const*, char* const*)) () + 47f (fork-inferior.c:423)
 0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853)
 0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187)
 0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584)
 0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96)
 0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113)
 0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657)
 0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187)
 0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473)

with

21297:	$obj/gdb/testsuite/../../gdb/gdb -nw
	data model = _LP64  flags = MSACCT|MSFORK
	exitset  = 0x00000000 0x04000000 0x00000000 0x00000000
	           0x00000000 0x00000000 0x00000000 0x00000000
 /1:	flags = STOPPED|ISTOP  execve(0x7fffbffff756,0x7fffbfffec58,0x7fffbfffec90,0x0)
	why = PR_SYSEXIT  what = execve

We have a deadlock here: the execve in the child cannot return until the
parent has handled the PR_SYSEXIT while the parent cannot run with a
vfork'ed child as documented in proc(4):

       The child of a vfork(2) borrows the  parent's  address  space.  When  a
       vfork(2) is executed by a traced process, all watched areas established
       for the parent are suspended until the child terminates or performs  an
       exec(2).  Any  watched areas established independently in the child are
       cancelled when the parent resumes  after  the  child's  termination  or
       exec(2).  PCWATCH  fails  with  EBUSY  if  applied  to  the parent of a
       vfork(2) before the child has terminated or performed an  exec(2).  The
       PR_VFORKP  flag  is  set  in  the  pstatus  structure for such a parent
       process.

In that situation, the parent cannot be killed even with SIGKILL (as
runtest will attempt once the timeout occurs; the pending signal can be
seen in the pflags output above), so the whole test hangs until one
manually kills the child process.

Fortunately, there's an easy way out: when using fork instead of vfork,
the problem doesn't occur, and this is what the current patch does: it
calls fork_inferior with a dummy pre_trace_fun arg.

Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.

	* procfs.c (procfs_pre_trace): New function.
	(procfs_target::create_inferior): Pass it to fork_inferior.
2020-06-25 17:48:14 +02:00
Rainer Orth
a7e6196bb8 Don't include *sol2-tdep.o on Linux/sparc*
Linux/sparc* currently links Solaris-specific files (sparc-sol2-tdep.o,
sparc64-sol2-tdep.o, sol2-tdep.o) for no apparent reason.  It has no
business doing so, and none of the functions/variables defined there are
used explicitly.  If support for the Solaris OSABI were desired, this
should be done using --enable-targets instead.

Since neither sparc{32,64}_sol2_init_abi currently declared in common
headers (sparc*-tdep.h) are used outside their source files, they are made
static and the declarations removed.

Tested on sparcv9-sun-solaris2.11 and sparc64-unknown-linux-gnu.

	* configure.tgt <sparc-*-linux*> (gdb_target_obs): Remove
	sparc-sol2-tdep.o, sol2-tdep.o, sparc64-sol2-tdep.o.
	<sparc64-*-linux*> (gdb_target_obs): Remove sparc64-sol2-tdep.o,
	sol2-tdep.o, sparc-sol2-tdep.o.
	* sparc-sol2-tdep.c (sparc32_sol2_init_abi): Make static.
	* sparc-tdep.h (sparc32_sol2_init_abi): Remove.
	* sparc64-sol2-tdep.c (sparc64_sol2_init_abi): Make static.
	* sparc64-tdep.h (sparc64_sol2_init_abi): Remove.
2020-06-25 13:54:42 +02:00
Rainer Orth
d412e69677 Move common handlers to sol2_init_abi
There's some overlap and duplication between 32 and 64-bit Solaris/SPARC
and x86 tdep files, in particular

        sol2_core_pid_to_str
	*_sol2_sigtramp_p
        sol2_skip_solib_resolver
        *_sol2_static_transform_name (forgotten on amd64)
        set_gdbarch_sofun_address_maybe_missing (likewise)

This patch avoids this by centralizing common code in sol2-tdep.c.
While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name
were declared in the shared sparc-tdep.h, they were only used in Solaris
files.

Tested on amd64-pc-solaris2.11, i386-pc-solaris2.11,
sparcv9-sun-solaris2.11, and sparc-sun-solaris2.11, and
sparc64-unknown-linux-gnu.

	* amd64-sol2-tdep.c (amd64_sol2_sigtramp_p): Remove.
	(amd64_sol2_init_abi): Use sol2_sigtramp_p.
	Call sol2_init_abi.
 	Remove calls to set_gdbarch_skip_solib_resolver,
	set_gdbarch_core_pid_to_str.
	* i386-sol2-tdep.c (i386_sol2_sigtramp_p): Remove.
	(i386_sol2_static_transform_name): Remove.
	(i386_sol2_init_abi): Call sol2_init_abi.
	Remove calls to set_gdbarch_sofun_address_maybe_missing,
	set_gdbarch_static_transform_name,
	set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str.
	Use sol2_sigtramp_p.
	* sol2-tdep.c (sol2_pc_in_sigtramp): New function.
	(sol2_sigtramp_p): New function.
	(sol2_static_transform_name): New function.
	(sol2_skip_solib_resolver, sol2_core_pid_to_str): Make static.
	(sol2_init_abi): New function.
	* sol2-tdep.h (sol2_sigtramp_p, sol2_init_abi): Declare.
	(sol2_skip_solib_resolver, sol2_core_pid_to_str): Remove.
	* sparc-sol2-tdep.c (sparc_sol2_pc_in_sigtramp): Remove.
	(sparc32_sol2_sigtramp_frame_sniffer): Just call sol2_sigtramp_p.
	(sparc_sol2_static_transform_name): Remove.
	(sparc32_sol2_init_abi): Call sol2_init_abi.
	Remove calls to set_gdbarch_sofun_address_maybe_missing,
	set_gdbarch_static_transform_name,
	set_gdbarch_skip_solib_resolver,
	set_gdbarch_core_pid_to_str.
	* sparc-tdep.h (sparc_sol2_pc_in_sigtramp)
	(sparc_sol2_static_transform_name): Remove
	* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_sniffer): Just
	call sol2_sigtramp_p.
	(sparc64_sol2_init_abi): Call sol2_init_abi.
	Remove calls to set_gdbarch_sofun_address_maybe_missing,
	set_gdbarch_static_transform_name,
	set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str.
2020-06-25 13:43:46 +02:00
Pedro Alves
221db974e6 W/ Clang, compile/link C++ test programs with "-x c++"
Some testcases want to compile .c files with a C++ compiler.  So they
pass the "c++" option to gdb_compile.  That works fine with GCC, but
with Clang, it results in:

  gdb compile failed, clang-5.0: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]

and the testcase is skipped with UNTESTED.

A previous patch fixed a case like that in
gdb.compile/compile-cplus.exp, by adding -Wno-deprecated to the build
options.  However, there are other testcases that use the same
pattern, and all fail for the same reason.  For example:

 gdb.base/info-types-c++.exp
 gdb.base/max-depth-c++.exp
 gdb.base/msym-lang.exp
 gdb.base/whatis-ptype-typedefs.exp
 gdb.btrace/rn-dl-bind.exp

Fix this in a central place, within gdb_compile, by passing "-x c++"
to the compiler driver when we're compiling/linking C++.

This revealed that gdb.compile/compile-cplus.exp and
gdb.arch/amd64-entry-value-paramref.exp tests are compiling an
assembly file with the "c++" option, which would now fail to compile,
with the C++ compiler not grokking the assembly, of course.  We just
need to not pass "c++" and all the other related C++ options when
compiling an assembly file.

gdb/testsuite/ChangeLog:
2020-06-24  Pedro Alves  <palves@redhat.com>

	* gdb.arch/amd64-entry-value-paramref.exp: Use
	prepare_for_testing_full and don't pass "c++" for the .S file
	build spec.
	* gdb.compile/compile-cplus.exp: Don't compile $srcfile3 with
	$options, since it's an assembly file.  Remove -Wno-deprecated.
	* lib/gdb.exp (gdb_compile): Pass "-x c++" explicitly when
	compiling C++ programs.
2020-06-24 23:18:19 +01:00
Pedro Alves
331733cd4e W/ Clang, compile C/C++ testcases with -Wno-unknown-warning-option
Some C/C++ testcases unconditionally pass -Wno-foo as additional
options to disable some warning.  That is OK with GCC, because GCC
accepts -Wno-foo silently even if it doesn't support -Wfoo.  This is a
feature which allows disabling warnings with newer compilers without
breaking builds with older compilers.  Clang however warns about
unknown -Wno-foo by default, unless you pass
-Wno-unknown-warning-option as well:

 $ gcc -Wno-foo test.c
 * nothing, compiles successfuly *

 $ clang -Wno-foo test.c
 warning: unknown warning option '-Wno-foo [-Wunknown-warning-option]

This commit adds -Wunknown-warning-option centrally in gdb_compile, so
that individual testcases don't have to worry about breaking older
Clangs.

IOW, this avoids this problematic scenario:

#1 - A testcase compiles successfully with Clang version X.
#2 - Clang version "X + 1" adds a new warning, enabled by default,
     which breaks the test.
#3 - We add -Wno-newwarning to the testcase, fixing the testcase with
     clang "X + 1".
#4 - Now building the test with Clang version X no longer works, due
     to "unknown warning option".

gdb/testsuite/ChangeLog:
2020-06-24  Pedro Alves  <palves@redhat.com>

	* lib/gdb.exp (gdb_compile): Update intro comment.  If C/C++ with
	Clang, add "-Wno-unknown-warning-option" to the options.
2020-06-24 23:18:19 +01:00
Philippe Waroquiers
a8654e7d78 Fixes PR 25475: ensure exec-file-mismatch "ask" always asks in case of mismatch.
As explained in https://sourceware.org/bugzilla/show_bug.cgi?id=25475,
when the currently loaded file has no debug symbol,
symbol_file_add_with_addrs does not ask a confirmation to the user
before loading the new symbol file.  The behaviour is not consistent
when symbol_file_add_with_addrs is called due to exec-file-mismatch "ask"
setting.

The PR discusses several solutions/approaches.
The preferred approach (suggested by Joel) is to ensure that GDB always asks
a confirmation when it loads a new symbol file due to exec-file-mismatch,
using a new SYMFILE add-flag.

I tested this manually.  If OK, we can remove the bypass introduced by Tom
in 6b9374f1, in order to always answer to the 'load' question.

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

	* symfile-add-flags.h: New flag SYMFILE_ALWAYS_CONFIRM.
	* exec.c (validate_exec_file): If from_tty, set both
	SYMFILE_VERBOSE (== from_tty) and SYMFILE_ALWAYS_CONFIRM.
	* symfile.c (symbol_file_add_with_addrs): if always_confirm
	and from_tty, unconditionally ask a confirmation.
2020-06-24 22:21:07 +02:00
Andrew Burgess
caa7fd04f6 gdb: New maintenance command to print XML target description
This commit adds a new maintenance command that dumps the current
target description as an XML document.  This is a maintenance command
as I currently only see this being useful for GDB developers, or for
people debugging a new remote target.

By default the command will print whatever the current target
description is, whether this was delivered by the remote, loaded by
the user from a file, or if it is a built in target within GDB.

The command can also take an optional filename argument.  In this case
GDB loads a target description from the file, and then reprints it.
This could be useful for testing GDB's parsing of target descriptions,
or to check that GDB can successfully parse a particular XML
description.

It is worth noting that the XML description printed will not be an
exact copy of the document fed into GDB.  For example this minimal
input file:

  <target>
    <feature name="abc">
      <reg name="r1" bitsize="32"/>
    </feature>
  </target>

Will produce this output:

  (gdb) maint print xml-tdesc path/to/file.xml
  <?xml version="1.0"?>
  <!DOCTYPE target SYSTEM "gdb-target.dtd">
  <target>
    <feature name="abc">
      <reg name="r1" bitsize="32" type="int" regnum="0"/>
    </feature>
  </target>

Notice that GDB filled in both the 'type' and 'regnum' fields of the
<reg>.  I think this is actually a positive as it means we get to
really understand how GDB processed the document, if GDB made some
assumptions that differ to those the user expected then hopefully this
will bring those issues to the users attention.

To implement this I have tweaked the output produced by the
print_xml_feature which is defined within the gdbsupport/ directory.
The changes I have made to this class are:

  1. The <architecture>...</architecture> tags are now not produced if
  the architecture name is NULL.

  2. The <osabi>...</osabi> tags get a newline at the end.

  3. And, the whole XML document is indented using white space in a
  nested fashion (as in the example output above).

I think that these changes should be fine, the print_xml_feature class
is used:

  1. In gdbserver to generate an XML document to send as the target
  description to GDB.

  2. In GDB as part of a self-check function, a target_desc is
  converted to XML then parsed back into a target_desc.  We then check
  the before and after target_desc objects are the same.

  3. In the new 'maint print xml-tdesc' command.

In all of these use cases adding the extra white space should be fine.

gdbsupport/ChangeLog:

	* tdesc.cc (print_xml_feature::visit_pre): Use add_line to add
	output content, and call indent as needed in all overloaded
	variants.
	(print_xml_feature::visit_post): Likewise.
	(print_xml_feature::visit): Likewise.
	(print_xml_feature::add_line): Two new overloaded functions.
	* tdesc.h (print_xml_feature::indent): New member function.
	(print_xml_feature::add_line): Two new overloaded member
	functions.
	(print_xml_feature::m_depth): New member variable.

gdb/ChangeLog:

	* target-descriptions.c (tdesc_architecture_name): Protect against
	NULL pointer dereference.
	(maint_print_xml_tdesc_cmd): New function.
	(_initialize_target_descriptions): Register new 'maint print
	xml-tdesc' command and give it the filename completer.
	* NEWS: Mention new 'maint print xml-tdesc' command.

gdb/testsuite/ChangeLog:

	* gdb.xml/tdesc-reload.c: New file.
	* gdb.xml/tdesc-reload.exp: New file.
	* gdb.xml/maint-xml-dump-01.xml: New file.
	* gdb.xml/maint-xml-dump-02.xml: New file.
	* gdb.xml/maint-xml-dump.exp: New file.

gdb/doc/ChangeLog:

	* gdb.texinfo (Maintenance Commands): Document new 'maint print
	xml-desc' command.
2020-06-23 22:17:20 +01:00
Andrew Burgess
fbf42f4e6d gdb: Print compatible information within print_xml_feature
The gdbsupport directory contains a helper class print_xml_feature
that is shared between gdb and gdbserver.  This class is used for
printing an XML representation of a target_desc object.

Currently this class doesn't have the ability to print the
<compatible> entities that can appear within a target description, I
guess no targets have needed that functionality yet.

The print_xml_feature classes API is based around operating on the
target_desc class, however, the sharing between gdb and gdbserver is
purely textural, we rely on their being a class called target_desc in
both gdb and gdbserver, but there is no shared implementation.  We
then have a set of functions declared that operate on an object of
type target_desc, and again these functions have completely separate
implementations.

Currently then the gdb version of target_desc contains a vector of
bfd_arch_info pointers which represents the compatible entries from a
target description.  The gdbserver version of target_desc has no such
information.  Further, the gdbserver code doesn't seem to include the
bfd headers, and so doesn't know about the bfd types.

I was reluctant to include the bfd headers into gdbserver just so I
can reference the compatible information, which isn't (currently) even
needed in gdbserver.

So, the approach I take in this patch is to wrap the compatible
information into a new helper class.  This class is declared in the
gdbsupport library, but implemented separately in both gdb and
gdbserver.

In gdbserver the class is empty.  The compatible information within
the gdbserver is an empty list, of empty classes.

In gdb the class contains a pointer to the bfd_arch_info object.

With this in place we can now add support to print_xml_feature for
printing the compatible information if it is present.  In the
gdbserver code this will never happen, as the gdbserver never has any
compatible information.  But in gdb, this code will trigger when
appropriate.

gdb/ChangeLog:

	* target-descriptions.c (class tdesc_compatible_info): New class.
	(struct target_desc): Change type of compatible vector.
	(tdesc_compatible_p): Update for change in type of
	target_desc::compatible.
	(tdesc_compatible_info_list): New function.
	(tdesc_compatible_info_arch_name): New function.
	(tdesc_add_compatible): Update for change in type of
	target_desc::compatible.
	(print_c_tdesc::visit_pre): Likewise.

gdbserver/ChangeLog:

	* tdesc.cc (struct tdesc_compatible_info): New struct.
	(tdesc_compatible_info_list): New function.
	(tdesc_compatible_info_arch_name): New function.

gdbsupport/ChangeLog:

	* tdesc.cc (print_xml_feature::visit_pre): Print compatible
	information.
	* tdesc.h (struct tdesc_compatible_info): Declare new struct.
	(tdesc_compatible_info_up): New typedef.
	(tdesc_compatible_info_list): Declare new function.
	(tdesc_compatible_info_arch_name): Declare new function.
2020-06-23 22:17:19 +01:00
Andrew Burgess
20821f4ed1 gdb: Allow target description to be dumped even when it is remote
The maintenance command 'maintenance print c-tdesc' can only print the
target description if it was loaded from a local file, or if the local
filename is passed to the maintenance command as an argument.

Sometimes it would be nice to know what target description GDB was
given by the remote, however, if I connect to a remote target and try
this command I see this:

  (gdb) maintenance print c-tdesc
  The current target description did not come from an XML file.
  (gdb)

Which is not very helpful.

This commit changes things so that if the description came from the
remote end then GDB will use a fake filename 'fetched from target' as
the filename for the description, GDB will then create the C
description of the target as though it came from this file.  Example
output would look like this (I snipped the feature creation from the
middle as that hasn't changed):

  (gdb) maintenance print c-tdesc
  /* THIS FILE IS GENERATED.  -*- buffer-read-only: t -*- vi:set ro:
    Original: fetched from target */

  #include "defs.h"
  #include "osabi.h"
  #include "target-descriptions.h"

  struct target_desc *tdesc_fetched_from_target;
  static void
  initialize_tdesc_fetched_from_target (void)
  {
    struct target_desc *result = allocate_target_description ();
    struct tdesc_feature *feature;

    /* ... features created here ... */

    tdesc_fetched_from_target = result;
  }
  (gdb)

In order to support using 'fetched from target' I had to update the
print_c_tdesc code to handle filenames that include a space.  This has
the benefit that we can now print out real files with spaces in the
name, for example the file 'with space.xml':

  (gdb) maint print c-tdesc with space.xml

I originally added this functionality so I could inspect the
description passed to GDB by the remote target.  After using this for
a while I realised that actually having GDB recreate the XML would be
even better, so a later commit will add that functionality too.

Still, given how small this patch is I thought it might be nice to
include this in GDB anyway.

While I was working on this anyway I've added filename command
completion to this command.

gdb/ChangeLog:

	* target-descriptions.c (print_c_tdesc::print_c_tdesc): Change
	whitespace to underscore.
	(maint_print_c_tdesc_cmd): Use fake filename for target
	descriptions that came from the target.
	(_initialize_target_descriptions): Add filename command completion
	for 'maint print c-tdesc'.
2020-06-23 22:17:18 +01:00
Simon Marchi
1fb5ee6203 gdb: add some more empty lines in loc.c
Add some empty lines at places I forgot in the previous patch.

gdb/ChangeLog:

	* dwarf2/loc.c (decode_debug_loclists_addresses): Add empty
	lines.

Change-Id: I8a9f3766ede1ce750e0703023285dca873bce0da
2020-06-23 15:40:24 -04:00
Simon Marchi
fc3ecb3e61 gdb: add empty lines in loc.c
I always found that some switch statements in this file were a bit too
packed.  I think having empty lines between each case helps with
reading.  I'm pushing this as obvious, I hope it won't be too
controversial.

gdb/ChangeLog:

	* dwarf2/loc.c (decode_debug_loc_dwo_addresses): Add empty
	lines.
	(dwarf2_find_location_expression): Likewise.
	(call_site_parameter_matches): Likewise.
	(dwarf2_compile_expr_to_ax): Likewise.
	(disassemble_dwarf_expression): Likewise.
	(loclist_describe_location): Likewise.

Change-Id: I381366a0468ff1793faa612c46ef48a9d4773192
2020-06-23 15:34:45 -04:00
Pedro Alves
236ef0346d Fix "maint selftest" regression, add struct scoped_mock_context
This commit:

 commit 3922b30264
 Author:     Pedro Alves <palves@redhat.com>
 AuthorDate: Thu Jun 18 21:28:37 2020 +0100

    Decouple inferior_ptid/inferior_thread(); dup ptids in thread list (PR 25412)

caused a regression for gdb.gdb/unittest.exp when GDB is configured
with --enable-targets=all.  The failure is:

  gdb/thread.c:95: internal-error: thread_info* inferior_thread(): Assertion `current_thread_ != nullptr' failed.

The problem is in this line in regcache.c:cooked_read_test:

  /* Switch to the mock thread.  */
  scoped_restore restore_inferior_ptid
    = make_scoped_restore (&inferior_ptid, mock_ptid);

Both gdbarch-selftest.c and regcache.c set up a similar mock context,
but the series the patch above belongs to only updated the
gdbarch-selftest.c context to not write to inferior_ptid directly, and
missed updating regcache.c's.

Instead of copying the fix over to regcache.c, share the mock context
setup code in a new RAII class, based on gdbarch-selftest.c's version.

Also remove the "target already pushed" error from regcache.c, like it
had been removed from gdbarch-selftest.c in the multi-target series.
That check is unnecessary because each inferior now has its own target
stack, and the unit test pushes a target on a separate (mock)
inferior, not the current inferior on entry.

gdb/ChangeLog:
2020-06-23  Pedro Alves  <palves@redhat.com>

	* gdbarch-selftests.c: Don't include inferior.h, gdbthread.h or
	progspace-and-thread.h.  Include scoped-mock-context.h instead.
	(register_to_value_test): Use scoped_mock_context.
	* regcache.c: Include "scoped-mock-context.h".
	(cooked_read_test): Don't error out if a target is already pushed.
	Use scoped_mock_context.  Adjust.
	* scoped-mock-context.h: New file.
2020-06-23 18:57:03 +01:00
Sandra Loosemore
bb8d126033 Adjust command completion output when TUI is disabled
The history-scrolling commands "+", "-", "<" and ">" are only known to
GDB when TUI is enabled.  This means the "complete pipe " command
produces different output depending on whether TUI is present, which
in turn caused

FAIL: gdb.base/shell.exp: cmd complete "pipe "

This patch provides different patterns for that test depending on
whether or not TUI is available.

2020-06-23  Sandra Loosemore  <sandra@codesourcery.com>

	gdb/testsuite/
	* lib/completion-support.exp (test_gdb_completion_offers_commands):
	Adjust for omitted commands when TUI is disabled.
2020-06-23 09:33:31 -07: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
Andrew Burgess
39e7eccae6 gdb: Convert language la_is_string_type_p field to a method
This commit changes the language_data::la_is_string_type_p function
pointer member variable into a member function of language_defn.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (ada_language_data): Delete la_is_string_type_p
	initializer.
	(ada_language::is_string_type_p): New member function.
	* c-lang.c (c_language_data): Delete la_is_string_type_p
	initializer.
	(cplus_language_data): Likewise.
	(asm_language_data): Likewise.
	(minimal_language_data): Likewise.
	* d-lang.c (d_language_data): Likewise.
	* f-lang.c (f_is_string_type_p): Delete function, implementation
	moved to f_language::is_string_type_p.
	(f_language_data): Delete la_is_string_type_p initializer.
	(f_language::is_string_type_p): New member function,
	implementation from f_is_string_type_p.
	* go-lang.c (go_is_string_type_p): Delete function, implementation
	moved to go_language::is_string_type_p.
	(go_language_data): Delete la_is_string_type_p initializer.
	(go_language::is_string_type_p): New member function,
	implementation from go_is_string_type_p.
	* language.c (language_defn::is_string_type_p): Define new member
	function.
	(default_is_string_type_p): Make static, add comment copied from
	header file.
	(unknown_language_data): Delete la_is_string_type_p initializer.
	(unknown_language::is_string_type_p): New member function.
	(auto_language_data): Delete la_is_string_type_p initializer.
	(auto_language::is_string_type_p): New member function.
	* language.h (language_data): Delete la_is_string_type_p field.
	(language_defn::is_string_type_p): Declare new function.
	(default_is_string_type_p): Delete desclaration, move comment to
	definition.
	* m2-lang.c (m2_is_string_type_p): Delete function, implementation
	moved to m2_language::is_string_type_p.
	(m2_language_data): Delete la_is_string_type_p initializer.
	(m2_language::is_string_type_p): New member function,
	implementation from m2_is_string_type_p.
	* objc-lang.c (objc_language_data): Delete la_is_string_type_p
	initializer.
	* opencl-lang.c (opencl_language_data): Likewise.
	* p-lang.c (pascal_is_string_type_p): Delete function,
	implementation moved to pascal_language::is_string_type_p.
	(pascal_language_data): Delete la_is_string_type_p initializer.
	(pascal_language::is_string_type_p): New member function,
	implementation from pascal_is_string_type_p.
	* rust-lang.c (rust_is_string_type_p): Delete function,
	implementation moved to rust_language::is_string_type_p.
	(rust_language_data): Delete la_is_string_type_p initializer.
	(rust_language::is_string_type_p): New member function,
	implementation from rust_is_string_type_p.
	* valprint.c (val_print_scalar_or_string_type_p): Update call to
	is_string_type_p.
2020-06-23 13:34:11 +01:00
Andrew Burgess
4ffc13fb0e gdb: Convert language la_print_typedef field to a method
This commit changes the language_data::la_print_typedef function
pointer member variable into a member function of language_defn.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (ada_language_data): Delete la_print_typedef
	initializer.
	(ada_language::print_typedef): New member function.
	* c-lang.c (c_language_data): Delete la_print_typedef initializer.
	(cplus_language_data): Likewise.
	(asm_language_data): Likewise.
	(minimal_language_data): Likewise.
	* d-lang.c (d_language_data): Likewise.
	* f-lang.c (f_language_data): Likewise.
	(f_language::print_typedef): New member function.
	* go-lang.c (go_language_data): Delete la_print_typedef
	initializer.
	* language.c (language_defn::print_typedef): Define member
	function.
	(unknown_language_data): Delete la_print_typedef initializer.
	(unknown_language::print_typedef): New member function.
	(auto_language_data): Delete la_print_typedef initializer.
	(auto_language::print_typedef): New member function.
	* language.h (language_data): Delete la_print_typedef field.
	(language_defn::print_typedef): Declare new member function.
	(LA_PRINT_TYPEDEF): Update call to print_typedef.
	(default_print_typedef): Delete declaration.
	* m2-lang.c (m2_language_data): Delete la_print_typedef
	initializer.
	(m2_language::print_typedef): New member function.
	* objc-lang.c (objc_language_data): Delete la_print_typedef
	initializer.
	* opencl-lang.c (opencl_language_data): Likewise.
	* p-lang.c (pascal_language_data): Likewise.
	(pascal_language::print_typedef): New member function.
	* rust-lang.c (rust_print_typedef): Delete function,
	implementation moved to rust_language::print_typedef.
	(rust_language): Delete la_print_typedef initializer.
	(rust_language::print_typedef): New member function,
	implementation from rust_print_typedef.
	* typeprint.c (default_print_typedef): Delete.
2020-06-23 13:34:11 +01:00
Andrew Burgess
d711ee67ac gdb: Convert language la_printstr field to a method
This commit changes the language_data::la_printstr function pointer
member variable into a member function of language_defn.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (ada_language_data): Delete la_printstr initializer.
	(ada_language::printstr): New member function.
	* c-lang.c (c_language_data): Delete la_printstr initializer.
	(cplus_language_data): Likewise.
	(asm_language_data): Likewise.
	(minimal_language_data): Likewise.
	* d-lang.c (d_language_data): Likewise.
	* f-lang.c (f_printstr): Rename to f_language::printstr.
	(f_language_data): Delete la_printstr initializer.
	(f_language::printstr): New member function, implementation from
	f_printstr.
	* go-lang.c (go_language_data): Delete la_printstr initializer.
	* language.c (language_defn::printstr): Define new member
	function.
	(unk_lang_printstr): Delete.
	(unknown_language_data): Delete la_printstr initializer.
	(unknown_language::printstr): New member function.
	(auto_language_data): Delete la_printstr initializer.
	(auto_language::printstr): New member function.
	* language.h (language_data): Delete la_printstr field.
	(language_defn::printstr): Declare new member function.
	(LA_PRINT_STRING): Update call to printstr.
	* m2-lang.c (m2_printstr): Rename to m2_language::printstr.
	(m2_language_data): Delete la_printstr initializer.
	(m2_language::printstr): New member function, implementation from
	m2_printstr.
	* objc-lang.c (objc_language_data): Delete la_printstr
	initializer.
	* opencl-lang.c (opencl_language_data): Likewise.
	* p-lang.c (pascal_printstr): Rename to pascal_language::printstr.
	(pascal_language_data): Delete la_printstr initializer.
	(pascal_language::printstr): New member function, implementation
	from pascal_printstr.
	* p-lang.h (pascal_printstr): Delete declaration.
	* rust-lang.c (rust_printstr): Update header comment.
	(rust_language_data): Delete la_printstr initializer.
	(rust_language::printstr): New member function.
2020-06-23 13:34:11 +01:00
Andrew Burgess
52b50f2c1b gdb: Convert language la_printchar field to a method
This commit changes the language_data::la_printchar function pointer
member variable into a member function of language_defn.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (ada_language_data): Delete la_printchar initializer.
	(ada_language::printchar): New member function.
	* c-lang.c (c_language_data): Delete la_printchar initializer.
	(cplus_language_data): Likewise.
	(asm_language_data): Likewise.
	(minimal_language_data): Likewise.
	* d-lang.c (d_language_data): Likewise.
	* f-lang.c (f_printchar): Rename to f_language::printchar.
	(f_language_data): Delete la_printchar initializer.
	(f_language::printchar): New member function, implementation from
	f_printchar.
	* go-lang.c (go_language_data): Delete la_printchar initializer.
	* language.c (unk_lang_printchar): Delete.
	(language_defn::printchar): Define new member function.
	(unknown_language_data): Delete la_printchar initializer.
	(unknown_language::printchar): New member function.
	(auto_language_data): Delete la_printchar initializer.
	(auto_language::printchar): New member function.
	* language.h (language_data): Delete la_printchar field.
	(language_defn::printchar): Declare new member function.
	(LA_PRINT_CHAR): Update call to printchar.
	* m2-lang.c (m2_language_data): Delete la_printchar initializer.
	(m2_language::printchar): New member function.
	* objc-lang.c (objc_language_data): Delete la_printchar
	initializer.
	* opencl-lang.c (opencl_language_data): Likewise.
	* p-lang.c (pascal_language_data): Delete la_printchar
	initializer.
	(pascal_language::printchar): New member function.
	* rust-lang.c (rust_printchar): Rename to
	rust_language::printchar.
	(rust_language_data): Delete la_printchar initializer.
	(rust_language::printchar): New member function, implementation
	from rust_printchar.
2020-06-23 13:34:11 +01:00
Andrew Burgess
ec8cec5b96 gdb: Convert language la_emitchar field to a method
This commit changes the language_data::la_emitchar function pointer
member variable into a member function of language_defn.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (emit_char): Renamed to ada_language::emitchar.
	(ada_language_data): Delete la_emitchar initializer.
	(ada_language::emitchar): New member function, implementation from
	emit_char.
	* c-lang.c (c_language_data): Delete la_emitchar initializer.
	(cplus_language_data): Likewise.
	(asm_language_data): Likewise.
	(minimal_language_data): Likewise.
	* d-lang.c (d_language_data): Likewise.
	* f-lang.c (f_emit_char): Rename to f_language::emitchar.
	(f_language_data): Delete la_emitchar initializer.
	(f_language::emitchar): New member function, implementation from
	f_emit_char.
	* go-lang.c (go_language_data): Delete la_emitchar initializer.
	* language.c (unk_lang_emit_char): Delete.
	(language_defn::emitchar): New member function definition.
	(unknown_language_data): Delete la_emitchar initializer.
	(unknown_language::emitchar): New member function.
	(auto_language_data): Delete la_emitchar initializer.
	(auto_language::emitchar): New member function.
	* language.h (language_data): Delete la_emitchar field.
	(language_defn::emitchar): New member field declaration.
	(LA_EMIT_CHAR): Update call to emitchar.
	* m2-lang.c (m2_emit_char): Rename to m2_language::emitchar.
	(m2_language_data): Delete la_emitchar initializer.
	(m2_language::emitchar): New member function, implementation from
	m2_emit_char.
	* objc-lang.c (objc_language_data): Delete la_emitchar
	initializer.
	* opencl-lang.c (opencl_language_data): Likewise.
	* p-lang.c (pascal_emit_char): Rename to pascal_language::emitchar.
	(pascal_language_data): Delete la_emitchar initializer.
	(pascal_language::emitchar): New member function, implementation
	from pascal_emit_char.
	* rust-lang.c (rust_emitchar): Rename to rust_language::emitchar.
	(rust_language_data): Delete la_emitchar initializer.
	(rust_language::emitchar): New member function, implementation
	from rust_emitchar.
2020-06-23 13:34:11 +01:00
Andrew Burgess
1bf9c36374 gdb: Convert language la_post_parser field to a method
This commit changes the language_data::la_post_parser function pointer
member variable into a member function of language_defn.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (resolve): Rename to ada_language::post_parser.
	(ada_language_data): Delete la_post_parser initializer.
	(ada_language::post_parser): New member function.
	* c-lang.c (c_language_data): Delete la_post_parser initializer.
	(cplus_language_data): Likewise.
	(asm_language_data): Likewise.
	(minimal_language_data): Likewise.
	* d-lang.c (d_language_data): Likewise.
	* f-lang.c (f_language_data): Likewise.
	* go-lang.c (go_language_data): Likewise.
	* language.c (unknown_language_data): Likewise.
	(auto_language_data): Likewise.
	* language.h (language_data): Delete la_post_parser field.
	(language_defn::post_parser): New member function.
	* m2-lang.c (m2_language_data): Delete la_post_parser initializer.
	* objc-lang.c (objc_language_data): Likewise.
	* opencl-lang.c (opencl_language_data): Likewise.
	* p-lang.c (pascal_language_data): Likewise.
	* parse.c (parse_exp_in_context): Update call to post_parser.
	(null_post_parser): Delete definition.
	* parser-defs.h (null_post_parser): Delete declaration.
	* rust-lang.c (rust_language_data): Delete la_post_parser
	initializer.
2020-06-23 13:34:11 +01:00
Andrew Burgess
87afa6523b gdb: Convert language la_parser field to a method
This commit changes the language_data::la_parser function pointer
member variable into a member function of language_defn.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* ada-lang.c (parse): Rename to ada_language::parser.
	(ada_language_data): Delete la_parser initializer.
	(ada_language::parser): New member function, implementation from
	parse.
	* c-lang.c (c_language_data): Delete la_parser initializer.
	(cplus_language_data): Likewise.
	(asm_language_data): Likewise.
	(minimal_language_data): Likewise.
	* d-lang.c (d_language_data): Likewise.
	(d_language::parser): New member function.
	* f-lang.c (f_language_data): Delete la_parser initializer.
	(f_language::parser): New member function.
	* go-lang.c (go_language_data): Delete la_parser initializer.
	(go_language::parser): New member function.
	* language.c (unk_lang_parser): Delete.
	(language_defn::parser): Define new member function.
	(unknown_language_data): Delete la_parser initializer.
	(unknown_language::parser): New member function.
	(auto_language_data): Delete la_parser initializer.
	(auto_language::parser): New member function.
	* language.h (language_data): Delete la_parser field.
	(language_defn::parser): Declare new member function.
	* m2-lang.c (m2_language_data): Delete la_parser initializer.
	(m2_language::parser): New member function.
	* objc-lang.c (objc_language_data): Delete la_parser initializer.
	* opencl-lang.c (opencl_language_data): Likewise.
	* p-lang.c (pascal_language_data): Likewise.
	(pascal_language::parser): New member function.
	* parse.c (parse_exp_in_context): Update call to parser.
	* rust-lang.c (rust_language_data): Delete la_parser initializer.
	(rust_language::parser): New member function.
2020-06-23 13:34:10 +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
Andrew Burgess
378258006c gdb: Add --with-python-libdir to gdb's --configuration output
Commit:

  commit d13c7322fe
  Date:   Fri Jan 17 00:10:22 2020 +0000

      gdb: Allow more control over where to find python libraries

Added a new configuration option --with-python-libdir, but failed to
add this option to the output of 'gdb --configuration'.  This commit
fixes this mistake.

gdb/ChangeLog:

	* top.c (print_gdb_configuration): Print --with-python-libdir
	configuration value.
2020-06-23 10:06:20 +01:00
Philippe Waroquiers
5b860c93e3 NEWS and documentation for alias default-args related concept and commands.
gdb/ChangeLog
2020-06-22  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* NEWS: Mention change to the alias command.

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

	* gdb.texinfo (Command aliases default args): New node documenting
	how to use default args for a command using aliases.
	(Aliases): Document the new 'DEFAULT-ARGS...' option.
	(Help): Update help aliases text and describe when full alias
	definition is provided.
2020-06-22 21:16:25 +02:00