Chenghua Xu [Mon, 26 Jul 2021 12:58:49 +0000 (20:58 +0800)]
Correct gs264e bfd_mach in mips_arch_choices.
opcodes/
* mips-dis.c (mips_arch_choices): Correct gs264e bfd_mach.
Roland McGrath [Tue, 27 Jul 2021 00:55:12 +0000 (17:55 -0700)]
Fix ld test case that assumes --enable-textrel-check
ld/
* testsuite/ld-x86-64/x86-64.exp (Build textrel-1): Use --warn-textrel.
GDB Administrator [Tue, 27 Jul 2021 00:00:23 +0000 (00:00 +0000)]
Automatic date update in version.in
H.J. Lu [Mon, 26 Jul 2021 12:37:57 +0000 (05:37 -0700)]
bfd: Set error to bfd_error_malformed_archive only if unset
When reading an archive member, set error to bfd_error_malformed_archive
on open_nested_file failure only if the error is unset.
PR ld/28138
* archive.c (_bfd_get_elt_at_filepos): Don't set error to
bfd_error_malformed_archive if it has been set.
Carl Love [Tue, 20 Jul 2021 22:42:48 +0000 (17:42 -0500)]
Fix for mi-reverse.exp
This test fails on PPC64 because PPC64 prints the value of 3.5 with
more significant digits than on Intel. The patch updates the regular
expression to allow for more significant digits on the constant.
gdb/testsuite/ChangeLog
* gdb.mi/mi-reverse.exp: mi_execute_to exec-step reverse add check
for additional digits.
Tom Tromey [Mon, 26 Jul 2021 13:34:37 +0000 (07:34 -0600)]
Fix the Windows build
The gdb build was broken on Windows after the patch to change
get_inferior_cwd. This patch fixes the build.
Shahab Vahedi [Fri, 16 Jul 2021 14:49:15 +0000 (16:49 +0200)]
gdb: Fix numerical field extraction for target description "flags"
The "val_print_type_code_flags ()" function is responsible for
extraction of fields for "flags" data type. These data types are
used when describing a custom register type in a target description
XML. The logic used for the extraction though is not sound:
unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
ULONGEST field_val
= val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB.
val: The register value.
Imagine you have a field that starts at position 1 and its length
is 4 bits. According to the third line of the code snippet the
shifting right would become "val >> -2", or "val >> 0xfff...fe"
to be precise. That will result in a "field_val" of 0.
The correct extraction should be:
ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);
The rest of the algorithm that masks out the higher bits is OK.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Andrea Corallo [Fri, 11 Jun 2021 07:53:09 +0000 (09:53 +0200)]
PATCH [10/10] arm: Alias 'ra_auth_code' to r12 for pacbti.
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (reg_names): Alias 'ra_auth_code' to r12.
Andrea Corallo [Tue, 8 Jun 2021 17:03:29 +0000 (19:03 +0200)]
PATCH [9/10] arm: add 'pacg' instruction for Armv8.1-M pacbti extension
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (T16_32_TAB): Add '_pacg'.
(do_t_pacbti_pacg): New function.
(insns): Define 'pacg' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacg' test.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
opcodes/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* arm-dis.c (thumb32_opcodes): Add 'pacg'.
Andrea Corallo [Tue, 8 Jun 2021 13:22:12 +0000 (15:22 +0200)]
PATCH [8/10] arm: add 'autg' instruction for Armv8.1-M pacbti extension
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (T16_32_TAB): Add '_autg'.
(insns): Define 'autg' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add autg test.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
opcodes/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* arm-dis.c (thumb32_opcodes): Add 'autg'.
Andrea Corallo [Wed, 19 May 2021 13:04:24 +0000 (15:04 +0200)]
PATCH [7/10] arm: add 'bxaut' instruction for Armv8.1-M pacbti extension
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (T16_32_TAB): Add '_bxaut'.
(do_t_pacbti_nonop): New function.
(insns): Define 'bxaut' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'bxaut' test.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
opcodes/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* arm-dis.c (thumb32_opcodes): Add 'bxaut'.
Andrea Corallo [Fri, 4 Jun 2021 08:17:17 +0000 (10:17 +0200)]
PATCH [6/10] arm: Add -march=armv8.1-m.main+pacbti flag
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (pacbti_ext): Define.
(BAD_PACBTI): New macro.
(armv8_1m_main_ext_table): Add 'pacbti' extension.
include/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* opcode/arm.h (ARM_EXT3_PACBTI, ARM_AEXT3_V8_1M_MAIN_PACBTI): New
macro.
Andrea Corallo [Thu, 3 Jun 2021 14:48:05 +0000 (16:48 +0200)]
PATCH [5/10] arm: Extend again arm_feature_set struct to provide more bits
include/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* opcode/arm.h (arm_feature_set): Extend 'core' field.
(ARM_CPU_HAS_FEATURE, ARM_FSET_CPU_SUBSET, ARM_CPU_IS_ANY)
(ARM_MERGE_FEATURE_SETS, ARM_CLEAR_FEATURE, ARM_FEATURE_EQUAL)
(ARM_FEATURE_ZERO, ARM_FEATURE_CORE_EQUAL): Account for
'core[2]'.
(ARM_FEATURE_CORE_HIGH_HIGH): New macro.
Andrea Corallo [Wed, 19 May 2021 07:51:40 +0000 (09:51 +0200)]
PATCH [4/10] arm: add 'pac' instruction for Armv8.1-M pacbti extension
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (T16_32_TAB): Add '_pac'.
(insns): Add 'pac' insn.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add pac tests.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
opcodes/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* arm-dis.c (thumb32_opcodes): Add 'pac'.
Andrea Corallo [Wed, 19 May 2021 07:00:14 +0000 (09:00 +0200)]
PATCH [3/10] arm: add 'aut' instruction for Armv8.1-M pacbti extension
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (insns): Add 'aut.'
(T16_32_TAB): Add '_aut'.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add 'aut' tests.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
opcodes/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* arm-dis.c (thumb32_opcodes): Add 'aut'.
Andrea Corallo [Tue, 18 May 2021 09:28:17 +0000 (11:28 +0200)]
PATCH [2/10] arm: add 'pacbti' instruction for Armv8.1-M pacbti extension
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c
(enum operand_parse_code): Add OP_SP and OP_R12.
(parse_operands): Add switch cases for OP_SP and OP_R12.
(T16_32_TAB): Add '_pacbti'.
(do_t_pacbti): New function.
(insns): Add 'pacbti'.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.d: New file.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacbti' to testcase.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
opcodes/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* arm-dis.c (thumb32_opcodes): Add 'pacbti' instruction.
Andrea Corallo [Fri, 14 May 2021 14:19:39 +0000 (16:19 +0200)]
PATCH [1/10] arm: add 'bti' instruction for Armv8.1-M pacbti extension
gas/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* config/tc-arm.c (insns): Add 'bti' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: New file.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.
opcodes/
2021-06-11 Andrea Corallo <andrea.corallo@arm.com>
* arm-dis.c (thumb32_opcodes): Add bti instruction.
Andrew Burgess [Fri, 23 Jul 2021 09:30:36 +0000 (10:30 +0100)]
gdb: move remaining ChangeLogs to legacy files
In commit:
commit
f069ea46a03ae868581d1c852da28e979ea1245a
Date: Sat Jul 3 16:29:08 2021 -0700
Rename gdb/ChangeLog to gdb/ChangeLog-2021
The gdb/ChangeLog file was renamed, but all of the other ChangeLog
files relating to gdb were left in place.
As I understand things, the no ChangeLogs policy applies to all the
GDB related directories, so this commit renames all of the remaining
GDB related ChangeLog files.
As with the original commit, the intention behind this commit is to
hopefully stop people merging ChangeLog entries by mistake.
The renames carried out in this commit are:
gdb/doc/ChangeLog -> gdb/doc/ChangeLog-1991-2021
gdb/stubs/ChangeLog -> gdb/stubs/ChangeLog-2012-2020
gdb/testsuite/ChangeLog -> gdb/testsuite/ChangeLog-2014-2021
gdbserver/ChangeLog -> gdbserver/ChangeLog-2002-2021
gdbsupport/ChangeLog -> gdbsupport/ChangeLog-2020-2021
Tankut Baris Aktemur [Mon, 26 Jul 2021 06:25:03 +0000 (08:25 +0200)]
gdb/mi: handle no condition argument case for -break-condition
As reported in PR gdb/28076 [1], passing no condition argument to the
-break-condition command (e.g.: "-break-condition 2") should clear the
condition for breakpoint 2, just like CLI's "condition 2", but instead
an error message is returned:
^error,msg="-break-condition: Missing the <number> and/or <expr> argument"
The current implementation of the -break-condition command's argument
handling (
79aabb7308c "gdb/mi: add a '--force' flag to the
'-break-condition' command") was done according to the documentation,
where the condition argument seemed mandatory. However, the
-break-condition command originally (i.e. before the
79aabb7308c
patch) used the CLI's "cond" command, and back then not passing a
condition argument was clearing out the condition. So, this is a
regression in terms of the behavior.
Fix the argument handling of the -break-condition command to allow not
having a condition argument, and also update the document to make the
behavior clear. Also add test cases to test the scenarios which were
previously not covered.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076
GDB Administrator [Mon, 26 Jul 2021 00:00:27 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 25 Jul 2021 00:00:20 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Sat, 24 Jul 2021 06:04:55 +0000 (15:34 +0930)]
Revert: PowerPC: Don't generate unused section symbols
Blindly following x86 broke linux kernel builds.
bfd/
* elf32-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define as true.
* elf64-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Likewise.
gas/
* testsuite/gas/ppc/power4.d: Adjust for section sym change.
* testsuite/gas/ppc/test1elf32.d: Likewise.
* testsuite/gas/ppc/test1elf64.d: Likewise.
ld/
* testsuite/ld-powerpc/tlsexe.r: Adjust for section sym change.
* testsuite/ld-powerpc/tlsexe32.r: Likewise.
* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
* testsuite/ld-powerpc/tlsexeno.r: Likewise.
* testsuite/ld-powerpc/tlsexenors.r: Likewise.
* testsuite/ld-powerpc/tlsexers.r: Likewise.
* testsuite/ld-powerpc/tlsexetoc.r: Likewise.
* testsuite/ld-powerpc/tlsexetocrs.r: Likewise.
* testsuite/ld-powerpc/tlsget.d: Likewise.
* testsuite/ld-powerpc/tlsget.wf: Likewise.
* testsuite/ld-powerpc/tlsget2.d: Likewise.
* testsuite/ld-powerpc/tlsget2.wf: Likewise.
* testsuite/ld-powerpc/tlsso.r: Likewise.
* testsuite/ld-powerpc/tlsso32.r: Likewise.
* testsuite/ld-powerpc/tlstocso.r: Likewise.
Alan Modra [Thu, 22 Jul 2021 12:11:15 +0000 (21:41 +0930)]
Re: ld script expression parsing
Commit
40726f16a8d7 broke references to sections within ADDR(), and
overlays with weird section names.
* ldgram.y (paren_script_name): New rule.
(exp): Use it for ALIGNOF, SIZEOF, ADDR, and LOADADDR. Similarly
ensure script mode parsing for section name in SEGMENT_START.
(overlay_section): Delete unnecessary ldlex_script call. Backup
on a lookahead NAME parsed in expression mode.
* testsuite/ld-elf/overlay.s: Add more sections.
* testsuite/ld-elf/overlay.t: Test '-' in section names.
Frederic Cambus [Wed, 14 Jul 2021 11:14:39 +0000 (13:14 +0200)]
Update the NetBSD system call table to match NetBSD-current.
Generated from sys/sys/syscall.h revision 1.319.
We can safely remove the _lwp_gettid syscall, which was never exposed
in libc and never made it into a release.
gdb/ChangeLog:
2021-07-23 Frederic Cambus <fred@statdns.com>
* syscalls/netbsd.xml: Regenerate.
GDB Administrator [Sat, 24 Jul 2021 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Wed, 14 Jul 2021 01:07:32 +0000 (21:07 -0400)]
gdb/testsuite: test get/set value of unregistered Guile parameter
When creating a parameter in Guile, you have to create it using
make-parameter and then register it with GDB with register-parameter!.
In between, it's still possible (though not documented) to set the
parameter's value. I broke this use case by mistake while writing this
series, so thought it would be good to have a test for it.
I suppose that people could use this "feature" to give their parameter
an initial value, even though make-parameter has an initial-value
parameter for this. Nevertheless, changing this behavior could break
some scripts, which is why I think it's important for it to be tested.
Change-Id: I5b2103e3cec0cfdcccf7ffb00eb05fed8626e66d
Simon Marchi [Wed, 30 Jun 2021 03:10:32 +0000 (23:10 -0400)]
gdb: remove cmd_list_element::function::sfunc
I don't understand what the sfunc function type in
cmd_list_element::function is for. Compared to cmd_simple_func_ftype,
it has an extra cmd_list_element parameter, giving the callback access
to the cmd_list_element for the command being invoked. This allows
registering the same callback with many commands, and alter the behavior
using the cmd_list_element's context.
From the comment in cmd_list_element, it sounds like at some point it
was the callback function type for set and show functions, hence the
"s". But nowadays, it's used for many more commands that need to access
the cmd_list_element object (see add_catch_command for example).
I don't really see the point of having sfunc at all, since do_sfunc is
just a trivial shim that changes the order of the arguments. All
commands using sfunc could just as well set cmd_list_element::func to
their callback directly.
Therefore, remove the sfunc field in cmd_list_element and everything
that goes with it. Rename cmd_const_sfunc_ftype to cmd_func_ftype and
use it for cmd_list_element::func, as well as for the add_setshow
commands.
Change-Id: I1eb96326c9b511c293c76996cea0ebc51c70fac0
Simon Marchi [Wed, 30 Jun 2021 01:47:23 +0000 (21:47 -0400)]
gdb: rename cfunc to simple_func
After browsing the CLI code for quite a while and trying really hard, I
reached the conclusion that I can't give a meaningful explanation of
what "sfunc" and "cfunc" functions are, in cmd_list_element. I don't
see a logic at all. That makes it very difficult to do any kind of
change. Unless somebody can make sense out of all that, I'd like to try
to retro-fit some logic in the cmd_list_element callback function code
so that we can understand what is going on, do some cleanups and add new
features.
The first change is about "cfunc". I can't figure out what the "c" in
cfunc means. It's not const, because there's already "const" in
"cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing
const.. It's not "cmd" or "command", because there's already "cmd" in
"cmd_const_cfunc_ftype".
The "main" command callback, cmd_list_element::func, has three
parameters, whereas cfunc has two. It is missing the cmd_list_element
parameter. So the only reason I see for cfunc to exist is to be a shim
between the three and two parameter versions. Most commands don't need
to receive the cmd_list_element object, so adding it everywhere would be
long and would just add more unnecessary boilerplate. So since this is
the "simple" version of the callback, compared to the "full", I suggest
renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as
everything (like the utility functions) that goes with it.
Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868
Simon Marchi [Mon, 28 Jun 2021 20:32:00 +0000 (16:32 -0400)]
gdb: make inferior::m_terminal an std::string
Same idea as the previous patch, but for m_terminal.
Change-Id: If9367d5db8c976a4336680adca4ea5bc31ab64d2
Simon Marchi [Fri, 25 Jun 2021 22:07:54 +0000 (18:07 -0400)]
gdb: make inferior::m_cwd an std::string
Same idea as the previous patch, but for m_cwd.
To keep things consistent across the board, change get_inferior_cwd as
well, which is shared with GDBserver. So update the related GDBserver
code too.
Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
Simon Marchi [Fri, 25 Jun 2021 21:54:55 +0000 (17:54 -0400)]
gdb: make inferior::m_args an std::string
With the current code, both a NULL pointer and an empty string can mean
"no arguments". We don't need this distinction. Changing to a string
has the advantage that there is now a single state for that (an empty
string), which makes the code a bit simpler in my opinion.
Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced
Simon Marchi [Sat, 26 Jun 2021 01:57:56 +0000 (21:57 -0400)]
gdb: add setter/getter for inferior cwd
Add cwd/set_cwd to the inferior class, remove set_inferior_args.
Keep get_inferior_args, because it is used from fork_inferior, in shared
code. The cwd could eventually be passed as a parameter eventually,
though, I think that would be cleaner.
Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e
Simon Marchi [Wed, 19 May 2021 02:02:47 +0000 (22:02 -0400)]
gdb: add setter/getter for inferior arguments
Add args/set_args to the inferior class, remove the set_inferior_args
and get_inferior_args functions, that would just be wrappers around
them.
Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3
Simon Marchi [Wed, 19 May 2021 01:36:42 +0000 (21:36 -0400)]
gdb: remove inferior::{argc,argv}
There are currently two states that the inferior args can be stored.
The main one is the `args` field, where they are stored as a single
string. The other one is the `argc`/`argv` fields.
This last one is only used for arguments passed in GDB's
command line. And the only outcome is that when get_inferior_args is
called, `argc`/`argv` are serialized into `args`. So really,
`argc`/`argv` is just a staging area before moving the arguments in
`args`.
Simplify this by only keeping the `args` field. Change
set_inferior_args_vector to immediately serialize the arguments into
`args`, work that would be done in get_inferior_args later anyway.
The only time where this work would be "wasted" is when the user passes
some arguments on the command line, but does not end up running the
program. But that just seems unlikely. And it's not that much work.
Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a
Simon Marchi [Tue, 18 May 2021 15:27:43 +0000 (11:27 -0400)]
gdb: un-share set_inferior_cwd declaration
The declaration of set_inferior_cwd is currently shared between gdb and
gdbserver, in gdbsupport/common-inferior.h. It doesn't need to be, as
set_inferior_cwd is not called from common code. Only get_inferior_cwd
needs to.
The motivation for this is that a future patch will change the prototype
of set_inferior_cwd in gdb, and I don't want to change it for gdbserver
unnecessarily. I see this as a good cleanup in any case, to reduce to
just the essential what is shared between GDB and GDBserver.
Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73
Simon Marchi [Thu, 8 Jul 2021 15:24:33 +0000 (11:24 -0400)]
gdb.base/setshow.exp: fix duplicate test name
Fix:
DUPLICATE: gdb.base/setshow.exp: test_setshow_args: show args
by giving some explicit test names.
Change-Id: I2a738d3d3675ab9b45929e71f5aee0ea6bf92072
Simon Marchi [Tue, 6 Jul 2021 17:52:17 +0000 (13:52 -0400)]
gdb.base/setshow.exp: split in procs
Split in multiple procs, one per topic, and start with a fresh GDB in
each. I find it easier to work on a test with multiple smaller
independent test procedures. For example, it's possible to comment all
but one when working on one. It's also easier to add things without
having to think about the impact on existing tests, and vice-versa.
Change-Id: I19691eed8f9bcb975b2eeff7577cac66251bcbe2
Simon Marchi [Tue, 6 Jul 2021 17:31:12 +0000 (13:31 -0400)]
gdb.base/setshow.exp: use save_vars to save/restore gdb_prompt
Using save_vars is a bit better than what we have now, as it ensures the
variable gets restored if the code within it throws an error.
Change-Id: I3bd6836e5b7efb61b078acadff1a1c8182c19a27
Simon Marchi [Tue, 18 May 2021 02:00:15 +0000 (22:00 -0400)]
gdb/testsuite: split gdb.python/py-parameter.exp in procs
Split the file into multiple independent test procs, where each proc
starts with a fresh GDB. I find it easier to understand what a test is
doing when each part of the test is isolated and self-contained. It
makes it easier to comment out some parts of the test while working /
debugging a specific part. It also makes it easier to add new things
(which a subsequent patch will do) without fear of impacting another part
of the test.
Change-Id: I8b4d52ac82b1492d79b679e13914ed177d8a836d
Carl Love [Tue, 20 Jul 2021 23:08:15 +0000 (18:08 -0500)]
Fix for gdb.python/py-breakpoint.exp
Not all systems have hardware breakpoint support. Add a check
to see if the system supports hardware breakpoints.
gdb/testsuite/ChangeLog
* gdb.python/py-breakpoint.exp (test_hardware_breakpoints): Add
check for hardware breakpoint support.
Andrew Burgess [Thu, 22 Jul 2021 13:07:15 +0000 (14:07 +0100)]
gdb/testsuite: don't error when trying to unset last_spawn_tty_name
In spawn_capture_tty_name (lib/gdb.exp) we either set or unset
last_spawn_tty_name depending on whether spawn_out(slave,name) exists
or not.
One situation that might cause spawn_out(slave,name) to not exists is
if the spawn function is called with the argument -leaveopen, which is
how it is called when processes are created as part of a pipeline, the
created process has no tty, instead its output is written to a file
descriptor.
If a pipeline is created consisting of multiple processes then there
will be multiple sequential calls to spawn, all using -leaveopen. The
first of these calls is fine, spawn_out(slave,name) is not set, and so
in spawn_capture_tty_name we unset last_spawn_tty_name. However, on
the second call to spawn, spawn_out(slave,name) is still not set and
so in spawn_capture_tty_name we again try to unset
last_spawn_tty_name, this now throws an error (as last_spawn_tty_name
is already unset).
Fix this issue by using -nocomplain with the call to unset in
spawn_capture_tty_name.
Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1
pass, and 1 unsupported test. After this commit I now see 16 passes
from this test script.
I have also improved the code that used to do this:
if { [info exists spawn_out] } {
set ::last_spawn_tty_name $spawn_out(slave,name)
} else {
...
}
The problem here is that we check for the existence of spawn_out, and
then unconditionally read spawn_out(slave,name). A situation could
arise where some other element of spawn_out is set,
e.g. spawn_out(foo), in which case we would enter the if block and try
to read a non-existent variable. After this commit we now check
specifically for spawn_out(slave,name).
Finally, it is worth noting that before this issue was fixed runtest
itself, or rather the expect process behind runtest, would segfault
while exiting. I haven't looked at all into what the problem is here
that caused expect to crash, as fixing the bug in GDB's testing
scripts made the segfault go away.
Jan Beulich [Fri, 23 Jul 2021 06:03:21 +0000 (08:03 +0200)]
x86: express unduly set rounding control bits in disassembly
While EVEX.L'L are indeed ignored when EVEX.b stands for just SAE,
EVEX.b itself is not ignored when an insn permits neither rounding
control nor SAE.
While changing this aspect of EVEX.b handling, also alter unduly set
embedded broadcast: Don't call BadOp(), screwing up subsequent
disassembly, but emit "{bad}" instead.
GDB Administrator [Fri, 23 Jul 2021 00:00:22 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom de Vries [Thu, 22 Jul 2021 12:36:31 +0000 (14:36 +0200)]
[gdb/testsuite] Fix FAILs due to PR gcc/101575
When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4 we run into:
...
(gdb) print/x s^M
No definition of "s" in current context.^M
(gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s
...
which is caused by "runto defs.adb:20" taking us to defs__struct1IP:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs__struct1IP () at defs.adb:20^M
20 return s.x; -- Set breakpoint marker here.^M
(gdb) print s1'access^M
...
instead of the expected defs.f1:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M
20 return s.x; -- Set breakpoint marker here.^M
...
This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11,
-gdwarf-4] Missing .file <n> directive causes invalid line info".
Fix this by when landing in defs__struct1IP:
- xfailing the runto, and
- issuing a continue to land in defs.f1.
Likewise in a few other test-cases.
Tested on x86_64-linux, with:
- system gcc.
- gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and
unix/gdb:debug_flags=-gdwarf-5.
gdb/testsuite/ChangeLog:
2021-07-22 Tom de Vries <tdevries@suse.de>
* gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575.
* gdb.ada/iwide.exp: Same.
* gdb.ada/pkd_arr_elem.exp: Same.
Jan Beulich [Thu, 22 Jul 2021 11:09:21 +0000 (13:09 +0200)]
x86: drop dq{b,d}_mode
Their sole use is for {,V}EXTRACTPS / {,V}P{EXT,INS}RB respectively; for
consistency also limit use of dqw_mode to Jdqw. 64-bit disassembly
reflecting REX.W / VEX.W is not in line with the assembler's opcode
table having NoRex64 / VexWIG in all respective templates, i.e. assembly
input isn't being honored there either. Obviously the 0FC5 encodings of
{,V}PEXTRW then also need adjustment for consistency reasons.
Jan Beulich [Thu, 22 Jul 2021 11:09:03 +0000 (13:09 +0200)]
x86: drop vex_scalar_w_dq_mode
It has only a single use and can easily be represented by dq_mode
instead. Plus its handling in intel_operand_size() was duplicating
that of vex_vsib_{d,q}_w_dq_mode anyway.
Jan Beulich [Thu, 22 Jul 2021 11:08:39 +0000 (13:08 +0200)]
x86: drop xmm_m{b,w,d,q}_mode
They're effectively redundant with {b,w,d,q}_mode.
Jan Beulich [Thu, 22 Jul 2021 11:08:05 +0000 (13:08 +0200)]
x86: fold duplicate vector register printing code
The bulk of OP_XMM() can be easily reused also for OP_EX(). Break the
shared logic out of the function, and invoke the new helper from both
places.
Jan Beulich [Thu, 22 Jul 2021 11:07:42 +0000 (13:07 +0200)]
x86: drop vex_mode and vex_scalar_mode
These are fully redundant with, respectively, x_mode and scalar_mode.
Jan Beulich [Thu, 22 Jul 2021 11:07:27 +0000 (13:07 +0200)]
x86: correct EVEX.V' handling outside of 64-bit mode
Unlike the high bit of VEX.vvvv / EVEX.vvvv, EVEX.V' is not ignored
outside of 64-bit mode. Oddly enough there already are tests for these
cases, but their expectations were wrong. (This may have been based on
an old SDM version, where the restriction wasn't properly spelled out.)
Jan Beulich [Thu, 22 Jul 2021 11:03:53 +0000 (13:03 +0200)]
x86: fold duplicate code in MOVSXD_Fixup()
There's no need to have two paths printing the "xd" mnemonic suffix.
Jan Beulich [Thu, 22 Jul 2021 11:03:37 +0000 (13:03 +0200)]
x86: fold duplicate register printing code
What so far was OP_E_register() can be easily reused also for OP_G().
Add suitable parameters to the function and move the invocation of
swap_operand() to OP_E(). Adjust MOVSXD's first operand: There never was
a need to use movsxd_mode there, and its use gets in the way of the code
folding.
Jan Beulich [Thu, 22 Jul 2021 11:03:16 +0000 (13:03 +0200)]
x86-64: properly bounds-check %bnd<N> in OP_G()
The restriction to %bnd0-%bnd3 requires to also check REX.R is clear,
just like OP_E_Register() also includes REX.B in its check.
Jan Beulich [Thu, 22 Jul 2021 11:02:54 +0000 (13:02 +0200)]
x86-64: generalize OP_G()'s EVEX.R' handling
EVEX.R' is invalid to be clear not only for mask registers, but also for
GPRs - IOW everything handled in this function.
Jan Beulich [Thu, 22 Jul 2021 11:02:08 +0000 (13:02 +0200)]
x86: correct VCVT{,U}SI2SD rounding mode handling
With EVEX.W clear the instruction doesn't ignore the rounding mode, but
(like for other insns without rounding semantics) EVEX.b set causes #UD.
Hence the handling of EVEX.W needs to be done when processing
evex_rounding_64_mode, not at the decode stages.
Derive a new 64-bit testcase from the 32-bit one to cover the different
EVEX.W treatment in both cases.
Jan Beulich [Thu, 22 Jul 2021 11:01:09 +0000 (13:01 +0200)]
x86: drop OP_Mask()
By moving its vex.r check there it becomes fully redundant with OP_G().
GDB Administrator [Thu, 22 Jul 2021 00:00:29 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom de Vries [Wed, 21 Jul 2021 19:08:07 +0000 (21:08 +0200)]
[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11
When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run
into:
...
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \
(PRMS symtab/25507)
FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \
(PRMS symtab/25507)
...
[ Note that I get the same result with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ]
With gcc-10, I have this trace:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
40 if (t->x != i)
52 && TREE_TYPE (t).z != 1
43 return x;
53 && TREE_TYPE (t).z != 2
43 return x;
54 && TREE_TYPE (t).z != 3)
43 return x;
main () at step-and-next-inline.cc:65
65 return 0;
...
and with gcc-11, I have instead:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
52 && TREE_TYPE (t).z != 1
43 return x;
53 && TREE_TYPE (t).z != 2
43 return x;
54 && TREE_TYPE (t).z != 3)
43 return x;
main () at step-and-next-inline.cc:65
65 return 0;
...
and with clang-10, I have instead:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
52 && TREE_TYPE (t).z != 1
53 && TREE_TYPE (t).z != 2
54 && TREE_TYPE (t).z != 3)
51 if (t != NULL
57 }
main () at step-and-next-inline.cc:65
65 return 0;
...
The test-case tries to verify that we don't step into inlined function
tree_check (lines 40-43) (so, with the clang trace we get that right).
The test-case then tries to kfail the problems when using gcc, but this is
done in such a way that the testing still gets out of sync after a failure.
That is: the "next step 2" check that is supposed to match
"TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1":
...
(gdb) next^M
52 && TREE_TYPE (t).z != 1^M
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2
...
Fix this by issuing extra nexts to arrive at the required lines.
Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10
and clang-12.
gdb/testsuite/ChangeLog:
2021-07-20 Tom de Vries <tdevries@suse.de>
* gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main):
Tag closing brace with comment.
* gdb.cp/step-and-next-inline.h: Update to keep identical with
step-and-next-inline.cc.
* gdb.cp/step-and-next-inline.exp: Issue extra next when required.
Nick Clifton [Wed, 21 Jul 2021 13:37:39 +0000 (14:37 +0100)]
Updated Russian translation for the bfd library
Luca Boccassi [Wed, 21 Jul 2021 13:32:03 +0000 (14:32 +0100)]
Allows linker scripts to set the SEC_READONLY flag.
* ld.texi: Document new output section type.
* ldgram.y: Add new token.
* ldlang.c: Handle the new flag.
* ldlang.h: Add readonly_section to list of section types.
* ldlex.l: Add a new identifier.
* testsuite/ld-scripts/output-section-types.t: New example linker script.
* testsuite/ld-scripts/output-section-types.d: Test driver.
* testsyute/ld-scripts/script.exp: Run the new test.
Tom de Vries [Wed, 21 Jul 2021 12:19:51 +0000 (14:19 +0200)]
[gdb/testsuite] Fix FAILs due to PR gcc/101452
When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
into this regression:
...
(gdb) ptype/o static_member^M
/* offset | size */ type = struct static_member {^M
- static static_member Empty;^M
/* 0 | 4 */ int abc;^M
^M
/* total size (bytes): 4 */^M
}^M
-(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
...
This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
dwarf-5] undefined static member removed by
-feliminate-unused-debug-symbols".
It's not clear yet whether this is a bug or a feature, but work around this in
the test-cases by:
- defining the static member
- adding additional_flags=-fno-eliminate-unused-debug-types.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-07-20 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gcc_major_version): New proc.
* gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
* gdb.cp/templates.exp: Define static member using -DGCC_BUG.
* gdb.cp/m-static.exp: Add
additional_flags=-fno-eliminate-unused-debug-types.
* gdb.cp/pr-574.exp: Same.
* gdb.cp/pr9167.exp: Same.
Tom de Vries [Wed, 21 Jul 2021 12:19:51 +0000 (14:19 +0200)]
[gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11
With gcc-11 we run into:
...
(gdb) print pa_ptr.all^M
That operation is not available on integers of more than 8 bytes.^M
(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991)
...
This is due to PR exp/20991 - "__int128 type support". Mark this and similar
FAILs as KFAIL.
Also mark this FAIL:
....
(gdb) print pa_ptr(3)^M
cannot subscript or call something of type `foo__packed_array_ptr'^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3)
...
as a KFAIL for PR ada/28115 - "Support packed array encoded as
DW_TAG_subrange_type".
Tested on x86_64-linux, with gcc-10 and gcc-11.
gdb/testsuite/ChangeLog:
2021-07-21 Tom de Vries <tdevries@suse.de>
* gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115.
* gdb.ada/exprs.exp: Add KFAILs for PR20991.
* gdb.ada/packed_array_assign.exp: Same.
Alan Modra [Wed, 21 Jul 2021 05:09:29 +0000 (14:39 +0930)]
as_bad_subtract
Many places report errors of the nature "can't resolve a - b".
This provides a utility function to report such errors consistently.
I removed the section reporting and quotes around symbol names while I
was at it. Compare
ifunc-2.s:4: Error: can't resolve `bar1' {.text.1 section} - `foo1' {.text.1 section}
with
ifunc-2.s:4: Error: can't resolve bar1 - foo1
In many cases the section names don't help the user very much in
figuring out what went wrong, and the quotes if present arguably ought
to be placed around the entire expression:
can't resolve `bar1 - foo1'
The patch also tidies some tc_get_reloc functions that leak memory on
error paths.
* write.h (as_bad_subtract): Declare.
* write.c (as_bad_subtract): New function.
(fixup_segment): Use as_bad_subtract.
* config/tc-arc.c (md_apply_fix): Likewise.
* config/tc-avr.c (md_apply_fix, tc_gen_reloc): Likewise.
* config/tc-cris.c (md_apply_fix): Likewise.
* config/tc-d10v.c (md_apply_fix): Likewise.
* config/tc-d30v.c (md_apply_fix): Likewise.
* config/tc-ft32.c (md_apply_fix): Likewise.
* config/tc-h8300.c (tc_gen_reloc): Likewise.
* config/tc-m68hc11.c (md_apply_fix): Likewise.
* config/tc-mmix.c (mmix_frob_file): Likewise.
* config/tc-mn10200.c (tc_gen_reloc): Likewise.
* config/tc-nds32.c (nds32_apply_fix): Likewise.
* config/tc-pru.c (md_apply_fix): Likewise.
* config/tc-riscv.c (md_apply_fix): Likewise.
* config/tc-s12z.c (md_apply_fix): Likewise.
* config/tc-s390.c (md_apply_fix): Likewise.
* config/tc-tilegx.c (md_apply_fix): Likewise.
* config/tc-tilepro.c (md_apply_fix): Likewise.
* config/tc-v850.c (md_apply_fix): Likewise.
* config/tc-vax.c (md_apply_fix): Likewise.
* config/tc-xc16x.c (tc_gen_reloc): Likewise.
* config/tc-xgate.c (md_apply_fix): Likewise.
* config/tc-xstormy16.c (xstormy16_md_apply_fix): Likewise.
* config/tc-xtensa.c (md_apply_fix): Likewise.
* config/tc-z80.c (tc_gen_reloc): Likewise.
* config/tc-spu.c (md_apply_fix): Likewise.
(tc_gen_reloc): Delete dead code. Free memory on error.
* config/tc-cr16.c (tc_gen_reloc): Use as_bad_subtract. Free
on error.
* config/tc-crx.c (tc_gen_reloc): Likewise.
* config/tc-ppc.c (tc_gen_reloc): Likewise.
* testsuite/gas/i386/ifunc-2.l: Adjust to suit changed error message.
* testsuite/gas/mips/lui-2.l: Likewise.
* testsuite/gas/tic6x/reloc-bad-1.l: Likewise.
John Ericson [Sun, 18 Jul 2021 22:32:14 +0000 (18:32 -0400)]
Remove `netbsdpe` support
netbsdpe was deprecated in
c2ce831330e10dab4703094491f80b6b9a5c2289.
Since then, a release has passed (2.37), and it was marked obselete in
5c9cbf07f3f972ecffe13d858010b3179df17b32. Unless I am mistaken, that
means we can now remove support altogether.
All branches in the "active" code are remove, and the target is
additionally marked as obsolete next to the other removed ones for
libbfd and gdb.
Per [1] from the NetBSD toolchain list, PE/COFF support was removed a
decade ago. Furthermore, the sole mention of this target in the binutils
commit history was in 2002. Together, I'm led to believe this target
hasn't seen much attention in quite a while.
[1]: https://mail-index.netbsd.org/tech-toolchain/2021/06/16/msg003996.html
bfd/
* config.bfd: Remove netbsdpe entry.
binutils/
* configure.ac: Remove netbsdpe entry.
* testsuite/lib/binutils-common.exp (is_pecoff_format): Likewise.
* configure: Regenerate.
gas/
* configure.tgt: Remove netbsdpe entry.
gdb/
* configure.tgt: Add netbsdpe to removed targets.
ld/
* configure.tgt: Remove netbsdpe entry.
* testsuite/ld-bootstrap/bootstrap.exp: Likewise.
GDB Administrator [Wed, 21 Jul 2021 00:00:24 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Tue, 20 Jul 2021 09:16:57 +0000 (18:46 +0930)]
PR28106, build of 2.37 fails on FreeBSD and Clang
https://en.cppreference.com/w/cpp/types/NULL says NULL might be
defined as nullptr.
https://en.cppreference.com/w/cpp/language/reinterpret_cast says
reinterpret_cast can't be used on nullptr.
PR gold/28106
PR gold/27815
* gc.h (gc_process_relocs): Use static_cast in Section_id constructor.
Luis Machado [Tue, 20 Jul 2021 10:29:28 +0000 (07:29 -0300)]
Fix printing of non-address types when memory tagging is enabled
When the architecture supports memory tagging, we handle
pointer/reference types in a special way, so we can validate tags and
show mismatches.
Unfortunately, the currently implementation errors out when the user
prints non-address values: composite types, floats, references, member
functions and other things.
Vector registers:
(gdb) p $v0
Value can't be converted to integer.
Non-existent internal variables:
(gdb) p $foo
Value can't be converted to integer.
The same happens for complex types and printing struct/union types.
There are a few problems here.
The first one is that after print_command_1 evaluates the expression
to print, the tag validation code call value_as_address
unconditionally, without making sure we have have a suitable type
where it makes to sense to call it. That results in value_as_address
(if it isn't given a pointer-like type) trying to treat the value as
an integer and convert it to an address, which #1 - doesn't make sense
(i.e., no sense in validating tags after "print 1"), and throws for
non-integer-convertible types. We fix this by making sure we have a
pointer or reference type first, and only if so then proceed to check
if the address-like value has tags.
The second is that we're calling value_as_address even if we have an
optimized out or unavailable value, which throws, because the value's
contents aren't fully accessible/readable. This error currently
escapes out and aborts the print. This case is fixed by checking for
optimized out / unavailable explicitly.
Third, the tag checking process does not gracefully handle exceptions.
If any exception is thrown from the tag validation code, we abort the
print. E.g., the target may fail to access tags via a running thread.
Or the needed /proc files aren't available. Or some other untold
reason. This is a bit too rigid. This commit changes print_command_1
to catch errors, print them, and still continue with the normal
expression printing path instead of erroring out and printing nothing
useful.
With this patch, printing works correctly again:
(gdb) p $v0
$1 = {d = {f = {2.
0546950501119882e-81, 2.
0546950501119882e-81}, u = {
3399988123389603631,
3399988123389603631}, s = {
3399988123389603631,
3399988123389603631}}, s = {f = {1.
59329203e-10, 1.
59329203e-10, 1.
59329203e-10, 1.
59329203e-10}, u = {
791621423,
791621423,
791621423,
791621423}, s = {
791621423,
791621423,
791621423,
791621423}}, h = {bf = {1.592e-10,
1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
62718710765820030520700417840365121327}, s = {
62718710765820030520700417840365121327}}}
(gdb) p $foo
$2 = void
(gdb) p 2 + 2i
$3 = 2 + 2i
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28110
Nelson Chu [Tue, 20 Jul 2021 03:42:09 +0000 (11:42 +0800)]
RISC-V: Minor updates for architecture parser.
* Two add subset functions is redundant. Keep the riscv_add_implicit_subset,
and renamed it to riscv_add_subset. Besides, if the subset is added in order,
then we just add it at the tail of the subset list.
* Removed the "-march:" prefix from the error messages. Since not only the
-march= option will use the parser, but also the architecture elf attributes,
the default architecture setting and linker will use the same parser.
* Use a function, riscv_parse_check_conflicts, to check the conflicts
of extensions, including the rv64e and rv32q.
The rv32emc-elf/rv32i-elf/rv32gc-linux/rv64gc-elf/rv64gc-linux regressions
are tested and passed.
bfd/
* elfxx-riscv.c (riscv_lookup_subset): Check the subset tail list
first. If the subset is added in order, then we can just add it to
the tail without searching the whole list.
(riscv_add_subset): Replaced by riscv_add_implicit_subset.
(riscv_add_implicit_subset): Renamed to riscv_add_subset.
(riscv_parse_add_subset): Updated.
(riscv_parsing_subset_version): Removed the "-march:" prefix from
the error message.
(riscv_parse_prefixed_ext): Likewise.
(riscv_parse_std_ext): Likewise. And move the rv<xlen>e check
to riscv_parse_check_conflicts.
(riscv_parse_check_conflicts): New function used to check conflicts.
(riscv_parse_subset): Updated.
gas/
* testsuite/gas/riscv/march-fail-base-02.l: Updated.
* testsuite/gas/riscv/march-fail-unknown-std.l: Likewise.
GDB Administrator [Tue, 20 Jul 2021 00:00:26 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Wed, 14 Jul 2021 20:31:09 +0000 (16:31 -0400)]
gdb: set current thread in btrace_compute_ftrace_{bts,pt}
As documented in bug 28086, test gdb.btrace/enable-new-thread.exp
started failing with commit
0618ae414979 ("gdb: optimize
all_matching_threads_iterator"):
(gdb) record btrace^M
(gdb) PASS: gdb.btrace/enable-new-thread.exp: record btrace
break 24^M
Breakpoint 2 at 0x555555555175: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.btrace/enable-new-thread.c, line 24.^M
(gdb) continue^M
Continuing.^M
/home/smarchi/src/binutils-gdb/gdb/inferior.c:303: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) FAIL: gdb.btrace/enable-new-thread.exp: continue to breakpoint: cont to bp.1 (GDB internal error)
Note that I only see the failure if GDB is compiled without libipt
support. This is because GDB then makes use BTS instead of PT, so
exercises different code paths.
I think that the commit above just exposed an existing problem. The
stack trace of the internal error is:
#8 0x0000561cb81e404e in internal_error (file=0x561cb83aa2f8 "/home/smarchi/src/binutils-gdb/gdb/inferior.c", line=303, fmt=0x561cb83aa099 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
#9 0x0000561cb7b5c031 in find_inferior_pid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, pid=0) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:303
#10 0x0000561cb7b5c102 in find_inferior_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:317
#11 0x0000561cb7f1d1c3 in find_thread_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:487
#12 0x0000561cb7f1b921 in all_matching_threads_iterator::all_matching_threads_iterator (this=0x7ffc4ee34678, filter_target=0x561cb8aafb60 <the_amd64_linux_nat_target>, filter_ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.c:125
#13 0x0000561cb77bc462 in filtered_iterator<all_matching_threads_iterator, non_exited_thread_filter>::filtered_iterator<process_stratum_target* const&, ptid_t const&> (this=0x7ffc4ee34670) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/filtered-iterator.h:42
#14 0x0000561cb77b97cb in all_non_exited_threads_range::begin (this=0x7ffc4ee34650) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.h:243
#15 0x0000561cb7d8ba30 in record_btrace_target::record_is_replaying (this=0x561cb8aa6250 <record_btrace_ops>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1411
#16 0x0000561cb7d8bb83 in record_btrace_target::xfer_partial (this=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=
140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1437
#17 0x0000561cb7ef73a9 in raw_memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=
140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1504
#18 0x0000561cb7ef77da in memory_xfer_partial_1 (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=
140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1635
#19 0x0000561cb7ef78b5 in memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=
140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1664
#20 0x0000561cb7ef7ba4 in target_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=
140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1721
#21 0x0000561cb7ef8503 in target_read_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=
140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1974
#22 0x0000561cb7ef861f in target_read (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=
140737352774277, len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:2014
#23 0x0000561cb7ef809f in target_read_code (memaddr=
140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:1869
#24 0x0000561cb7937f4d in gdb_disassembler::dis_asm_read_memory (memaddr=
140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:139
#25 0x0000561cb80ab66d in fetch_data (info=0x7ffc4ee34e88, addr=0x7ffc4ee34c59 "g\343N\374\177") at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:194
#26 0x0000561cb80ab7e2 in ckprefix () at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8628
#27 0x0000561cb80adbd8 in print_insn (pc=
140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:9587
#28 0x0000561cb80abe4f in print_insn_i386 (pc=
140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8894
#29 0x0000561cb7744a19 in default_print_insn (memaddr=
140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/arch-utils.c:1029
#30 0x0000561cb7b33067 in i386_print_insn (pc=
140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/i386-tdep.c:4013
#31 0x0000561cb7acd8f4 in gdbarch_print_insn (gdbarch=0x561cbae2fb60, vma=
140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3478
#32 0x0000561cb793a32d in gdb_disassembler::print_insn (this=0x7ffc4ee34e80, memaddr=
140737352774277, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:795
#33 0x0000561cb793a5b0 in gdb_print_insn (gdbarch=0x561cbae2fb60, memaddr=
140737352774277, stream=0x561cb8ac99f8 <null_stream>, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:850
#34 0x0000561cb793a631 in gdb_insn_length (gdbarch=0x561cbae2fb60, addr=
140737352774277) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:859
#35 0x0000561cb77f53f4 in btrace_compute_ftrace_bts (tp=0x561cbba11210, btrace=0x7ffc4ee35188, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1107
#36 0x0000561cb77f55f5 in btrace_compute_ftrace_1 (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1527
#37 0x0000561cb77f5705 in btrace_compute_ftrace (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1560
#38 0x0000561cb77f583b in btrace_add_pc (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1589
#39 0x0000561cb77f5a86 in btrace_enable (tp=0x561cbba11210, conf=0x561cb8ac6878 <record_btrace_conf>) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1629
#40 0x0000561cb7d88d26 in record_btrace_enable_warn (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:294
#41 0x0000561cb7c603dc in std::__invoke_impl<void, void (*&)(thread_info*), thread_info*> (__f=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:60
#42 0x0000561cb7c5e5a6 in std::__invoke_r<void, void (*&)(thread_info*), thread_info*> (__fn=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:153
#43 0x0000561cb7c5dc92 in std::_Function_handler<void (thread_info*), void (*)(thread_info*)>::_M_invoke(std::_Any_data const&, thread_info*&&) (__functor=..., __args#0=@0x7ffc4ee35310: 0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:291
#44 0x0000561cb7f2600f in std::function<void (thread_info*)>::operator()(thread_info*) const (this=0x561cbb6c4878, __args#0=0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:622
#45 0x0000561cb7f23dc8 in gdb::observers::observable<thread_info*>::notify (this=0x561cb8ac5aa0 <gdb::observers::new_thread>, args#0=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
#46 0x0000561cb7f1c436 in add_thread_silent (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:263
#47 0x0000561cb7f1c479 in add_thread_with_info (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., priv=0x561cbb3f7ab0) at /home/smarchi/src/binutils-gdb/gdb/thread.c:272
#48 0x0000561cb7bfa1d0 in record_thread (info=0x561cbb0413a0, tp=0x0, ptid=..., th_p=0x7ffc4ee35610, ti_p=0x7ffc4ee35620) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1380
#49 0x0000561cb7bf7a2a in thread_from_lwp (stopped=0x561cba81db20, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:429
#50 0x0000561cb7bf7ac5 in thread_db_notice_clone (parent=..., child=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:447
#51 0x0000561cb7bdc9a2 in linux_handle_extended_wait (lp=0x561cbae25720, status=4991) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:1981
#52 0x0000561cb7bdf0f3 in linux_nat_filter_event (lwpid=435403, status=198015) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:2920
#53 0x0000561cb7bdfed6 in linux_nat_wait_1 (ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3202
#54 0x0000561cb7be0b68 in linux_nat_target::wait (this=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3440
#55 0x0000561cb7bfa2fc in thread_db_target::wait (this=0x561cb8a9acd0 <the_thread_db_target>, ptid=..., ourstatus=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1412
#56 0x0000561cb7d8e356 in record_btrace_target::wait (this=0x561cb8aa6250 <record_btrace_ops>, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:2547
#57 0x0000561cb7ef996d in target_wait (ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2608
#58 0x0000561cb7b6d297 in do_target_wait_1 (inf=0x561cba6d8780, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3640
#59 0x0000561cb7b6d43e in operator() (__closure=0x7ffc4ee36190, inf=0x561cba6d8780) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3701
#60 0x0000561cb7b6d7b2 in do_target_wait (ecs=0x7ffc4ee36370, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3720
#61 0x0000561cb7b6e67d in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4069
#62 0x0000561cb7b4659b in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:41
#63 0x0000561cb7be25f7 in handle_target_event (error=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4227
#64 0x0000561cb81e4ee2 in handle_file_event (file_ptr=0x561cbae24e10, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:575
#65 0x0000561cb81e5490 in gdb_wait_for_event (block=0) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:701
#66 0x0000561cb81e41be in gdb_do_one_event () at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:212
#67 0x0000561cb7c18096 in start_event_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:421
#68 0x0000561cb7c181e0 in captured_command_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:481
#69 0x0000561cb7c19d7e in captured_main (data=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1353
#70 0x0000561cb7c19df0 in gdb_main (args=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1368
#71 0x0000561cb7693186 in main (argc=11, argv=0x7ffc4ee367b8) at /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
At frame 45, the new_thread observable is fired. At this moment, the
new thread isn't the current thread, inferior_ptid is null_ptid. I
think this is ok: the new_thread observable doesn't give any guarantee
on the global context when observers are invoked. Frame 35,
btrace_compute_ftrace_bts, calls gdb_insn_length. gdb_insn_length
doesn't have a thread_info or other parameter what could indicate where
to read memory from, it implicitly uses the global context
(inferior_ptid).
So we reach the all_non_exited_threads_range in
record_btrace_target::record_is_replaying with a null inferior_ptid.
The previous implemention of all_non_exited_threads_range didn't care,
but the new one does. The problem of calling gdb_insn_length and
ultimately trying to read memory with a null inferior_ptid already
existed, but the commit mentioned above made it visible.
Something between frames 40 (record_btrace_enable_warn) and 35
(btrace_compute_ftrace_bts) needs to be switching the global context to
make TP the current thread. Since btrace_compute_ftrace_bts takes the
thread_info to work with as a parameter, that typically means that it
doesn't require its caller to also set the global current context
(current thread) when calling. If it needs to call other functions
that do require the global current thread to be set, then it needs to
temporarily change the current thread while calling these other
functions. Therefore, switch and restore the current thread in
btrace_compute_ftrace_bts.
By inspection, it looks like btrace_compute_ftrace_pt may also call
functions sensitive to the global context: it installs the
btrace_pt_readmem_callback callback in the PT instruction decoder. When
this function gets called, inferior_ptid must be set appropriately. Add
a switch and restore in there too.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28086
Change-Id: I407fbfe41aab990068bd102491aa3709b0a034b3
GDB Administrator [Mon, 19 Jul 2021 00:00:17 +0000 (00:00 +0000)]
Automatic date update in version.in
Nick Clifton [Sun, 18 Jul 2021 19:10:52 +0000 (20:10 +0100)]
Move pending-obsolesence targets onto the obsolete list.
* config.bfd: Move pending obsoletion targets to obsolete list.
Nick Clifton [Sun, 18 Jul 2021 19:07:23 +0000 (20:07 +0100)]
Update how-to-make-a-release checklist with latest changes from 2.37 release
Michael Krasnyk [Sat, 17 Jul 2021 15:35:56 +0000 (17:35 +0200)]
PR28098 Skip R_*_NONE relocation entries with zero r_sym without counting
PR gold/28098
* reloc.cc (Track_relocs::advance): Skip R_*_NONE relocation entries
with r_sym of zero without counting in advance method.
Simon Marchi [Thu, 15 Jul 2021 19:01:58 +0000 (15:01 -0400)]
gdb: convert nat/x86-dregs.c macros to functions
I'm debugging why GDB crashes on OpenBSD/amd64, turns out it's because
x86_dr_low.get_status is nullptr. It would have been useful to be able
to break on x86_dr_low_get_status, so I thought it would be a good
reason to convert these function-like macros into functions.
Change-Id: Ic200b50ef8455b4697bc518da0fa2bb704cf4721
GDB Administrator [Sun, 18 Jul 2021 00:00:24 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Sun, 4 Jul 2021 19:48:33 +0000 (13:48 -0600)]
Fix file-name handling regression with DWARF index
When run with the gdb-index or debug-names target boards, dup-psym.exp
fails. This came up for me because my new DWARF scanner reuses this
part of the existing index code, and so it registers as a regression.
This is PR symtab/25834.
Looking into this, I found that the DWARF index code here is fairly
different from the psymtab code. I don't think there's a deep reason
for this, and in fact, it seemed to me that the index code could
simply mimic what the psymtab code already does.
That is what this patch implements. The DW_AT_name and DW_AT_comp_dir
are now stored in the quick file names table. This may require
allocating a quick file names table even when DW_AT_stmt_list does not
exist. Then, the functions that work with this data are changed to
use find_source_or_rewrite, just as the psymbol code does. Finally,
line_header::file_full_name is removed, as it is no longer needed.
Currently, the index maintains a hash table of "quick file names".
The hash table uses a deletion function to free the "real name"
components when necessary. There's also a second such function to
implement the forget_cached_source_info method.
This bug fix patch will create a quick file name object even when
there is no DW_AT_stmt_list, meaning that the object won't be entered
in the hash table. So, this patch changes the memory management
approach so that the entries are cleared when the per-BFD object is
destroyed. (A dwarf2_per_cu_data destructor is not introduced,
because we have been avoiding adding a vtable to that class.)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25834
Tom Tromey [Sun, 4 Jul 2021 19:33:12 +0000 (13:33 -0600)]
Check for debug-types in map_symbol_filenames
map_symbol_filenames can skip type units -- in fact I think it has to,
due to the assertion at the top of dw2_get_file_names. This may be a
regression due to the TU/CU unification patch, I did not check.
Tom Tromey [Sun, 4 Jul 2021 19:14:10 +0000 (13:14 -0600)]
Simplify DWARF file name caching
The DWARF index file name caching code only records when a line table
has been read and the reading failed. However, the code would be
simpler if it recorded any attempt, which is what this patch
implements.
Tom Tromey [Sun, 4 Jul 2021 19:26:15 +0000 (13:26 -0600)]
Introduce find_source_or_rewrite
The final bug fix in this series would duplicate the logic in
psymtab_to_fullname, so this patch extracts the body of this function
into a new function.
Tom Tromey [Sun, 4 Jul 2021 18:51:52 +0000 (12:51 -0600)]
Simplify file_and_directory storage management
file_and_directory carries a std::string in case the compilation
directory is computed, but a subsequent patch wants to preserve this
string without also having to maintain the storage for it. So, this
patch arranges for the compilation directory string to be stored in
the per-BFD string bcache instead.
Tom Tromey [Sun, 4 Jul 2021 18:31:18 +0000 (12:31 -0600)]
Pass file_and_directory through DWARF line-decoding code
This patch removes the redundant "comp_unit" parameter from
compute_include_file_name, and arranges to pass a file_and_directory
object from the readers down to this function. It also changes the
partial symtab reader to use find_file_and_directory, rather than
reimplement this functionality by hand.
Tom Tromey [Sun, 4 Jul 2021 18:21:31 +0000 (12:21 -0600)]
Rename and refactor psymtab_include_file_name
In order to fix an index-related regression, I want to use
psymtab_include_file_name in the DWARF index file-handling code. This
patch renames this function and changes it to no longer require a
partial symtab to be passed in. A subsequent patch will further
refactor this code to remove the redundant parameter (which was always
there but is now more obvious).
Sergey Belyashov [Fri, 25 Sep 2020 11:40:42 +0000 (14:40 +0300)]
Add basic Z80 CPU support
Supported ISAs:
- Z80 (all undocumented instructions)
- Z180
- eZ80 (Z80 mode only)
Datasheets:
Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf
Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf
eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt
To debug Z80 programs using GDB you must configure and embed
z80-stub.c to your program (SDCC compiler is required). Or
you may use some simulator with GDB support.
gdb/ChangeLog:
* Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c.
* NEWS: Mention z80 support.
* configure.tgt: Handle z80*.
* features/Makefile (XMLTOC): Add z80.xml.
* features/z80-cpu.xml: New.
* features/z80.c: Generate.
* features/z80.xml: New.
* z80-tdep.c: New file.
* z80-tdep.h: New file.
gdb/stubs/ChangeLog:
* z80-stub.c: New file.
Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9
Simon Marchi [Wed, 14 Jul 2021 16:31:36 +0000 (12:31 -0400)]
gdb: make all_inferiors_safe actually work
The test gdb.threads/fork-plus-threads.exp fails since
08bdefb58b78
("gdb: make inferior_list use intrusive_list"):
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
Looking at the log, we see that we are left with a bunch of inferiors in
the detach-on-fork=off case:
info inferiors^M
Num Description Connection Executable ^M
* 1 <null> <snip>/fork-plus-threads ^M
2 <null> <snip>/fork-plus-threads ^M
3 <null> <snip>/fork-plus-threads ^M
4 <null> <snip>/fork-plus-threads ^M
5 <null> <snip>/fork-plus-threads ^M
6 <null> <snip>/fork-plus-threads ^M
7 <null> <snip>/fork-plus-threads ^M
8 <null> <snip>/fork-plus-threads ^M
9 <null> <snip>/fork-plus-threads ^M
10 <null> <snip>/fork-plus-threads ^M
11 <null> <snip>/fork-plus-threads ^M
(gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left
when we expect to have just one. The problem is prune_inferiors not
pruning inferiors. And this is caused by all_inferiors_safe not
actually iterating on inferiors. The current implementation:
inline all_inferiors_safe_range
all_inferiors_safe ()
{
return {};
}
default-constructs an all_inferiors_safe_range, which default-constructs
an all_inferiors_safe_iterator as its m_begin field, which
default-constructs a all_inferiors_iterator. A default-constructed
all_inferiors_iterator is an end iterator, which means we have
constructed an (end,end) all_inferiors_safe_range.
We actually need to pass down the list on which we want to iterator
(that is the inferior_list global), so that all_inferiors_iterator's
first constructor is chosen. We also pass nullptr as the proc_target
filter. In this case, we don't do any filtering, but if in the future
all_inferiors_safe needed to allow filtering on process target (like
all_inferiors does), we could pass down a process target pointer.
basic_safe_iterator's constructor needs to be changed to allow
constructing the wrapped iterator with multiple arguments, not just one.
With this, gdb.threads/fork-plus-threads.exp is passing once again for
me.
Change-Id: I650552ede596e3590c4b7606ce403690a0278a01
GDB Administrator [Sat, 17 Jul 2021 00:00:23 +0000 (00:00 +0000)]
Automatic date update in version.in
Lancelot SIX [Fri, 16 Jul 2021 22:10:08 +0000 (22:10 +0000)]
gdb: Support stepping out from signal handler on riscv*-linux
Currently, gdb cannot step outside of a signal handler on RISC-V
platforms. This causes multiple failures in gdb.base/sigstep.exp:
FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, step from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, step from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, next from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, next from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: stepi from handleri: leave signal trampoline
FAIL: gdb.base/sigstep.exp: nexti from handleri: leave signal trampoline
=== gdb Summary ===
# of expected passes 587
# of unexpected failures 6
This patch adds support for stepping outside of a signal handler on
riscv*-*-linux*.
Implementation is heavily inspired from mips_linux_syscall_next_pc and
surroundings as advised by Pedro Alves.
After this patch, all tests in gdb.base/sigstep.exp pass.
Build and tested on riscv64-linux-gnu.
Lancelot SIX [Fri, 16 Jul 2021 22:10:07 +0000 (22:10 +0000)]
gdb/testsuite: Declare that riscv*-*-linux* cannot hardware_single_step
Many tests fail in gdb/testsuite/gdb.base/sigstep.exp on
riscv64-linux-gnu. Those tests check that when stepping, if the
debuggee received a signal it should step inside the signal handler.
This feature requires hardware support for single stepping (or at least
kernel support), but none are available on riscv*-linux-gnu hosts, at
the moment at least.
This patch adds RISC-V to the list of configurations that does not
have hardware single step capability, disabling tests relying on such
feature.
Tested on riscv64-linux-gnu.
Tom Tromey [Mon, 21 Jun 2021 20:10:41 +0000 (14:10 -0600)]
Document quick_symbol_functions::expand_symtabs_matching invariant
While working on my series to replace the DWARF psymbol reader, I
noticed that the expand_symtabs_matching has an undocumented
invariant. I think that, if this invariant is not followed, then GDB
will crash. So, this patch documents this in the relevant spots and
introduces some asserts to make it clear.
Regression tested on x86-64 Fedora 32.
Tom Tromey [Fri, 18 Jun 2021 19:08:33 +0000 (13:08 -0600)]
Fix array stride bug
Investigation of using the Python API with an Ada program showed that
an array of dynamic types was not being handled properly. I tracked
this down to an oddity of how array strides are handled.
In gdb, an array stride can be attached to the range type, via the
range_bounds object. However, the stride can also be put into the
array's first field. From create_range_type_with_stride:
else if (bit_stride > 0)
TYPE_FIELD_BITSIZE (result_type, 0) = bit_stride;
It's hard to be sure why this is done, but I would guess a combination
of historical reasons plus a desire (mentioned in a comment somewhere)
to avoid modifying the range type.
This patch fixes the problem by changing type::bit_stride to
understand this convention. It also fixes one spot that reproduces
this logic.
Regression tested on x86-64 Fedora 32.
Giulio Benetti [Fri, 16 Jul 2021 14:03:07 +0000 (15:03 +0100)]
or1k: fix pc-relative relocation against dynamic on PC relative 26 bit relocation.
bfd * elf32-or1k.c (or1k_elf_relocate_section): Use a separate entry
in switch case R_OR1K_INSN_REL_26 where we need to check for
!SYMBOL_CALLS_LOCAL() instead of !SYMBOL_REFERENCES_LOCAL().
Nick Clifton [Fri, 16 Jul 2021 12:57:15 +0000 (13:57 +0100)]
Updated Swedish translation for the binutils sub-directory
GDB Administrator [Fri, 16 Jul 2021 00:00:12 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Thu, 15 Jul 2021 16:13:18 +0000 (10:13 -0600)]
Avoid expression parsing crash with unknown language
PR gdb/28093 points out that gdb crashes when language is set to
"unknown" and expression parsing is attempted. At first I thought
this was a regression due to the expression rewrite, but it turns out
that older versions crash as well.
This patch avoids the crash by changing the default expression parser
to throw an exception. I think this is preferable -- the current
behavior of silently doing nothing does not really make sense.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
Simon Marchi [Mon, 31 May 2021 17:00:32 +0000 (13:00 -0400)]
gdb: pass child_ptid and fork kind to target_ops::follow_fork
This is a small cleanup I think would be nice, that I spotted while
doing the following patch.
gdb/ChangeLog:
* target.h (struct target_ops) <follow_fork>: Add ptid and
target_waitkind parameters.
(target_follow_fork): Likewise.
* target.c (default_follow_fork): Likewise.
(target_follow_fork): Likewise.
* fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise.
* fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise.
* linux-nat.h (class linux_nat_target) <follow_fork>: Likewise.
* linux-nat.c (linux_nat_target::follow_fork): Likewise.
* obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise.
* obsd-nat.c (obsd_nat_target::follow_fork): Likewise.
* remote.c (class remote_target) <follow_fork>: Likewise.
* target-debug.h (target_debug_print_target_waitkind): New.
* target-delegates.c: Re-generate.
Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8
Simon Marchi [Tue, 6 Apr 2021 18:31:50 +0000 (14:31 -0400)]
gdb: call post_create_inferior at end of follow_fork_inferior
GDB doesn't handle well the case of an inferior using the JIT interface
to register JIT-ed objfiles and forking. If an inferior registers a
code object using the JIT interface and then forks, the child process
conceptually has the same code object loaded, so GDB should look it up
and learn about it (it currently doesn't).
To achieve this, I think it would make sense to have the
inferior_created observable called when an inferior is created due to a
fork in follow_fork_inferior. The inferior_created observable is
currently called both after starting a new inferior and after attaching
to an inferior, allowing various sub-components to learn about that new
executing inferior. We can see handling a fork child just like
attaching to it, so any work done when attaching should also be done in
the case of a fork child.
Instead of just calling the inferior_created observable, this patch
makes follow_fork_inferior call the whole post_create_inferior function.
This way, the attach and follow-fork code code paths are more alike.
Given that post_create_inferior calls solib_create_inferior_hook,
follow_fork_inferior doesn't need to do it itself, so those calls to
solib_create_inferior_hook are removed.
One question you may have: why not just call post_create_inferior at the
places where solib_create_inferior_hook is currently called, instead of
after target_follow_fork?
- there's something fishy for the second solib_create_inferior_hook
call site: at this point we have switched the current program space
to the child's, but not the current inferior nor the current thread.
So solib_create_inferior_hook (and everything under, including
check_for_thread_db, for example) is called with inferior 1 as the
current inferior and inferior 2's program space as the current
program space. I think that's wrong, because at this point we are
setting up inferior 2, and all that code relies on the current
inferior. We could just add a switch_to_thread call before it to
make inferior 2 the current one, but there are other problems (see
below).
- solib_create_inferior_hook is currently not called on the
`follow_child && detach_fork` path. I think we need to call it,
because we still get a new inferior in that case (even though we
detach the parent). If we only call post_create_inferior where
solib_create_inferior_hook used to be called, then the JIT
subcomponent doesn't get informed about the new inferior, and that
introduces a failure in the new gdb.base/jit-elf-fork.exp test.
- if we try to put the post_create_inferior just after the
switch_to_thread that was originally at line 662, or just before the
call to target_follow_fork, we introduce a subtle failure in
gdb.threads/fork-thread-pending.exp. What happens then is that
libthread_db gets loaded (somewhere under post_create_inferior)
before the linux-nat target learns about the LWPs (which happens in
linux_nat_target::follow_fork). As a result, the ALL_LWPS loop in
try_thread_db_load_1 doesn't see the child LWP, and the thread-db
target doesn't have the chance to fill in thread_info::priv. A bit
later, when the test does "info threads", and
thread_db_target::pid_to_str is called, the thread-db target doesn't
recognize the thread as one of its own, and delegates the request to
the target below. Because the pid_to_str output is not the expected
one, the test fails.
This tells me that we need to call the process target's follow_fork
first, to make the process target create the necessary LWP and thread
structures. Then, we can call post_create_inferior to let the other
components of GDB do their thing.
But then you may ask: check_for_thread_db is already called today,
somewhere under solib_create_inferior_hook, and that is before
target_follow_fork, why don't we see this ordering problem!? Well,
because of the first bullet point: when check_for_thread_db /
thread_db_load are called, the current inferior is (erroneously)
inferior 1, the parent. Because libthread_db is already loaded for
the parent, thread_db_load early returns. check_for_thread_db later
gets called by linux_nat_target::follow_fork. At this point, the
current inferior is the correct one and the child's LWP exists, so
all is well.
Since we now call post_create_inferior after target_follow_fork, which
calls the inferior_created observable, which calls check_for_thread_db,
I don't think linux_nat_target needs to explicitly call
check_for_thread_db itself, so that is removed.
In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp
test. It makes an inferior register a JIT code object and then fork.
It then verifies that whatever the detach-on-fork and follow-fork-child
parameters are, GDB knows about the JIT code object in all the inferiors
that survive the fork. It verifies that the inferiors can unload that
code object.
There isn't currently a way to get visibility into GDB's idea of the JIT
code objects for each inferior. For the purpose of this test, add the
"maintenance info jit" command. There isn't much we can print about the
JIT code objects except their load address. So the output looks a bit
bare, but it's good enough for the test.
gdb/ChangeLog:
* NEWS: Mention "maint info jit" command.
* infrun.c (follow_fork_inferior): Don't call
solib_create_inferior_hook, call post_create_inferior if a new
inferior was created.
* jit.c (maint_info_jit_cmd): New.
(_initialize_jit): Register new command.
* linux-nat.c (linux_nat_target::follow_fork): Don't call
check_for_thread_db.
* linux-nat.h (check_for_thread_db): Remove declaration.
* linux-thread-db.c (check_thread_signals): Make static.
gdb/doc/ChangeLog:
* gdb.texinfo (Maintenance Commands): Mention "maint info jit".
gdb/testsuite/ChangeLog:
* gdb.base/jit-elf-fork-main.c: New test.
* gdb.base/jit-elf-fork-solib.c: New test.
* gdb.base/jit-elf-fork.exp: New test.
Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c
Libor Bukata [Wed, 14 Jul 2021 13:19:51 +0000 (13:19 +0000)]
[gdb/procfs.c] Fix build failure in find_stop_signal
It fixes a regression caused by commit
1edb66d856c82c389edfd7610143236a68c76846 where thread_info::suspend was
made private.
The public thread_info API has to be used to get stop signal and avoid
build failures.
gdb/ChangeLog:
2021-07-14 Libor Bukata <libor.bukata@oracle.com>
* gdb/procfs.c (find_stop_signal): Use thread_info API.
Change-Id: I53bc57a05cd0eca5f28ef0726d6faeeb306e7904
GDB Administrator [Thu, 15 Jul 2021 00:00:10 +0000 (00:00 +0000)]
Automatic date update in version.in
H.J. Lu [Wed, 14 Jul 2021 21:17:48 +0000 (14:17 -0700)]
x86: Add int1 as one byte opcode 0xf1
Also change the x86 disassembler to disassemble 0xf1 as int1, instead of
icebp.
gas/
PR gas/28088
* testsuite/gas/i386/opcode.s: Add int1.
* testsuite/gas/i386/x86-64-opcode.s: Add int1, int3 and int.
* testsuite/gas/i386/opcode-intel.d: Updated.
* testsuite/gas/i386/opcode-suffix.d: Likewise.
* testsuite/gas/i386/opcode.d: Likewise.
* testsuite/gas/i386/x86-64-opcode.d: Likewise.
opcodes/
PR gas/28088
* i386-dis.c (dis386): Replace icebp with int1.
* i386-opc.tbl: Add int1.
* i386-tbl.h: Regenerate.
Alan Modra [Sat, 10 Jul 2021 06:28:44 +0000 (15:58 +0930)]
gas: default TC_VALIDATE_FIX_SUB to 0
gas/write.c provides a fallback TC_VALIDATE_FIX_SUB define that can be
a problem for some targets, the problem being that a non-zero
definition of TC_VALIDATE_FIX_SUB says that some uses of fx_subsy are
OK, in effect that the target will handle fx_subsy in md_apply_fix
and/or tc_gen_reloc. A lot of targets don't have the necessary
md_apply_fix and tc_gen_reloc support. So a safer default is to
disallow fx_subsy by default.
I've had a good look over target usage of fx_subsy, and think I've
caught all the cases where targets need TC_VALIDATE_FIX_SUB. Possible
failures would be limited to alpha, microblaze, ppc and s390 (the
targets that define UNDEFINED_DIFFERENCE_OK), or targets that generate
fixups with BFD_RELOC_GPREL32/16 and use a syntax explicitly showing
a difference expression.
* write.c (TC_VALIDATE_FIX_SUB): Default to 0.
* config/tc-hppa.h (TC_VALIDATE_FIX_SUB): Define.
* config/tc-microblaze.h (TC_VALIDATE_FIX_SUB): Define.
* config/tc-alpha.h (TC_VALIDATE_FIX_SUB): Define for ECOFF.
* config/tc-ppc.h (TC_VALIDATE_FIX_SUB): Don't define for ELF.
Do define for XCOFF.