Tom Tromey [Wed, 21 Feb 2024 15:22:01 +0000 (08:22 -0700)]
Pass alignment when using GCC_C_FE_VERSION_2
When the GCC compiler plugin responds with GCC_C_FE_VERSION_2, gdb can
use the new 'finish_record_with_alignment' method. This lets gdb pass
alignment information to the compiler, which in turn fixes the test
case included in this patch.
Tom Tromey [Fri, 22 Dec 2023 18:43:26 +0000 (11:43 -0700)]
Remove 'if' from GDB_PY_HANDLE_EXCEPTION
This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and
GDB_PY_SET_HANDLE_EXCEPTION. I believe this 'if' was necessary with
the old gdb try/catch macros, but it no longer is: these should only
ever be called from a 'catch' block, where it's already known that an
exception was thrown.
Simon pointed out, though, that in a few spots, these were in facts
called outside of 'catch' blocks. This patch cleans up these spots.
I also found one spot where a redundant 'return nullptr' could be
removed.
Tom de Vries [Thu, 14 Mar 2024 10:25:10 +0000 (11:25 +0100)]
[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64
On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into:
...
(gdb) watch data.u.size8twice[1]^M
Hardware watchpoint 241: data.u.size8twice[1]^M
(gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1]
continue^M
Continuing.^M
FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)
FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write
...
This happens as follows.
We start the exec and set an 8-byte hardware watchpoint on
data.u.size8twice[1] at address 0x440048:
...
(gdb) p sizeof (data.u.size8twice[1])
$1 = 8
(gdb) p &data.u.size8twice[1]
$2 = (uint64_t *) 0x440048 <data+16>
...
We continue execution, and a 16-byte write at address 0x440040 triggers the
hardware watchpoint:
...
4101c8: a9000801 stp x1, x2, [x0]
...
When checking whether a watchpoint has triggered in
aarch64_stopped_data_address, we check against address 0x440040 (passed in
parameter addr_trap). This behaviour is documented:
...
/* ADDR_TRAP reports the first address of the memory range
accessed by the CPU, regardless of what was the memory
range watched. ... */
...
and consequently the matching logic compares against an addr_watch_aligned:
...
&& addr_trap >= addr_watch_aligned
&& addr_trap < addr_watch + len)
...
However, the comparison fails:
...
(gdb) p /x addr_watch_aligned
$3 = 0x440048
(gdb) p addr_trap >= addr_watch_aligned
$4 = false
...
Consequently, aarch64_stopped_data_address returns false, and
stopped_by_watchpoint returns false, and watchpoints_triggered returns 0,
which make infrun think it's looking at a delayed hardware
breakpoint/watchpoint trap:
...
[infrun] handle_signal_stop: stop_pc=0x4101c8
[infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap, ignoring
...
Infrun then ignores the trap and continues, but runs into the same situation
again and again, causing a hang which then causes the test timeout.
Fix this by allowing a match 8 bytes below addr_watch_aligned. This
introduces the possibility for false positives, so we only do this for regular
"value changed" watchpoints.
An earlier version of this patch worked by aligning addr_watch_aligned to 16
instead of 8:
...
- const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 8);
+ const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 16);
...
but while that fixed the test-case, it didn't fix the problem completely, so
extend the test-case to check more scenarios.
Tested on aarch64-linux.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/29423
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423
H.J. Lu [Wed, 13 Mar 2024 13:45:16 +0000 (06:45 -0700)]
bfd: Use size_t in the BFD mmap interface
Change the size type in the BFD mmap interface from bfd_size_type to
size_t to be consistent with the size type of the host mmap interface.
* bfdio.c (bfd_iovec): Change the bmmap size type to size_t.
(bfd_mmap): Likewise.
(memory_bmmap): Likewise.
* cache.c (cache_bmmap): Change the bmmap size type to size_t.
* opncls.c (opncls_bmmap): Change the bmmap size type to size_t.
* bfd-in2.h: Regenerated.
* libbfd.h: Likewise.
H.J. Lu [Wed, 13 Mar 2024 13:31:28 +0000 (06:31 -0700)]
bfd: Use MAP_FAILED for mmap failure
Use MAP_FAILED, instead of ((void *) -1), for mmap failure and use
((void *) -1) only if MAP_FAILED is undefined.
* bfdio.c (bfd_mmap): Replace (void *) -1 with MAP_FAILED for
mmap failure.
* bfdwin.c: Don't include <sys/mman.h>.
(MAP_FILE): Removed.
(bfd_get_file_window): Replace (void *) -1 with MAP_FAILED for
mmap failure.
* cache.c: Don't include <sys/mman.h>.
(cache_bmmap): Replace (void *) -1 with MAP_FAILED for mmap
failure.
* opncls.c (opncls_bmmap): Likewise.
* sysdep.h: Include <sys/mman.h> if HAVE_MMAP is define.
(MAP_FILE): New. Defined as 0 if undefined.
(MAP_FAILED): New. Defined as ((void *) -1) if undefined.
Hau Hsu [Fri, 23 Feb 2024 06:17:28 +0000 (14:17 +0800)]
RISC-V: Add -march=help for gas
Use -march=help for gas to print all supported extensions and versions.
Here is part of the output of `as -march=help`:
All available -march extensions for RISC-V:
e 1.9
i 2.1, 2.0
m 2.0
a 2.1, 2.0
f 2.2, 2.0
d 2.2, 2.0
q 2.2, 2.0
c 2.0
v 1.0
h 1.0
zicbom 1.0
zicbop 1.0
...
This patch assumes that the supported extensions with the same versions
are listed together. For example:
static struct riscv_supported_ext riscv_supported_std_ext[] =
{
...
{"i", ISA_SPEC_CLASS_20191213, 2, 1, 0 },
{"i", ISA_SPEC_CLASS_20190608, 2, 1, 0 },
{"i", ISA_SPEC_CLASS_2P2, 2, 0, 0 },
...
};
For the "i" extension, 2.1.0 with different spec class are listed together.
This patch records the previous printed extension and version. If the
current extension and version are the same as the previous one, skip
printing.
bfd/
* elfxx-riscv.c (riscv_print_extensions): New function. Print
available extensions and versions.
* elfxx-riscv.h (riscv_print_extensions): New declaration.
gas/
* gas/config/tc-riscv.c (md_parse_option): Parse 'help' keyword in
-march option to print available extensions and versions.
* testsuite/gas/riscv/march-help.l: New testcase for -march=help.
* testsuite/gas/riscv/riscv.exp: Updated.
Tom de Vries [Tue, 12 Mar 2024 16:08:18 +0000 (17:08 +0100)]
[gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64
On aarch64-linux, with test-case gdb.base/watch-bitfields.exp I run into:
...
(gdb) continue^M
Continuing.^M
^M
Hardware watchpoint 2: -location q.a^M
^M
Old value = 1^M
New value = 0^M
main () at watch-bitfields.c:42^M
42 q.h--;^M
(gdb) FAIL: $exp: -location watch against bitfields: q.e: 0->5: continue
...
In a minimal form, if we step past line 37 which sets q.e, and we have a
watchpoint set on q.e, it triggers:
...
$ gdb -q -batch watch-bitfields -ex "b 37" -ex run -ex "watch q.e" -ex step
Breakpoint 1 at 0x410204: file watch-bitfields.c, line 37.
Breakpoint 1, main () at watch-bitfields.c:37
37 q.e = 5;
Hardware watchpoint 2: q.e
Hardware watchpoint 2: q.e
Old value = 0
New value = 5
main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:38
38 q.f = 6;
...
However, if we set in addition a watchpoint on q.a, the watchpoint on q.e
doesn't trigger.
How does this happen?
Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1
and bit 1 of byte 2. So, watch q.a should watch byte 0, and watch q.e should
watch bytes 1 and 2.
Using "maint set show-debug-regs on" (and some more detailed debug prints) we
get:
...
WP2: addr=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1
ctrl: enabled=1, offset=1, len=2
WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1
ctrl: enabled=1, offset=0, len=1
...
which matches that.
When executing line 37, a hardware watchpoint trap triggers and we hit
aarch64_stopped_data_address with addr_trap == 0x440028:
...
(gdb) p /x addr_trap
$1 = 0x440028
....
and since the loop in aarch64_stopped_data_address walks backward, we check
WP3 first, which matches, and consequently target_stopped_by_watchpoint
returns true in watchpoints_triggered.
Likewise for target_stopped_data_address, which also returns addr == 0x440028.
Watchpoints_triggered matches watchpoint q.a to that address, and sets
watch_triggered_yes.
However, subsequently the value of q.a is checked, and it's the same value as
before (becase the insn in line 37 didn't change q.a), so the watchpoint
hardware trap is not reported to the user.
The problem originates from that fact that aarch64_stopped_data_address picked
WP3 instead of WP2.
There's something we can do about this. In the example above, both
target_stopped_by_watchpoint and target_stopped_data_address returned true.
Instead we can return true in target_stopped_by_watchpoint but false in
target_stopped_data_address. This lets watchpoints_triggered known that a
watchpoint was triggered, but we don't know where, and both watchpoints
get set to watch_triggered_unknown.
Subsequently, the values of both q.a and q.e are checked, and since q.e is not
the same value as before, the watchpoint hardware trap is reported to the user.
Note that this works well for regular (write) watchpoints (watch command), but
not for read watchpoints (rwatch command), because for those no value is
checked. Likewise for access watchpoints (awatch command).
So, fix this by:
- passing a nullptr in aarch64_fbsd_nat_target::stopped_by_watchpoint and
aarch64_linux_nat_target::stopped_by_watchpoint to make clear we're not
interested in the stop address,
- introducing a two-phase approach in aarch64_stopped_data_address, where:
- phase one handles access and read watchpoints, as before, and
- phase two handles write watchpoints, where multiple matches cause:
- return true if addr_p == null, and
- return false if addr_p != null.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31214
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31214
This patch deprecates the MPX commands "show/set mpx bound".
Intel listed Intel(R) Memory Protection Extensions (MPX) as removed
in 2019. Following gcc v9.1, the linux kernel v5.6 and glibc v2.35,
deprecate MPX in GDB.
Lulu Cai [Sat, 2 Mar 2024 02:47:42 +0000 (10:47 +0800)]
LoongArch: Scan all illegal operand instructions without interruption
Currently, gas will exit immediately and report an error when
it sees illegal operands, and will not process the remaining
instructions. Replace as_fatal with as_bad to check for all
illegal operands.
Add test cases for illegal operands of some instructions.
Lulu Cai [Thu, 7 Mar 2024 03:09:14 +0000 (11:09 +0800)]
LoongArch: Fix gas and ld test cases
* After adding the old LE relax, all old LE relocations will have
an R_LARCH_RELAX relocation. Fix the gas test case failure caused
by the implementation of the old LE relax.
* loongarch64-elf does not support pie and -z norelro options,
removed in test files.
Simon Marchi [Tue, 12 Mar 2024 02:41:19 +0000 (22:41 -0400)]
gnulib: re-generate build files
I see some changes in the generated files when running update-gnulib.sh.
The changes appeared with commit 35b38b0182d0 ("Finalized intl-update
patches (trois)"). This is most likely due to how the autotools were
ran in that commit, possibly with some different -I arguments.
Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b
which would've required an autoreconf, as it should be handled separately.
Tom Tromey [Wed, 13 Dec 2023 02:22:07 +0000 (19:22 -0700)]
Remove tui-out.[ch]
The other day on irc, we were discussing the "m_line" hack in
tui-out.c, and I mentioned that it would be nice to replace this with
a new ui_out_flag.
Later, I looked at ui_out_flag and found:
ui_source_list = (1 << 0),
... and sure enough, this is tested already.
This patch removes tui-out.[ch] and changes the TUI to use an ordinary
cli-out object without this flag set.
As far as I can tell, this doesn't affect behavior at all -- the TUI
tests all pass, and interactively I tried switching stack frames,
"list", etc, and it all seems to work.
New in v2: fixed the problem pointed out by Keith, and added a test
case for that scenario.
Simon Marchi [Mon, 11 Mar 2024 19:32:40 +0000 (15:32 -0400)]
gdb/Makefile.in: remove ACLOCAL_AMFLAGS
aclocal picks up the relevant include paths from AC_CONFIG_MACRO_DIRS in
configure.ac, so there's no need to pass `-I ../config` here.
Passing `-I ../config` is actually annoying, because it makes the output
different between when the update is triggered by the maintainer mode
and when aclocal or autoreconf is ran with no special flags. The
difference in the output is due to the order of include paths being
different.
Change-Id: I2c963876516570842f20b4a6a470867e7a941006 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Tue, 13 Feb 2024 18:47:38 +0000 (11:47 -0700)]
Special case NULL pointers in dynamic type resolution
commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically")
caused a regression on a test case in the AdaCore internal test suite.
The issue here is that gdb would try to resolve the type of a dynamic
pointer that happened to be NULL. In this case, the "Location address
is not set." error would end up being thrown from the DWARF expression
evaluator.
I think it makes more sense to special-case NULL pointers and not try
to resolve their target type, as that type can't really be accessed
anyway.
This patch implements this idea, and also adds the missing Ada test
case.
Nick Alcock [Tue, 30 Jan 2024 14:18:54 +0000 (14:18 +0000)]
libctf: fix uninitialized variables in testsuite
Just because a path is an error path doesn't mean the program terminates
there if you don't ask it to. And we don't want to -- but that means
we need to initialize the variables that are missed if an error happens to
*something*. Type ID 0 (unimplemented) will do: it'll induce further
ECTF_BADID errors, but that's no bad thing.
we cleared the original errno. When the error reason can not be explained
in a more detailed error message, and we fall back to the default error
message, it now gives Success as error.
The problem reported here was using GDB on GNU/Linux for S390, the
user stepped into JIT generated code. As they enter the JIT code GDB
would report 'PC not saved', and this same message would be reported
after each step/stepi.
Additionally, the user had 'set disassemble-next-line on', and once
they entered the JIT code this output was not displayed, nor were any
'display' directives displayed.
The user is not making use of the JIT plugin API to provide debug
information. But that's OK, they aren't expecting any source level
debug here, they are happy to use 'stepi', but the missing 'display'
directives are a problem, as is the constant 'PC not saved' (error)
message.
What is happening here is that as GDB is failing to find any debug
information for the JIT generated code, it is falling back on to the
S390 prologue unwinder to try and unwind frame #0. Unfortunately,
without being able to identify the function boundaries, the S390
prologue scanner can't help much, in fact, it doesn't even suggest an
arbitrary previous $pc value (some targets that use a link-register
will, by default, assume the link-register contains the previous $pc),
instead the S390 will just say, "sorry, I have no previous $pc value".
The result of this is that when GDB tries to find frame #1 we end
throwing an error from frame_unwind_pc (the 'PC not saved' error).
This error is not caught anywhere except at the top-level interpreter
loop, and so we end up skipping all the 'display' directive handling.
While thinking about this, I wondered, could I trigger the same error
using the Python Unwinder API? What happens if a Python unwinder
claims a frame, but then fails to provide a previous $pc value?
Turns out that exactly the same thing happens, which is great, as that
means we now have a way to reproduce this bug on any target. And so
the test included with this patch does just this. I have a Python
unwinder that claims a frame, but doesn't provide any previous
register values.
I then do two tests, first I stop in the claimed frame (i.e. frame #0
is the frame that can't be unwound), I perform a few steps, and check
the backtrace. And second, I stop in a child of the problem
frame (i.e. frame #1 is the frame that can't be unwound), and from
here I check the backtrace.
While all this is going on I have a 'display' directive in place, and
each time GDB stops I check that the display directive triggers.
Additionally, when checking the backtrace, I am checking that the
backtrace finishes with the message 'Backtrace stopped: frame did not
save the PC'.
As for the fix I chose to add a call to frame_unwind_pc directly to
get_prev_frame_always_1. Calling frame_unwind_pc will cache the
unwound $pc value, so this doesn't add much additional work as
immediately after the new frame_unwind_pc call, we call
get_prev_frame_maybe_check_cycle, which actually generates the
previous frame, which will always (I think) require a call to
frame_unwind_pc anyway.
The reason for adding the frame_unwind_pc call into
get_prev_frame_always_1, is that if the frame_unwind_pc call fails we
want to set the frames 'stop_reason', and get_prev_frame_always_1
seems to be the place where this is done, so I wanted to keep the new
stop_reason setting code next to all the existing stop_reason setting
code.
Additionally, once we enter get_prev_frame_maybe_check_cycle we
actually create the previous frame, then, if it turns out that the
previous frame can't be created we need to remove the frame .. this
seemed more complex than just making the check in
get_prev_frame_always_1.
With this fix in place the original S390 bug is fixed, and also the
test added in this commit, that uses the Python API, is also fixed.
Guinevere Larsen [Mon, 11 Mar 2024 09:57:32 +0000 (10:57 +0100)]
gdb/testsuite: Reduce gdb.threads/threadcrash.exp reliance on libc symbols
The test gdb.threads/threadcrash.exp demanded GDB to fully unwind and
print the names of all functions. However, some of the functions are
from the libc library, and so the test implicitly demanded libc symbols
to be available, and would fail otherwise, as was raised in PR
gdb/31293.
This commit changes it so we only explicitly check for functions that
are not provided by threadcrash.c if they are indeed available.
Tested on arm-linux and x86_64-linux.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31293
Guinevere Larsen [Mon, 11 Mar 2024 09:57:31 +0000 (10:57 +0100)]
gdb/testsuite: Use _inferior_thread_count in gdb.threads/threadcrash.exp
A linaro PR [1] reports that the gdb.threads/threadcrash.exp test-case fails
to cout the number of threads in the inferior:
...
FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7
FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == [llength $test_list]
...
Fix this by getting the convenience variable _inferior_thread_count as opposed
to calculating it based on the output of "info threads".
Tested on arm-linux and x86_64-linux.
Reviewed-By: Lancelot Six <lancelot.six@amd.com> Approved-By: Tom de Vries <tdevries@suse.de>
[1] https://linaro.atlassian.net/browse/GNU-1120
Tom de Vries [Mon, 11 Mar 2024 09:57:31 +0000 (10:57 +0100)]
gdb/testsuite: Fix gdb.threads/threadcrash.exp with check-readmore
With check-readmore, I run into:
...
FAIL: gdb.threads/threadcrash.exp: test_corefile: \
$thread_count == [llength $test_list]
...
The problem is that the clauses in the gdb_test_multiple for
"thread apply all backtrace" intent to match one line, but actually can
match more than one line, and consequently a match for one type of thread can
consume a line that was supposed to match another thread.
For instance, there's this regexp:
...
-re "\[^\n\]*syscall_task .location=SIGNAL_ALT_STACK\[^\n\]*" {
...
It's limited at the end by \[^\n\]*, meaning the match stops at the end of the
line.
But it doesn't start with a ^, and consequently can match more than one line.
The "\[^\n\]*" at the start doesn't prevent this, there's an implicit .* at
the start of each pattern, unless it's anchored using a ^.
Fix this by rewriting the regexps in a "^\r\n$hs$regexp$hs$eol" style, where:
- hs is: \[^\n\]* (horizontal space), and
- eol is (?=\r\n) (look-ahead end-of-line).
It also turned out to be necessary to drop the -lbl switch, and introduce a
corresponding explicit clause. The -lbl clause is placed ALAP, and
consequently allowed the default fail clause to trigger.
Tom de Vries [Mon, 11 Mar 2024 09:57:31 +0000 (10:57 +0100)]
gdb/testsuite: Reduce indentation in gdb.threads/threadcrash.exp
In test-case gdb.threads/threadcrash.exp we have an unnecessarily indented
gdb_test_multiple:
...
gdb_test_multiple "thread apply all backtrace" \
"Get thread information" -lbl {
-re "#\[0-9\]+\\\?\\\?\[^\n\]*" {
...
Fix this by moving the command into a variable, allowing the
"gdb_test_multiple ... {" to fit on a single 80 chars line.
Jan Beulich [Mon, 11 Mar 2024 07:23:45 +0000 (08:23 +0100)]
x86: KeyLocker insn interaction with -msse-check / .sse_check
Some of these have no explicit %xmm operand(s), yet they still act SSE-
like (in leaveing bits 128 and up untouched). Hence they want similarly
diagnosing, if that was asked for.
Jan Beulich [Mon, 11 Mar 2024 07:23:11 +0000 (08:23 +0100)]
x86/APX: permit wider than 4-bit immediates with V{EXTRACT,INSERT}{F,I}128
These aren't useful, but can be encoded for their AVX forms and hence
should also be permitted for the APX surrogates. Extend the respective
conditional by a base opcode check, to restrict it to VROUND{P,S}{S,D}.
Stephen Kitt [Mon, 11 Mar 2024 07:21:47 +0000 (08:21 +0100)]
tests: force non-deterministic mode in non-deterministic tests
Since ar can be built defaulting to deterministic mode, tests which
expect non-deterministic behaviour need to explicitly set the U flag.
The non-deterministic member test expects SOURCE_DATE_EPOCH to not be
set; this documents that. Unconditionally unsetting the variable
causes issues in test infrastructure (which expects unsetenv to only
be called on variables which are already set).
Tom de Vries [Sat, 9 Mar 2024 15:13:10 +0000 (16:13 +0100)]
[gdb/python] Normalize exceptions in gdbpy_err_fetch
With python 3.12, I run into:
...
(gdb) PASS: gdb.python/py-block.exp: check variable access
python print (block['nonexistent'])^M
Python Exception <class 'KeyError'>: 'nonexistent'^M
Error occurred in Python: 'nonexistent'^M
(gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable
...
The problem is that that PyErr_Fetch returns a normalized exception, while the
test-case matches the output for an unnormalized exception.
With python 3.6, PyErr_Fetch returns an unnormalized exception, and the
test passes.
Fix this by:
- updating the test-case to match the output for a normalized exception, and
- lazily forcing normalized exceptions using PyErr_NormalizeException.
Tom de Vries [Sat, 9 Mar 2024 15:13:10 +0000 (16:13 +0100)]
[gdb/python] Use gdbpy_err_fetch::{type,value} as getters
Similar to gdbpy_err_fetch::value, add a getter gdbpy_err_fetch::type, and use
both consistently to get gdbpy_err_fetch members m_error_value and
m_error_type.
Alan Modra [Sat, 9 Mar 2024 09:57:32 +0000 (20:27 +1030)]
Reinstate bfd_print_error as an extern function
* bfd.c (_bfd_print): Renamed from bfd_print_error.
(bfd_print_error): Reinstate previous code but using the above.
(error_handler_fprintf, error_handler_sprintf): Adjust.
* bfd-in2.h: Regenerate.
Alan Modra [Sat, 9 Mar 2024 02:56:19 +0000 (13:26 +1030)]
print cached error messages using _bfd_error_handler
* bfd.c (bfd_print_error): Make static. Don't print program name.
(error_handler_fprintf): Print program name here.
* format.c (print_warnmsg): Use _bfd_error_handler to print
cached messages.
* bfd-in2.h: Regenerate.
Tom Tromey [Sun, 28 Jan 2024 16:14:04 +0000 (09:14 -0700)]
Avoid race when writing to index cache
The background DWARF reader changes introduced a race when writing to
the index cache. The problem here is that constructing the
index_cache_store_context object should only happen on the main
thread, to ensure that the various value captures do not race.
This patch adds an assert to the construct to that effect, and then
arranges for this object to be constructed by the cooked_index_worker
constructor -- which is only invoked on the main thread.
Tom Tromey [Sat, 27 Jan 2024 15:59:06 +0000 (08:59 -0700)]
Move the 'store' method to index_cache_store_context
I think it is cleaner for 'store' to be a method on
index_cache_store_context rather than on the global index cache
itself. This patch makes this change.
Tom Tromey [Sat, 27 Jan 2024 15:56:53 +0000 (08:56 -0700)]
Capture the per-BFD object in index_cache_store_context
This changes index_cache_store_context to also capture the per-BFD
object when it is constructed. This is used when storing to the
cache, and this approach makes the code a little simpler.
Tom Tromey [Sat, 27 Jan 2024 15:52:46 +0000 (08:52 -0700)]
Capture directory in index_cache_store_context
I noticed that index_cache_store_context captures the 'enabled'
setting, but not the index cache directory. This patch makes this
change, which avoids a possible race -- with background reading, the
user could possibly change this directory at the exact moment the
writer examines the variable.
Tom Tromey [Mon, 12 Feb 2024 17:12:26 +0000 (10:12 -0700)]
Add return value to DAP scope
A bug report in the DAP specification repository pointed out that it
is typical for DAP implementations to put a function's return value
into the outermost scope.
This patch changes gdb to follow this convention.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31341 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Mon, 12 Feb 2024 15:12:02 +0000 (08:12 -0700)]
Export "finish" return value to Python
This patch changes the Python "stop" event emission code to also add
the function return value, if it is known. This happens when the stop
comes from a "finish" command and when the value can be fetched.
H.J. Lu [Fri, 8 Mar 2024 16:08:02 +0000 (08:08 -0800)]
gas: Fix x86 build with GCC 6.4
Add "()" to silence GCC 6.4:
.../gas/config/tc-i386.c: In function ‘x86_ginsn_lea’:
.../gas/config/tc-i386.c:5738:19: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
if (!i.base_reg != (!i.index_reg || i.index_reg->reg_num == RegIZ))
^~
cc1: all warnings being treated as errors
Tom Tromey [Thu, 25 Jan 2024 13:48:22 +0000 (06:48 -0700)]
Avoid race when reading dwz file
PR gdb/31260 points out a race introduced by the background reading
changes. If a given objfile is re-opened when it is already being
read, dwarf2_initialize_objfile will call dwarf2_read_dwz_file again,
causing the 'dwz_file' to be reset.
This patch fixes the problem by arranging to open the dwz just once:
when the dwarf2_per_bfd object is created.
H.J. Lu [Wed, 6 Mar 2024 23:23:56 +0000 (15:23 -0800)]
bfd: Don't hard-code BFD_JUMP_TABLE_COPY
In BFD_JUMP_TABLE_COPY, replace _bfd_generic_init_private_section_data
with NAME##_init_private_section_data so that ELF targets can properly
replace it with _bfd_elf_init_private_section_data.
Jiawei [Wed, 28 Feb 2024 08:27:17 +0000 (16:27 +0800)]
RISC-V: Support Zabha extension.
The Zabha extension[1] supports for byte and halfword
atomic memory operations. This patch add all instructions
include in Zabha. Further work is waiting Zacas[2] merge.
Lulu Cai [Wed, 24 Jan 2024 09:43:20 +0000 (17:43 +0800)]
LoongArch: Delete extra instructions when TLS type transition
This modification mainly changes the timing of type transition,
adds relaxation to the old LE instruction sequence, and fixes
bugs in extreme code models.
We strictly distinguish between type transition and relaxation.
Type transition is from one type to another, while relaxation
is the removal of instructions under the same TLS type. Detailed
instructions are as follows:
1. For type transition, only the normal code model of DESC/IE
does type transition, and each relocation is accompanied by a
RELAX relocation. Neither abs nor extreme will do type transition,
and no RELAX relocation will be generated.
The extra instructions when DESC transitions to other TLS types
will be deleted during the type transition.
2. Implemented relaxation for the old LE instruction sequence.
The first two instructions of LE's 32-bit and 64-bit models
use the same relocations and cannot be distinguished based on
relocations. Therefore, for LE's instruction sequence, any code
model will try to relax.
3. Some function names have been adjusted to facilitate understanding,
parameters have been adjusted, and unused macros have been deleted.
Andrew Burgess [Thu, 1 Feb 2024 12:57:11 +0000 (12:57 +0000)]
gdb/testsuite: fix duplicate test names in gdb.trace/circ.exp
This fixes some duplicate test names in gdb.trace/circ.exp when using
native-gdbserver and native-extended-gdbserver boards.
In this test we set the trace buffer size twice. The same test name
was used each time the size was adjusted.
I've fixed this issue by:
1. Creating a new proc, set_trace_buffer_size, which factors out the
code to change the buffer size, and uses test names based on the
size we're setting the buffer too,
2. Calling the new proc each time we want to adjust the buffer size.
After this the duplicate test names are resolved. There should be no
change in what is tested after this commit.
Andrew Burgess [Thu, 1 Feb 2024 12:49:02 +0000 (12:49 +0000)]
gdb/testsuite: fix some more duplicate test names in gdb.trace/
This commit fixes some duplicate test names in the gdb.trace/
directory when run with the native-gdbserver and
native-extended-gdbserver boards. In this case the duplicates relate
to the calls to gdb_compile_pthreads which emits a fixed PASS message,
as there are two calls to gdb_compile_pthreads we get a duplicate PASS
message.
In both cases the problem is fixed by adding a with_test_prefix around
one of the compilations, however, I've made additional changes to
clean up the tests a little while I was working on them:
1. Switch to use prepare_for_testing instead of
gdb_compile_pthreads. By passing the 'pthreads' option this does
call gdb_compile_pthreads under the hood, but using the standard
compile function is cleaner,
2. Using prepare_for_testing removes the need to call clean_restart
immediately afterwards, so those calls are removed,
3. I removed the unneeded $executable and $expfile globals, where
the $executable global was used I've replaced this with $binfile,
4. When we compile two executables I've now given these different
names so that both exist at the end of the test run,
5. Removed a gdb_reinitialize_dir call, this is covered by
clean_restart,
6. Use gdb_test_no_output where it makes sense.
I now see no duplicate test names when running these test scripts.
There should be no change in what is being tested after this commit.
Hui Li [Tue, 27 Feb 2024 01:18:10 +0000 (09:18 +0800)]
gdb: LoongArch: Change LOONGARCH_FIRST_FP_REGNUM to 35
There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())"
in find_register_by_number() when gdb connects to gdbserver, this
is because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains
10 reserved regs) is different with the number of regs (35, which not
contains 10 reserved regs) in file gdb/features/loongarch/base64.xml.
Add a new macro LOONGARCH_USED_NUM_GREGSET which is defined as 35 to
keep consistent with the gdb/features/loongarch/base64.xml, and then
define LOONGARCH_FIRST_FP_REGNUM as LOONGARCH_USED_NUM_GREGSET so that
all the reg numbers in regcache are consistent with tdesc reg numbers.
Process ./test created; pid = 67683
Listening on port 5678
Remote debugging from host 192.168.1.136, port 6789
gdbserver/regcache.cc:205: A problem internal to GDBserver has been detected.
find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' failed.
Output on the host machine:
Remote debugging using 192.168.1.123:5678
Remote connection closed
Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: John Baldwin <jhb@FreeBSD.org> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tom Tromey [Fri, 9 Feb 2024 23:22:53 +0000 (16:22 -0700)]
Fix TUI text centering
In a couple of spots, the TUI tries to center some text in the window.
Andrew noticed that the calculation is done strangely and the text
ends up somewhat to the left of center.
With <operand-type> being one of:
- base register
- displacement
- [vector] index register
- length
- access register
- control register
- floating-point register
- general-purpose register
- vector register
- [un]signed number
gas/
* config/tc-s390.c: Provide missing operand type in error
message.
* testsuite/gas/s390/zarch-base-index-0-err.l: Update test case
result validation patterns to operand number in operand syntax
error messages.
* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Provide operand number in assembler warning and error messages
Prepend the operand number "operand %d:" to the s390-specific assembler
operand parsing warning and error messages.
While at it reword the custom operand out of range error message text to
be closer to the one used by as_bad_value_out_of_range(). Additionally
reword the invalid FPR pair warning message to make it nicer.
gas/
* config/tc-s390.c: Print operand number in error messages.
* testsuite/gas/s390/zarch-base-index-0-err.l: Update test case
verification patterns to accept syntax error messages now
containing the operand number.
* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.
* testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise.
* testsuite/gas/s390/zarch-z9-109-err.l: Likewise.
* testsuite/gas/s390/zarch-z900-err.l: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Allow to explicitly omit base register operand in assembly
The base register operand B may be omitted in D(B) by coding D and in
D(L,B) by coding D(L). The index register operand X may be omitted in
D(X,B) by coding D(B) or explicitly omitted by coding D(,B). In both
cases the omitted base register operand value defaults to zero.
Allow to explicitly omit the base register operand B in D(X,B) and
D(L,B) by coding D(X,) and D(L,). Default the omitted base register
operand value to zero.
gas/
* config/tc-s390.c: Allow to explicitly omit the base register
operand in assembly.
* NEWS: Mention that the base register now may be omitted on
s390.
* gas/testsuite/gas/s390/zarch-base-index-0.s: Update test cases
for change to allow to explicitly omit the base register
operand in assembly.
* gas/testsuite/gas/s390/zarch-base-index-0.d: Likewise.
* gas/testsuite/gas/s390/zarch-base-index-0-err.s: Likewise.
* gas/testsuite/gas/s390/zarch-base-index-0-err.l: Likewise.
* gas/testsuite/gas/s390/zarch-omitted-base-index.s: Likewise.
* gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.
* gas/testsuite/gas/s390/zarch-omitted-base-index-err.s:
Likewise.
* gas/testsuite/gas/s390/zarch-omitted-base-index-err.l:
Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Print base register 0 as "0" in disassembly
Base and index register 0 have no effect in address computation:
"A value of zero in the B [base] or X [index] field specifies that no
base or index is to be applied, and, thus, general register 0 cannot be
designated as containing a base address or index."
IBM z/Architecture Principles of Operation [1], chapter "Organization",
section "General Registers".
Index register 0 is omitted in the s390 disassembly. Base register 0 is
omitted in D(B), D(L,B) and D(X,B) - the latter only if the index
register is zero.
To make it more apparent print base register 0 as "0" instead of "%r0",
whenever it would still be printed in the disassembly.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
opcodes/
* s390-dis.c: Print base register 0 as "0" in disassembly.
binutils/
* NEWS: Mention base register 0 now being printed as "0" in s390
disassembly.
gas/
* testsuite/gas/s390/zarch-base-index-0.d: Update test case
output verification patterns to accept "0" as base base
register due to disassembler output format change.
* gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Warn when register name type does not match operand
Print a warning message when the register type of a specified register
name does not match with the operand's register type:
operand {#}: expected {access|control|floating-point|general|vector}
register name [as {base|index} register]
Introduce a s390-specific assembler option "warn-regtype-mismatch"
with the values "strict", "relaxed", and "no" as well as an option
"no-warn-regtype-mismatch" which control whether the assembler
performs register name type checks and generates above warning messages.
warn-regtype-mismatch=strict:
Perform strict register name type checks.
warn-regtype-mismatch=relaxed:
Perform relaxed register name type checks, which allow floating-point
register (FPR) names %f0 to %f15 to be specified as argument to vector
register (VR) operands and vector register (VR) names %v0 to %v15 to
be specified as argument to floating-point register (FPR) operands.
This is acceptable as the FPRs are embedded into the lower halves of
the VRs. Make "relaxed" the default, as GCC generates assembler code
using FPR and VR interchangeably, which would cause assembler warnings
to be generated with "strict".
warn-regtype-mismatch=no:
no-warn-regtype-mismatch:
Disable any register name type checks.
Tag .insn pseudo mnemonics as such, to skip register name type checks
on those. They need to be skipped, as there do not exist .insn pseudo
mnemonics for every possible operand register type combination. Keep
track of the currently parsed operand number to provide it as reference
in warning messages.
To verify that the introduction of this change does not unnecessarily
affect the compilation of existing code the GNU Binutils, GNU C Library,
and Linux Kernel have been build with the new assembler, verifying that
the assembler did not generate any of the new warning messages.
gas/
* config/tc-s390.c: Handle new assembler options
"[no]warn-regtype-mismatch[=strict|relaxed|no". Annotate
parsed register expressions with register type. Keep track of
operand number being parsed. Print warning message in case of
register type mismatch between instruction operand and parsed
register expression.
* doc/as.texi: Document new s390-specific assembler options
"[no-]warn-regtype-mismatch[=strict|relaxed|no]".
* NEWS: Mention new s390-specific register name type checks and
related assembler option "warn-regtype-mismatch=strict|
relaxed|no".
* testsuite/gas/s390/s390.exp: Add test cases for new assembler
option "warn-regtype-mismatch={strict|relaxed}".
* testsuite/gas/s390/esa-g5.s: Fix register types in tests for
didbr, diebr, tbdr, and tbedr.
* testsuite/gas/s390/zarch-z13.s: Fix register types in tests
for vgef, vgeg, vscef, and vsceg.
* testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.s:
Tests for assembler option "warn-regtype-mismatch=strict".
* testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.l:
Likewise.
* gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.s:
Tests for assembler option "warn-regtype-mismatch=relaxed".
* gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.l:
Likewise.
* gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: Update
test cases for assembler option "warn-regtype-mismatch"
defaulting to "relaxed".
* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.
include/
* opcode/s390.h (S390_INSTR_FLAG_PSEUDO_MNEMONIC): Add
instruction flag to tag .insn pseudo-mnemonics.
opcodes/
* s390-opc.c (s390_opformats): Tag .insn pseudo-mnemonics as
such.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reorder, reword, and complete the s390-specific option descriptions.
Align the formatting of s390-specific assembler options to that of the
general assembler options in "as --help".
While at it change a warning message to use the term "z/Architecture"
instead of the deprecated "esame" (ESA Modal Extensions or ESAME) one.
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Add test cases for base/index register 0
While at it add comments to logic to omit base and/or index register 0
in s390 disassembly.
opcodes/
* s390-dis.c: Add comments related to omitting base and/or index
register 0 in disassembly.
gas/
* testsuite/gas/s390/s390.exp: Add test cases for base and/or
index register 0.
* testsuite/gas/s390/zarch-base-index-0.s: Add test cases for
base and/or index register 0.
* testsuite/gas/s390/zarch-base-index-0.d: Likewise.
* testsuite/gas/s390/zarch-base-index-0-err.s: Add error test
cases for base and/or index register 0.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Correct setting of highgprs flag in ELF output
The combination of an architecture size of 32 bits and z/Architecture
mode requires the highgprs flag to be set in the ELF output. It causes
the high-halves of the general purpose registers (GPRs) to be preserved
at run-time, so that the code can use 64-bit GPRs.
The architecture size of 32 bits can either be the default in case of
a default architecture name of "s390" or due to specification of the
option -m31 (to generate the 31-bit file format).
The z/Architecture mode can either be the default or due to
specification of the option -mzarch (to assemble for z/Architecture
mode). It can also be selected using the pseudo commands
".machinemode zarch" and ".machinemode zarch_nohighgprs". The latter
not causing the highgprs flag to be set.
The highgprs flag was only set when the following s390-specific
assembler options were given in the following specific order:
"-m31 -mzarch".
The highgprs flag was erroneously not set when:
- the order of above options was inverse (i.e. "-mzarch -m31"),
- the architecture mode defaulted to z/Architecture mode and
option "-m31" was specified,
- the architecture size defaulted to 32 bits due to a default
architecture name of "s390" and option -mzarch was specified,
- the architecture size defaulted to 32 bits and the architecture
mode defaulted to z/Architecture due to the specified processor
(e.g. "-march=z900" or follow-on processor).
Determine whether to set the highgprs flag in init_default_arch() after
having processed all assembler options in md_parse_option(). This
ensures the flag is set in all of the above cases it was erroneously not
set. Add test cases for highgprs flag, including ones that use
.machinemode to switch the architecture mode.
gas/
* config/tc-s390.c: Correct setting of highgprs flag in ELF
output.
* testsuite/gas/s390/s390.exp: Add test cases for highgprs
flag.
* testsuite/gas/s390/blank.s: Empty assembler source used in
test cases for "highgprs" flag.
* testsuite/gas/s390/esa-highgprs-0.d: Add test case for
highgprs flag.
* testsuite/gas/s390/zarch-highgprs-0.d: Likewise.
* testsuite/gas/s390/zarch-highgprs-1.d: Likewise.
* testsuite/gas/s390/esa-highgprs-machinemode-0.s: Add test case
for highgprs flag when using .machinemode to switch
architecture mode.
* testsuite/gas/s390/esa-highgprs-machinemode-0.d: Likewise.
* testsuite/gas/s390/esa-highgprs-machinemode-1.s: Likewise.
* testsuite/gas/s390/esa-highgprs-machinemode-1.d: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Do not erroneously use base operand value for length operand
The base register operand B may optionally be omitted in D(B) by coding
D and in D(L,B) by coding D(L). The index register operand X may
optionally be omitted in D(X,B) by coding D(,B) or D(B). Both base and
index register operands may optionally be omitted in D(X,B) by coding D.
In any case the omitted base and/or index register operand value
defaults to zero.
When parsing an erroneously omitted length L operand in D(L,B) by coding
D(,B) the base register operand B was erroneously consumed as length
operand. When using a register name for the base register operand this
was detected and reported as error. But when not using a register name
the base register operand value was erroneously used as length operand
value.
Correct the parsing of an omitted optional base or index register to not
erroneously use the base register operand value as length, when
erroneously omitting the length operand.
While at it rename the variable used to remember whether the base or
index register operand was omitted to enhance code readability.
Additionally add test cases for the optional omission of base and/or
index register operands.
Disassembly of bad assembly without commit shows the base register
operand value was erroneously used as length operand value:
0: d2 00 10 10 20 20 mvc 16(1,%r1),32(%r2)
6: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2)
c: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2)
Assembler messages with commit:
3: Error: operand 1: missing operand
gas/
* config/tc-s390.c: Correct parsing of omitted base register.
* testsuite/gas/s390/s390.exp: Add test cases for omitted base
and/or index register.
* testsuite/gas/s390/zarch-omitted-base-index.s: Test cases for
omitted optional base or index register.
* testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.
* testsuite/gas/s390/zarch-omitted-base-index-err.s: Test cases
for omitted base and/or index register.
* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Enhance handling of syntax errors in assembler
Do not consume any unexpected character including newline ('\n') when
detecting a syntax error when parsing an operand block with parenthesis.
This resolves the unfavorable assembler messages from the example below,
including consuming the newline at the end of the current statement and
reporting the next statement as junk.
While at it change the only pre-increment of the current instruction
string pointer into a post-increment to align with the other instances.
Example assembler source:
mvi 16(),32 # syntax error
a %r1,16(%r2 # syntax error
a %r1,16(%r2)
mvc 16(1,),32(%r2) # syntax error
mvc 16(1,%r1,32(%r2 # syntax error
Assembler messages without commit:
1: Error: bad expression
1: Error: syntax error; missing ')' after base register
1: Error: syntax error; expected ','
1: Error: junk at end of line: `32'
2: Error: syntax error; missing ')' after base register
2: Error: junk at end of line: `a %r1,16(%r2)'
4: Error: bad expression
4: Error: syntax error; missing ')' after base register
4: Error: syntax error; expected ','
4: Error: operand out of range (32 is not between 0 and 15)
4: Error: syntax error; missing ')' after base register
4: Error: junk at end of line: `%r2)'
5: Error: syntax error; missing ')' after base register
5: Error: syntax error; expected ','
5: Error: operand out of range (32 is not between 0 and 15)
5: Error: syntax error; missing ')' after base register
5: Error: junk at end of line: `%r2'
Assembler messages with commit:
1: Error: bad expression
1: Error: syntax error; missing ')' after base register
2: Error: syntax error; missing ')' after base register
4: Error: bad expression
4: Error: syntax error; missing ')' after base register
5: Error: syntax error; missing ')' after base register
5: Error: syntax error; missing ')' after base register
gas/
* config/tc-s390.c: Do not erroneously consume newline when
parsing an addressing operand with parentheses.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 11:45:14 +0000 (12:45 +0100)]
s390: Lower severity of assembler syntax errors from fatal to error
Report s390 assembler syntax errors as error instead of fatal error.
This allows the assembler to continue and potentially report further
syntax errors in the source. This should not cause syntax errors to
be erroneously accepted, as both error and fatal error cause the
assembler to return with a non-zero return code.
The following syntax errors are changed from fatal to error:
- invalid length field specified
- odd numbered general purpose register specified as register pair
- invalid floating point register pair. Valid fp register pair operands
are 0, 1, 4, 5, 8, 9, 12 or 13.
gas/
* config/tc-s390.c: Lower severity of assembler syntax errors
from fatal to error.
* testsuite/gas/s390/zarch-z9-109-err.l: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 1 Mar 2024 10:12:40 +0000 (11:12 +0100)]
s390: Use proper string lengths when parsing opcode table flags
opcodes/
* s390-mkopc.c: Use proper string lengths when parsing opcode
table flags.
Fixes: c5306fed7d4 ("s390: Support for jump visualization in disassembly") Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Jan Beulich [Fri, 1 Mar 2024 08:25:59 +0000 (09:25 +0100)]
x86: adjust which Dwarf2 register numbers to use
Consumers can't know which execution mode is in effect for a certain
piece of code; they can only go from object file properties. Hence which
register numbers to encode ought to depend solely on object file type.
In tc_x86_frame_initial_instructions() do away with parsing a register
name: We have a symbolic constant already for the 64-bit case, and the
32-bit number isn't going to change either. Said constant's definition
needs moving, though, to be available also for non-ELF. While moving
also adjust the comment to clarify that it's applicable to 64-bit mode
only.
SVE2.1 support is both incomplete and buggy. SME2.1 "support" goes as
far as a single instruction (a subset of movaz forms) only. The SME part
of B16B16 is entirely missing.
projects / thirdparty / binutils-gdb.git / log
