Commit Graph

108276 Commits

Author SHA1 Message Date
Andrew Burgess
288712bbac gdb/remote: use scoped_restore to control starting_up flag
This commit makes use of a scoped_restore object to control the
remote_state::starting_up flag within the remote_target::start_remote
method.

Ideally I would have liked to create the scoped_restore inside
start_remote and just leave the restore in place until the end of the
scope, however, I'm worried that doing this would change the behaviour
of GDB.  Specifically, in start_remote, the following code is executed
once the starting_up flag has been restored to its previous value:

  if (breakpoints_should_be_inserted_now ())
    insert_breakpoints ();

I think (but am not 100% sure) that calling install_breakpoints could
end up back inside remote_target::can_download_tracepoint, which does
check the value of remote_state::starting_up.  And so, I'm concerned
that leaving the scoped_restore in place until the end of start_remote
will cause a possible change in behaviour.

To avoid this, and to leave things as close to the current behaviour
as possible, I've split remote_target::start_remote into two, there's
the main function body which moves into remote_target::start_remote_1,
this function uses the scoped_restore to change the ::starting_up
flag, then there's the old remote_target::start_remote, which now just
calls ::start_remote_1, and then does the insert_breakpoints call.

There should be no user visible changes after this commit, unless
there's a situation where the ::starting_up flag could previously have
been left set, if this was the case, then this situation should no
longer be possible.
2021-12-01 10:07:14 +00:00
Simon Marchi
6976b5b961 gdb.base/corefile-buildid.exp: fix DUPLICATEs when failing to generate a core file
When my system isn't properly configured to generate core files in the
local directory, I see these DUPLICATEs:

    DUPLICATE: gdb.base/corefile-buildid.exp: could not generate core file

Fix that by having a single with_test_prefix around that message and
what follows.

Change-Id: I4ac245fcce1c666db56e3bad3582aa17f183dcba
2021-11-30 21:05:26 -05:00
Mike Frysinger
360ef3b94a gold: enable silent build rules 2021-11-30 19:41:31 -05:00
GDB Administrator
b70f818d7d Automatic date update in version.in 2021-12-01 00:00:09 +00:00
Carl Love
5de7960f76 gdb: Powerpc fix gdb.multi/multi-arch-exec.exp test
The expect file has a procedure append_arch_options which sets march based
the istarget.  The current if / else statement does not check for
powerpc64.  The else statement is hit which sets march to -m32.  This
results in compilation errors on 64-bit PowerPC.

This patch adds an if statement to check for powerpc64 and if true sets mach
to -m64.

The patch was tested on a Power 10 system.  No compile errors were generated.
The test completes with 1 expected pass and no failures.
2021-11-30 16:01:36 -06:00
Mike Frysinger
10e1e79e58 binutils: regenerate Makefile.in after doc/ changes 2021-11-30 14:02:05 -05:00
Roland McGrath
6e2acee1b5 Fix missing build dependency for binutils man pages
binutils/
	* doc/local.mk: Give each man page target its missing dependency on
	doc/$(am__dirstamp).
2021-11-30 10:16:45 -08:00
Richard Sandiford
e9dac4f012 aarch64: Add missing system registers [PR27145]
This patch adds support for various system registers, up to Armv8.7-A.
This includes all the registers that were mentioned in the PR and that
hadn't become supported since.

opcodes/
	PR aarch64/27145
	* aarch64-opc.c (SR_V8_4): Remove duplicate definition.
	(SR_V8_6, SR_V8_7, SR_GIC, SR_AMU): New macros.
	(aarch64_sys_regs): Add missing entries (up to Armv8.7-A).

gas/
	PR aarch64/27145
	* testsuite/gas/aarch64/sysreg-8.s,
	* testsuite/gas/aarch64/sysreg-8.d,
	* testsuite/gas/aarch64/illegal-sysreg-8.s,
	* testsuite/gas/aarch64/illegal-sysreg-8.d,
	* testsuite/gas/aarch64/illegal-sysreg-8.l,
	* testsuite/gas/aarch64/illegal-sysreg-8b.s,
	* testsuite/gas/aarch64/illegal-sysreg-8b.d,
	* testsuite/gas/aarch64/illegal-sysreg-8b.l: New tests.
	* testsuite/gas/aarch64/sysreg.s: Change system register numbers
	to ones that are still unallocated.
	* testsuite/gas/aarch64/sysreg.d: Update accordingly.
2021-11-30 17:50:25 +00:00
Richard Sandiford
3de8c82a4a aarch64: Make LOR registers conditional on +lor
We have a +lor feature flag for the Limited Ordering Regions
extension, but the associated registers didn't use it.

opcodes/
	* aarch64-opc.c (SR_LOR): New macro.
	(aarch64_sys_regs): Use it for lorc_el1, lorea_el1, lorn_el1 and
	lorsa_el1.

gas/
	* testsuite/gas/aarch64/sysreg-7.s: Enable +lor.
	* testsuite/gas/aarch64/illegal-sysreg-7.s: Test for LOR registers
	without +lor.
	* testsuite/gas/aarch64/illegal-sysreg-7.d: Update accordingly.
	* testsuite/gas/aarch64/illegal-sysreg-7.l: Likewise.
2021-11-30 17:50:25 +00:00
Richard Sandiford
ed96bdcba5 aarch64: Remove ZIDR_EL1
ZIDR_EL1 was part of an early version of SVE, but didn't make
it to the final release.

opcodes/
	* aarch64-opc.c (aarch64_sys_regs): Remove zidr_el1 entry.

gas/
	* testsuite/gas/aarch64/sve-sysreg.s: Remove zidr_el1.
	* testsuite/gas/aarch64/sve-sysreg.d: Update accordingly.
	* testsuite/gas/aarch64/sve-sysreg-invalid.l: Likewise.
2021-11-30 17:50:25 +00:00
Richard Sandiford
b009f915c9 aarch64: Allow writes to MFAR_EL3
MFAR_EL3 is a read/write register, but was incorrectly marked as
read-only
[https://developer.arm.com/documentation/ddi0601/2021-09/AArch64-Registers/MFAR-EL3--PA-Fault-Address-Register?lang=en]

opcodes/
	* aarch64-opc.c (aarch64_sys_regs): Mark mfar_el3 as read-write.

gas/
	* testsuite/gas/aarch64/rme.s: Test writing to mfar_el3.
	* testsuite/gas/aarch64/rme.d: Update accordingly.
	* testsuite/gas/aarch64/rme-invalid.s: Delete.
	* testsuite/gas/aarch64/rme-invalid.l: Likewise.
	* testsuite/gas/aarch64/rme-invalid.d: Likewise.
2021-11-30 17:50:24 +00:00
Richard Sandiford
1864b6578b aarch64: Mark PMSIDR_EL1 as read-only
We were incorrectly allowing writes to PMSIDR_EL1, which is
a read-only register.
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/PMSIDR-EL1--Sampling-Profiling-ID-Register?lang=en]

opcodes/
	* aarch64-opc.c (aarch64_sys_regs): Make pmsidr_el1 as F_REG_READ.

gas/
	* testsuite/gas/aarch64/msr.s: Remove write to pmsidr_el1.
	* testsuite/gas/aarch64/msr.d: Update accordingly.
	* testsuite/gas/aarch64/illegal-sysreg-2.s,
	* testsuite/gas/aarch64/illegal-sysreg-2.d,
	* testsuite/gas/aarch64/illegal-sysreg-2.l: New test.
2021-11-30 17:50:24 +00:00
Richard Sandiford
31a8056f2f aarch64: Remove duplicate system register entries
There is a lot of overlap between the ETM and ETE system registers,
so some registers were listed twice.

Already tested by etm.[sd] and ete.[sd].

opcodes/
	* aarch64-opc.c (aarch64_sys_regs): Combine ETE and ETM blocks
	and remove redundant entries.

gas/
	* testsuite/gas/aarch64/etm.s: Remove duplicated test.
	* testsuite/gas/aarch64/etm.d: Update accordingly.
2021-11-30 17:50:24 +00:00
Richard Sandiford
2dd3146b4f aarch64: Check for register aliases before mnemonics
Previously we would not accept:

	A .req B

if A happened to be the name of an instruction.  Adding new
instructions could therefore invalidate existing register aliases.

I noticed this with a test that used "zero" as a register alias
for "xzr", where "zero" is now also the name of an SME instruction.
I don't have any evidence that "real" code is doing this, but it
seems at least plausible.

This patch switches things so that we check for register aliases
first.  It might slow down parsing slightly, but the difference
is unlikely to be noticeable.

Things like:

	b	.req + 0

still work, since create_register_alias checks for " .req ",
and with the input scrubber, we'll only keep whitespace after
.req if it's followed by another name.  If there's some valid
expression that I haven't thought about that is scrubbed to
" .req ", users could avoid the ambiguity by wrapping .req
in parentheses.

The new test for invalid aliases already passed.  I just wanted
something to exercise the !dot condition.

I can't find a way of exercising the (existing) p == base condition,
but I'm not brave enough to say that it can never happen.  If it does
happen, get_mnemonic_name would return an empty string.

gas/
	* config/tc-aarch64.c (opcode_lookup): Move mnemonic extraction
	code to...
	(md_assemble): ...here.  Check for register aliases first.
	* testsuite/gas/aarch64/register_aliases.d,
	testsuite/gas/aarch64/register_aliases.s: Test for a register
	alias called "zero".
	* testsuite/gas/aarch64/register_aliases_invalid.d,
	testsuite/gas/aarch64/register_aliases_invalid.l,
	testsuite/gas/aarch64/register_aliases_invalid.s: New test.
2021-11-30 17:50:24 +00:00
Andrew Burgess
90fe61ced1 gdb/python: don't use the 'p' format for parsing args
When running the gdb.python/py-arch.exp tests on a GDB built
against Python 2 I ran into some errors.  The problem is that this
test script exercises the gdb.Architecture.integer_type method, and
this method uses 'p' as an argument format specifier in a call to
gdb_PyArg_ParseTupleAndKeywords.

Unfortunately this specified was only added in Python 3.3, so will
cause an error for earlier versions of Python.

This commit switches to use the 'O' specifier to collect a PyObject,
and then uses PyObject_IsTrue to convert the object to a boolean.

An earlier version of this patch incorrectly switched from using 'p'
to use 'i', however, it was pointed out during review that this would
cause some changes in behaviour, for example both of these will work
with 'p', but not with 'i':

  gdb.selected_inferior().architecture().integer_type(32, None)
  gdb.selected_inferior().architecture().integer_type(32, "foo")

The new approach of using 'O' works fine with these cases.  I've added
some new tests to cover both of the above.

There should be no user visible changes after this commit.
2021-11-30 15:46:09 +00:00
Tom de Vries
d0b39fc485 [gdb/testsuite] Fix gdb.base/style.exp with stub-termcap
When running test-case gdb.base/style.exp with a gdb build using
stub-termcap.c, we run into:
...
(gdb) PASS: gdb.base/style.exp: all styles enabled: frame when width=20
^M<et width 30^M
(gdb) FAIL: gdb.base/style.exp: all styles enabled: set width 30
...

The problem is that we're trying to issue the command "set width 30" while
width is set to 20, which causes horizontal scrolling.

Fix this by resetting the width to 0 before issuing the "set width 30"
command.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24582
2021-11-30 15:37:01 +01:00
Nick Clifton
9745b5a753 Use dwarf_vma type for offsets, ranges and section sizes in DWARF decoder.
* dwarf.c (find_debug_info_for_offset): Use dwarf_vma type for
	offsets, sizes and ranges.
	(display_loc_list): Likewise.  Also use print_dwarf_vma to print
	the offset.
	(display_loclists_list): Likewise.
	(display_loc_list_dwo): Likewise.
	(display_debug_str): Likewise.
	(display_debug_aranges): Likewise.
	(display_debug_ranges_list): Likewise.
	(display_debug_rnglists_list): Likewise.
	(display_debug_ranges): Likewise.
2021-11-30 13:17:49 +00:00
Nick Clifton
44b357eb9a ld: pru: Add pru_irq_map output section
* scripttempl/pru.sc (.pru_irq_map): Define output section.
	* testsuite/ld-pru/pru_irq_map-1.d: New test.
	* testsuite/ld-pru/pru_irq_map-2.d: New test.
	* testsuite/ld-pru/pru_irq_map.s: New test.
2021-11-30 13:11:57 +00:00
Andrew Burgess
ae9aa73767 gdb/testsuite: check the python module is available before using it
The gdb.python/py-inferior-leak.exp test makes use of the tracemalloc
module.  When running the Python tests with a GDB built against Python
2 I ran into a test failure due to the tracemalloc module not being
available.

This commit adds a new helper function to lib/gdb-python.exp that
checks if a named module is available.  Using this we can then skip
the py-inferior-leak.exp test when the tracemalloc module is not
available.
2021-11-30 13:05:57 +00:00
Andrew Burgess
1527fe5f58 gdb: fix disassembler regressions for 32-bit arm
After this commit:

  commit 76b43c9b5c
  Date:   Tue Oct 5 15:10:12 2021 +0100

      gdb: improve error reporting from the disassembler

We started seeing FAILs in the gdb.base/all-architectures*.exp tests,
when running on a 32-bit ARM target, though I suspect running on any
target that compiles such that bfd_vma is 32-bits would also trigger
the failures.

The problem is that the test is expected GDB's disassembler to print
an error like this:

  Cannot access memory at address 0x0

However, after the above commit we see an error like:

  unknown disassembler error (error = -1)

The reason for this is this code in opcodes/i386-dis.c (in the
print_insn function):

  if (address_mode == mode_64bit && sizeof (bfd_vma) < 8)
    {
      (*info->fprintf_func) (info->stream,
                             _("64-bit address is disabled"));
      return -1;
    }

This code effectively disallows us from ever disassembling 64-bit x86
code if we compiled GDB with a 32-bit bfd_vma.  Notice we return
-1 (indicating a failure to disassemble), but never call the
memory_error_func callback.

Prior to the above commit GDB, when it received the -1 return value
would assume that a memory error had occurred and just print whatever
value happened to be in the memory error address variable, the default
value of 0 just happened to be fine because the test had asked GDB to
do this 'disassemble 0x0,+4'.

If we instead change the test to do 'disassemble 0x100,+4' then GDB
would (previously) have still reported:

  Cannot access memory at address 0x0

which makes far less sense.

In this commit I propose to fix this issue by changing the test to
accept either the "Cannot access memory ..." string, or the newer
"unknown disassembler error ..." string.  With this change done the
test now passes.

However, there is one weakness with this strategy; if GDB broke such
that we _always_ reported "unknown disassembler error ..." we would
never notice.  This clearly would be bad.  To avoid this issue I have
adjusted the all-architectures*.exp tests so that, when we disassemble
for the default architecture (the one selected by "auto") we _only_
expect to get the "Cannot access memory ..." error string.

[ Note: In an ideal world we should be able to disassemble any
  architecture at all times.  There's no reason why the 64-bit x86
  disassembler requires a 64-bit bfd_vma, other than the code happens
  to be written that way.  We could rewrite the disassemble to not
  have this requirement, but, I don't plan to do that any time soon. ]

Further, I have changed the all-architectures*.exp test so that we now
disassemble at address 0x100, this should avoid us being able to pass
by printing a default address of 0x0.  I did originally change the
address we disassembled at to 0x4, however, some architectures,
e.g. ia64, have a default instruction alignment that is greater than
4, so would still round down to 0x0.  I could have just picked 0x8 as
an address, but I figured that 0x100 was likely to satisfy most
architectures alignment requirements.
2021-11-30 12:20:09 +00:00
Andrew Burgess
24b2de7b77 gdb/python: add gdb.RemoteTargetConnection.send_packet
This commits adds a new sub-class of gdb.TargetConnection,
gdb.RemoteTargetConnection.  This sub-class is created for all
'remote' and 'extended-remote' targets.

This new sub-class has one additional method over its base class,
'send_packet'.  This new method is equivalent to the 'maint
packet' CLI command, it allows a custom packet to be sent to a remote
target.

The outgoing packet can either be a bytes object, or a Unicode string,
so long as the Unicode string contains only ASCII characters.

The result of calling RemoteTargetConnection.send_packet is a bytes
object containing the reply that came from the remote.
2021-11-30 12:10:40 +00:00
Andrew Burgess
e5b176f25f gdb: make packet_command function available outside remote.c
In a later commit I will add a Python API to access the 'maint packet'
functionality, that is, sending a user specified packet to the target.

To make implementing this easier, this commit refactors how this
command is currently implemented so that the packet_command function
is now global.

The new global send_remote_packet function takes an object that is an
implementation of an abstract interface.  Two functions within this
interface are then called, one just before a packet is sent to the
remote target, and one when the reply has been received from the
remote target.  Using an interface object in this way allows (1) for
the error checking to be done before the first callback is made, this
means we only print out what packet it being sent once we know we are
going to actually send it, and (2) we don't need to make a copy of the
reply if all we want to do is print it.

One user visible changes after this commit are the error
messages, which I've changed to be less 'maint packet' command
focused, this will make them (I hope) better for when
send_remote_packet can be called from Python code.

So:      "command can only be used with remote target"
Becomes: "packets can only be sent to a remote target"

And:     "remote-packet command requires packet text as argument"
Becomes: "a remote packet must not be empty"

Additionally, in this commit, I've added support for packet replies
that contain binary data.  Before this commit, the code that printed
the reply treated the reply as a C string, it assumed that the string
only contained printable characters, and had a null character only at
the end.

One way to show the problem with this is if we try to read the auxv
data from a remote target, the auxv data is binary, so, before this
commit:

  (gdb) target remote :54321
  ...
  (gdb) maint packet qXfer:auxv:read::0,1000
  sending: "qXfer:auxv:read::0,1000"
  received: "l!"
  (gdb)

And after this commit:

  (gdb) target remote :54321
  ...
  (gdb) maint packet qXfer:auxv:read::0,1000
  sending: "qXfer:auxv:read::0,1000"
  received: "l!\x00\x00\x00\x00\x00\x00\x00\x00\xf0\xfc\xf7\xff\x7f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xf>
  (gdb)

The binary contents of the reply are now printed as escaped hex.
2021-11-30 12:10:40 +00:00
Andrew Burgess
0e3b7c25ee gdb/python: introduce gdb.TargetConnection object type
This commit adds a new object type gdb.TargetConnection.  This new
type represents a connection within GDB (a connection as displayed by
'info connections').

There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.

Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).

Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.

The gdb.TargetConnection has an 'is_valid()' method.  A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).

The gdb.TargetConnection has the following read-only properties:

  'num': The number for this connection,

  'type': e.g. 'native', 'remote', 'sim', etc

  'description': The longer description as seen in the 'info
                 connections' command output.

  'details': A string or None.  Extra details for the connection, for
             example, a remote connection's details might be
             'hostname:port'.
2021-11-30 12:10:33 +00:00
Nelson Chu
abfdb09f01 RISC-V: The vtype immediate with more than the defined 8 bits are preserved.
According the rvv spec,
https://github.com/riscv/riscv-v-spec/blob/master/vtype-format.adoc

The bits of vtype immediate from 8 to (xlen - 1) should be reserved.
Therefore, we should also dump the vtype immediate as numbers, when
they are set over 8-bits.  I think this is a bug that we used to support
vediv extension and use the bit 8 and 9 of vtype, but forgot to update
the behavior when removing the vediv.

Consider the testcases,

vsetvli  a0, a1,  0x700    # the reserved bit 10, 9 and 8 are used.
vsetvli  a0, a1,  0x400    # the reserved bit 10 is used.
vsetvli  a0, a1,  0x300    # the reserved bit 9 and 8 are used.
vsetvli  a0, a1,  0x100    # the reserved bit 8 is used.
vsetivli a0, 0xb, 0x300    # the reserved bit 9 and 8 are used.
vsetivli a0, 0xb, 0x100    # the reserved bit 8 is used.

The original objdump shows the following result,

0000000000000000 <.text>:
   0:   7005f557                vsetvli a0,a1,1792
   4:   4005f557                vsetvli a0,a1,1024
   8:   3005f557                vsetvli a0,a1,e8,m1,tu,mu
   c:   1005f557                vsetvli a0,a1,e8,m1,tu,mu
  10:   f005f557                vsetivli        a0,11,e8,m1,tu,mu
  14:   d005f557                vsetivli        a0,11,e8,m1,tu,mu

But in fact the correct result should be,

0000000000000000 <.text>:
   0:   7005f557                vsetvli a0,a1,1792
   4:   4005f557                vsetvli a0,a1,1024
   8:   3005f557                vsetvli a0,a1,768
   c:   1005f557                vsetvli a0,a1,256
  10:   f005f557                vsetivli        a0,11,768
  14:   d005f557                vsetivli        a0,11,256

gas/
	* testsuite/gas/riscv/vector-insns.d: Added testcases to
	test the reserved bit 8 to (xlen-1) of vtype.
	* testsuite/gas/riscv/vector-insns.s: Likewise.
include/
	* opcode/riscv.h: Removed OP_MASK_VTYPE_RES and OP_SH_VTYPE_RES,
	since they are different for operand Vc and Vb.
opcodes/
	* riscv-dis.c (print_insn_args): Updated imm_vtype_res to
	extract the reserved immediate of vtype correctly.
2021-11-30 19:03:48 +08:00
Nelson Chu
ee083a9e7c RISC-V: Dump vset[i]vli immediate as numbers once vsew or vlmul is reserved.
Consider the following case,

vsetvli  a0, a1,  0x4           # unrecognized vlmul
vsetvli  a0, a1,  0x20          # unrecognized vsew
vsetivli a0, 0xb, 0x4           # unrecognized vlmul
vsetivli a0, 0xb, 0x20          # unrecognized vsew

For the current dis-assembler, we get the result,

0000000000000000 <.text>:
   0:   0045f557                vsetvli a0,a1,e8,(null),tu,mu
   4:   0205f557                vsetvli a0,a1,e128,m1,tu,mu
   8:   c045f557                vsetivli        a0,11,e8,(null),tu,mu
   c:   c205f557                vsetivli        a0,11,e128,m1,tu,mu

The vsew e128 and vlmul (null) are preserved according to the spec,
so dump these fields looks wrong.  Consider that we are used to dump
the unrecognized csr as csr numbers directly, we should also dump
the whole vset[i]vli immediates as numbers, once the vsew or vlmul
is reserved.  Therefore, following is what I expected,

0000000000000000 <.text>:
   0:   0045f557                vsetvli a0,a1,4
   4:   0205f557                vsetvli a0,a1,32
   8:   c045f557                vsetivli        a0,11,4
   c:   c205f557                vsetivli        a0,11,32

gas/
	* testsuite/gas/riscv/vector-insns.d: Rewrite the vset[i]vli
	testcases since we should dump the immediate as numbers once
	the vsew or vlmul is reserved.
	* testsuite/gas/riscv/vector-insns.s: Likewise.
opcodes/
	* riscv-dis.c (print_insn_args): The reserved vsew and vlmul
	are NULL string in the riscv_vsew and riscv_vlmul, so dump the
	whole imm as numbers once one of them is NULL.
	* riscv-opc.c (riscv_vsew): Set the reserved vsew to NULL.
	(riscv_vlmul): Set the reserved vlmul to NULL.
2021-11-30 15:14:31 +08:00
Mike Frysinger
ae8e528122 zlib: enable silent build rules 2021-11-29 20:28:29 -05:00
Mike Frysinger
48b5f33ab1 ld: enable silent build rules
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-29 20:28:29 -05:00
Mike Frysinger
c7d1b270c2 libctf: enable silent build rules
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-29 20:28:29 -05:00
Mike Frysinger
c7a92c872b gprof: enable silent build rules
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-29 20:28:29 -05:00
Mike Frysinger
45c06bb712 binutils: merge doc subdir up a level
This avoids a recursive make into the doc subdir and speeds up the
build slightly.  It also allows for more parallelism.
2021-11-29 20:26:26 -05:00
Mike Frysinger
d8bbdb9dd5 binutils: enable silent build rules
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-29 20:26:26 -05:00
Mike Frysinger
75ea503ef0 bfd: enable silent build rules
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-29 20:26:26 -05:00
Mike Frysinger
13678b206f opcodes: enable silent build rules
Also add $(AM_V_xxx) to various manual rules in here.
2021-11-29 20:26:26 -05:00
GDB Administrator
9832d223d6 Automatic date update in version.in 2021-11-30 00:00:11 +00:00
Tom Tromey
1c0e43634c Allow DW_ATE_UTF for Rust characters
The Rust compiler plans to change the encoding of a Rust 'char' type
to use DW_ATE_UTF.  You can see the discussion here:

    https://github.com/rust-lang/rust/pull/89887

However, this fails in gdb.  I looked into this, and it turns out that
the handling of DW_ATE_UTF is currently fairly specific to C++.  In
particular, the code here assumes the C++ type names, and it creates
an integer type.

This comes from commit 53e710acd ("GDB thinks char16_t and char32_t
are signed in C++").  The message says:

    Both places need fixing.  But since I couldn't tell why dwarf2read.c
    needs to create a new type, I've made it use the per-arch built-in
    types instead, so that the types are only created once per arch
    instead of once per objfile.  That seems to work fine.

... which is fine, but it seems to me that it's also correct to make a
new character type; and this approach is better because it preserves
the type name as well.  This does use more memory, but first we
shouldn't be too concerned about the memory use of types coming from
debuginfo; and second, if we are, we should implement type interning
anyway.

Changing this code to use a character type revealed a couple of
oddities in the C/C++ handling of TYPE_CODE_CHAR.  This patch fixes
these as well.

I filed PR rust/28637 for this issue, so that this patch can be
backported to the gdb 11 branch.
2021-11-29 13:24:32 -07:00
Aaron Merey
b9db26b4c4 [PR gdb/27026] CTRL-C is ignored when debug info is downloaded
During debuginfod downloads, ctrl-c should result in the download
being cancelled and skipped.  However in some cases, ctrl-c fails to
get delivered to gdb during downloading.  This can result in downloads
being unskippable.

Fix this by ensuring that target_terminal::ours is in effect for the
duration of each download.

Co-authored-by: Tom de Vries <tdevries@suse.de>
https://sourceware.org/bugzilla/show_bug.cgi?id=27026#c3
2021-11-29 14:58:38 -05:00
Nick Clifton
584294c406 strings: Replace references to -u option with references to -U.
PR 28632
2021-11-29 15:37:24 +00:00
Tom de Vries
49fa1332a6 [gdb/symtab] Fix segfault in search_one_symtab
PR28539 describes a segfault in lambda function search_one_symtab due to
psymbol_functions::expand_symtabs_matching calling expansion_notify with a
nullptr symtab:
...
          struct compunit_symtab *symtab =
            psymtab_to_symtab (objfile, ps);

          if (expansion_notify != NULL)
            if (!expansion_notify (symtab))
              return false;
...

This happens as follows.  The partial symtab ps is a dwarf2_include_psymtab
for some header file:
...
(gdb) p ps.filename
$5 = 0x64fcf80 "/usr/include/c++/11/bits/stl_construct.h"
...

The includer of ps is a shared symtab for a partial unit, with as user:
...
(gdb) p ps.includer().user.filename
$11 = 0x64fc9f0 \
  "/usr/src/debug/llvm13-13.0.0-1.2.x86_64/tools/clang/lib/AST/Decl.cpp"
...

The call to psymtab_to_symtab expands the Decl.cpp symtab (and consequently
the shared symtab), but returns nullptr because:
...
struct dwarf2_include_psymtab : public partial_symtab
{
  ...
  compunit_symtab *get_compunit_symtab (struct objfile *objfile) const override
  {
    return nullptr;
  }
...

Fix this by returning the Decl.cpp symtab instead, which fixes the segfault
in the PR.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28539
2021-11-29 16:19:16 +01:00
Nick Clifton
8fee99c3c8 Update description of string's -n option.
PR 28632
	* strings.c (usage): Update desciption of -n option.
	* doc/binutils.texi: Likewise.
2021-11-29 14:52:42 +00:00
Tom de Vries
c261149278 [gdb/testsuite] Fix typo in proc lines
Proc lines contains a typo:
...
  string_form { set $_line_string_form $value }
...

Remove the incorrect '$' in '$_line_string_form'.

Tested on x86_64-linux.
2021-11-29 09:51:10 +01:00
Tom de Vries
2a0fa84217 [gdb/testsuite] Use unique files in gdb.dwarf2/dw2-lines.exp
While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the
test-case generates all executables and associated temporary files using the
same filenames.

Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the
test-case.

Tested on x86_64-linux.
2021-11-29 09:51:10 +01:00
Tom de Vries
97b3f4e86f [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp with -m32
When running test-case gdb.dwarf2/dw2-lines.exp with target board -unix/-m32,
we run into another instance of PR28383, where the dwarf assembler generates
64-bit relocations which are not supported by the 32-bit assembler:
...
dw2-lines-dw.S: Assembler messages:^M
outputs/gdb.dwarf2/dw2-lines/dw2-lines-dw.S:76: Error: \
  cannot represent relocation type BFD_RELOC_64^M
...

Fix this by using _op_offset in _line_finalize_header.

Tested on x86_64-linux.
2021-11-29 09:51:10 +01:00
Mike Frysinger
b42f20d2ac sim: testsuite: drop most specific istarget checks
We'll rely on the toolchain probing to determine whether each arch's
tests can be run rather the current configure target.  This allows
testing all of the ports in a multitarget configuration.

For now, we don't reformat the files entirely to make it easier to
review, and in case we need to make adjustments.  Once this feels
like it's stable, we can flatten the code a bit by removing the if
statement entirely.
2021-11-28 21:55:16 -05:00
Mike Frysinger
804de1faf4 sim: testsuite: support parallel execution
Break up the dejagnu logic so that we can parallelize the testsuite.
This takes a page from gcc & gdb where each .exp is run in isolation
instead of in serial.

For most targets, this doesn't make much of a difference as they only
have a single .exp.  A few (like cris & frv) have multiple .exp though
and will see a bit of a speed up.

The real gain is when testing a multitarget build.  This way we can
run all the targets in parallel and cut the execution time a bit.
On my system, it goes from ~155sec to ~100sec.

We can gain further speedups by splitting up some of the larger .exp
files into smaller groups.  We'll do that in a followup though.
2021-11-28 21:55:15 -05:00
Mike Frysinger
7a259895bb sim: testsuite: expand arch specific toolchain settings
Leverage the new per-port toolchain settings to initialize the env
for eeach set of tests.  This allows us to run all the tests in a
multitarget build if the user sets up the vars.  If they don't, we
can still skip all the tests.
2021-11-28 21:55:15 -05:00
Mike Frysinger
8996c21067 sim: testsuite: setup per-port toolchain settings for multitarget build
Gas does not support multitarget builds -- it still only supports
a single input & output format.  ld is a bit better, but requires
manual flags to select the right output.  This makes it impossible
to run the complete testsuite in a multitarget build.

To address this limitation, create a suite of FOR_TARGET variables
so these can be set to precompiled as & ld programs.  It requires
a bit of setup ahead of time, but it's a one-time cost, and makes
running the full testsuite at once much easier.
2021-11-28 21:55:15 -05:00
GDB Administrator
dba322be6e Automatic date update in version.in 2021-11-29 00:00:09 +00:00
Alan Modra
28cdb9c67a PR28629 NIOS2 fallout
The test exactly matched wrong output.

	PR 28629
	* testsuite/gas/nios2/relax.d: Update expected output.
2021-11-29 09:29:29 +10:30
Mike Frysinger
e9307449c3 sim: add checks to core headers to prevent incorrect common building
Some of the core sim headers rely on the SIM_AC_OPTION_BITSIZE macro
which can change the size of core types.  Since these haven't been
unified across ports, add checks to make sure they aren't accidentally
included when building for all ports.  This caught the sim-load file
using poisoned headers that it didn't actually need.
2021-11-28 14:28:35 -05:00
Mike Frysinger
6688220490 sim: unify syscall.o building
Now that we've unified all the syscall tables, this file does not rely
on any port-specific settings, so move it up to building as part of the
common step so we only do it once in a multibuild.
2021-11-28 13:24:04 -05:00