the offset-to-entry mappings are allocated in blocks, which may
become a bit wasteful in case there are extremely many small
input files or sections. This made it so that a large project
(Qt5WebEngine) didn't build anymore on x86 32bit due to address
space limits. It barely fit into address space before the new
string merging, and then got pushed over the limit by this.
So instead of leaving the waste reallocate the maps to their final
size once known. Now the link barely fits again.
bfd/
* merge.c (record_section): Reallocate offset maps to their
final size.
as the bug report shows we had an overflow in the test if
hash table resizing is needed. Reorder the expression to avoid
that. There's still a bug somewhere in gracefully handling
failure in resizing (e.g. out of memory), but this pushes the
boundary for that occurring somewhen into the future and
immediately helps the reporter.
bfd/
PR ld/31009
* merge.c (NEEDS_RESIZE): New macro avoiding overflow.
(sec_merge_maybe_resize): Use it.
(sec_merge_hash_insert): Ditto.
The tests are not compatible with ilp32 abi: the GNU property
note is ABI dependent (size changes) and the disasm is ABI
dependent too. Making the test portable between the ABIs is
not trivial.
For now force lp64 abi.
We decide to emit BTI stubs based on the instruction at the target
location. But PLT code is generated later than the stubs so we always
read 0 which is not a valid BTI.
Fix the logic to special case the PLT section: this is code the linker
generates so we know when it will have BTI.
This avoids BTI stubs in large executables where the PLTs have them
already. An alternative is to never emit BTI stubs for PLTs, instead
use BTI in the PLT if a library gets too big, however that may be
more tricky given the ordering of PLT sizing and stub insertion.
Related to bug 30957.
BTI stub parameters were recomputed even if those were already set up.
This is unnecessary work and leaks the symbol name that is allocated
for the stub.
Input sections are grouped together that can use the same stub area
(within reach) and these groups have a stable id.
Stubs have a name generated from the stub group id and target symbol.
When a relocation requires a stub with a name that already exists, the
stub is reused instead of adding a new one.
For an indirect branch stub another BTI stub may be inserted near the
target to provide a BTI landing pad.
The BTI stub can end up with the same stub group id and thus the same
name as the indirect stub. This happens if the target symbol is within
reach of the indirect branch stub. Then, due to the name collision,
only a single stub was emmitted which branched to itself causing an
infinite loop at runtime.
A possible solution is to just name the BTI stubs differently, but
since in the problematic case the indirect and BTI stub are in the
same stub area, a better solution is to emit a single stub with a
direct branch. The stub is still needed since the caller cannot reach
the target directly and we also want a BTI landing pad in the stub in
case other indirect stubs target the same symbol and thus need a BTI
stub.
In short we convert an indirect branch stub into a BTI stub when the
target is within reach and has no BTI. It is a hassle to change the
symbol of the stub so a BTI stub may end up with *_veneer instead of
*_bti_veneer after the conversion, but this should not matter much.
(Refactoring some of _bfd_aarch64_add_call_stub_entries would be
useful but too much for this bug fix patch.)
The same conversion to direct branch could be done even if the target
did not need a BTI. The stub groups are fixed in the current logic so
linking can fail if too many stubs are inserted and the section layout
is changed too much, but this only happens in extreme cases that can
be reasonably ignored. Because of this the target cannot go out of
reach during stub insertion so the optimization is valid, but not
implemented by this patch for the non-BTI case.
Fixes bug 30930.
The instruction was looked up in the wrong input file (file of branch
source instead of branch target) when optimizing away BTI stubs in
commit 5834f36d93
bfd: aarch64: Optimize BTI stubs PR30076
This can cause adding BTI stubs when they are not necessary or removing
them when they are (the latter is a correctness issue but it is very
unlikely in practice).
Fixes bug 30957.
The erroneous omission of a "reg_value == " in the THE system register
encoding check added in [1] led to an error which was not picked up in
GCC but which was flagged in Clang due to its use of
[-Werror,-Wconstant-logical-operand] check. Together with this fix we
add a new test for the THE registers to pick up their illegal use,
adding an extra and important layer of validation.
Furthermore, in separating system register from instruction
implementation (with which only the former was of concern in the cited
patch), additions made to `aarch64-tbl.h' are rolled back so
that these can be added later when adding THE instructions to the
codebase, a more natural place for these changes.
[1] https://sourceware.org/pipermail/binutils/2023-November/130314.html
opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Fix typo.
* aarch64-tbl.h (THE): Remove.
(aarch64_feature_set aarch64_feature_the): Likewise.
gas/ChangeLog:
* testsuite/gas/aarch64/illegal-sysreg-8.l: Add tests for THE
system registers.
* testsuite/gas/aarch64/illegal-sysreg-8.s: Likewise.
As we have grown more uses of it, it becomes increasingly more desirable
to replace it by a simpler check. Have i386-gen do at build time what so
far was done at runtime: Deal with templates indicating EVEX-encoding by
other than the EVex attribute, and set that to "dynamic" in such cases.
This then allows simplifying a number of other conditionals as well.
Right now the opcode table has entries with ISA restrictions of the form
FEAT1|FEAT2, the meaning of which depends on context and requires
special treatment in tc-i386.c: Sometimes this means "both features
requires", whereas originally it was intended to solely mean "all of
these features required". Split the field, with the original one
regaining its original meaning. The new field now truly means "any of
these". The combination of both fields is still and &&-type check, i.e.
(all of these) && (any of these). In the opcode table more involved
combinations of features then also need expressing this way: "all"
entities first, follow by "any" entities enclosed in parentheses, e.g.
x64&(AVX|AVX512F). If the "all" part is empty, parentheses may not be
added around the "any" part (unless parsing logic was further relaxed).
Note that this way AVX512VL no longer needs as much special treatment,
and hence templates previously using AVX512F|AVX512VL are switched to
just AVX512VL.
Note further that this requires FMA handling as resulting from
da0784f961 ("x86: fold FMA VEX and EVEX templates") to be slightly
re-done: FMA now becomes more similar to AVX and AVX2.
First of all we want to also accumulate its reverse dependencies, such
that we can use them in cpu_flags_match(). This is in particular in
preparation of APX additions, such that e.g. BMI VEX-encoding templates
can become combined VEX/EVEX ones.
Once we have the reverse dependencies, we can further leverage them to
omit explicit "&x64" from any insn templates dealing with 64-bit-mode-
only ISA extensions. Besides helping readability for several insn
templates we already have, this will also help with what is going to be
added for APX (as all of the new templates would otherwise need to have
"&x64").
Note that rather than leaving a meaningless CPU_64_FLAGS (which is
unused anyway), its emitting is now also suppressed.
The test currently fails for IEEE 128-bit floating point types. PowerPC
supports the IBM double 128-bit floating point format and IEEE 128-bit
format. The IBM double 128-bit floating point format uses two 64-bit
floating point registers to store the 128-bit value. The IEEE 128-bit
floating point format stores the value in a single 128-bit vector-scalar
register (vsr).
The various floating point values, 32-bit float, 64-bit double, IBM double
128-bit float and IEEE 128-bit floating point numbers are all mapped to the
DWARF fpr numbers. The issue is the IEEE 128-bit floating point values are
actually stored in a vsr not the fprs. This patch changes the register
mapping for the vsrs from the fpr to the vsr registers so the value is
properly accessed by GDB. The functions rs6000_linux_register_to_value,
rs6000_linux_value_to_register, rs6000_linux_value_from_register check if
the value is an IEEE 128-bit floating point value and adjust the register
number as needed. The test in function rs6000_convert_register_p is fixed
so it is only true for floating point values.
This patch fixes three regression tests in gdb.base/store.exp.
The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
with no regressions.
Overview of issues fixed by the patch.
The primary issue this patch fixes is the DWARF register mapping for
Linux. The changes in ppc-linux-tdep.c fix the DWARF register mapping
issues. The register mapping issue is responsible for two of the
five regression bugs seen in gdb.base/store.exp.
Once the register mapping was fixed, an underlying issue with the unwinding
of the signal trampoline in common-code in ifrun.c was found. This
underlying bug is best described by Ulrich in the following description.
The unwinder bug shows up on platforms where the kernel uses a trampoline
to dispatch "calls to" the signal handler (not just *returns from* the
signal handler). Many platforms use a trampoline for signal return, and
that is working fine, but the only platform I'm (Ulrich) aware of that
uses a trampoline for signal handler calls is (recent kernels for)
PowerPC. I believe the rationale for using a trampoline here
is to improve performance by avoiding unbalancing of the
branch predictor's call/return stack.
However, on PowerPC the bug is dormant as well as it is hidden
by *another* bug that prevents correct unwinding out of the
signal trampoline. This is because the custom CFI for the
trampoline uses a register number (VSCR) that is not ever used
by compiler-generated CFI, and that particular register is
mapped to an invalid number by the current PowerPC DWARF mapper.
The underlying unwinder bug is exposed by the "new" regression failures
in gdb.base/sigstep.exp. These failures were previously masked by
the fact that GDB was not seeing a valid frame when it tried to unwind
the frames. The sigstep.exp test is specifically testing stepping into
a signal handler. With the correct DWARF register mapping in place,
specifically the VSCR mapping, the signal trampoline code now unwinds to a
valid frame exposing the pre-existing bug in how the signal handler on
PowerPC works. The one line change infrun.c fixes the exiting bug in
the common-code for platforms that use a trampoline to dispatch calls
to the signal handler by not stopping in the SIGTRAMP_FRAME.
Detailed description of the DWARF register mapping fix.
The PowerPC DWARF register mapping is the same for the .eh_frame and
.debug_frame on Linux. PowerPC uses different mapping for .eh_frame and
.debug_frame on other operating systems. The current GDB support for
mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and
rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux.
The files have some legacy mappings for spe_acc, spefscr, EV which was
removed from GCC in 2017.
This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum,
and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle
the DWARF register mappings on Linux. Function
rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum
and gdbarch_stab_reg_to_regnum since the mappings are the same.
The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to
call set_gdbarch_dwarf2_reg_to_regnum map the new function
rs6000_linux_dwarf2_reg_to_regnum for the architecture. Similarly,
dwarf2_frame_set_adjust_regnum is called to map
rs6000_linux_adjust_frame_regnum into the architecture.
Additional detail on the signal handling fix.
The specific sequence of events for handling a signal on most
architectures is as follows:
1) Some code is running when a signal arrives.
2) The kernel handles the signal and dispatches to the handler.
...
However on PowerPC the sequence of events is:
1) Some code is running when a signal arrives.
2) The kernel handles the signal and dispatches to the trampoline.
3) The trampoline performs a normal function call to the handler.
...
We want the "nexti" to step into, not over, signal handlers invoked by
the kernel. This is the case for most platforms as the kernel puts a
signal trampoline frame onto the stack to handle proper return after the
handler. However, on some platforms such as PowerPC, the kernel actually
uses a trampoline to handle *invocation* of the handler. We do not
want GDB to stop in the SIGTRAMP_FRAME. The issue is fixed in function
process_event_stop_test by adding a check that the frame is not a
SIGTRAMP_FRAME to the if statement to stop in a subroutine call. This
prevents GDB from erroneously detecting the trampoline invocation as a
subroutine call.
This patch fixes two regression test failures in gdb.base/store.exp.
The patch then fixes an exposed, dormant, signal handling issue that
is exposed in the signal handling test gdb.base/sigstep.exp.
The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with
no new regressions. Note, only two of the five failures in store.exp
are fixed. The remaining three failures are fixed in a following
patch.
I noticed that if GDB is using a remote or extended-remote target,
then, if an inferior call caused a new thread to appear, or for an
existing thread to exit, then these events are not reported to the
user.
The problem is that for these targets GDB relies on a call to
update_thread_list to learn about changes to the inferior's thread
list.
If GDB doesn't pass through the normal stop code then GDB will not
call update_thread_list, and so will not report changes in the thread
list.
This commit adds an additional update_thread_list call, after which
thread events are correctly reported.
I noticed that sometimes the value returned by $_inferior_thread_count
can become out of sync with the actual thread count of the inferior,
and will disagree with the number of threads reported by 'info
threads'. This commit fixes this issue.
The cause of the problem is that 'info threads' includes a call to
update_thread_list, this can be seen in print_thread_info_1 in
thread.c, while $_inferior_thread_count doesn't include a similar
call, see the function inferior_thread_count_make_value also in
thread.c.
Of course, this is only a problem when GDB is running on a target that
relies on update_thread_list calls to learn about new threads,
e.g. remote or extended-remote targets. Native targets generally
learn about new threads as soon as they appear and will not have this
problem.
I ran into this issue when writing a test for the next commit which
uses inferior function calls to add an remove threads from an
inferior. But for testing I've made use of non-stop mode and
asynchronous inferior execution; by reading the inferior state I can
know when a new thread has been created, at which point I can print
$_inferior_thread_count while the inferior is still running. This is
important, if I stop the inferior then GDB will pass through an
update_thread_list call in the normal stop code, which will
synchronise the thread list, after which $_inferior_thread_count will
report the correct value.
With this change in place $_inferior_thread_count is now correct.
Add a new command completer function for the disassemble command.
There are two things that this completion function changes. First,
after the previous commit, the new function calls skip_over_slash_fmt,
which means that hitting tab after entering a /OPT flag now inserts a
space ready to start typing the address to disassemble at:
(gdb) disassemble /r<TAB>
(gdb) disassemble /r <CURSOR>
But also, we now get symbol completion after a /OPT option set,
previously this would do nothing:
(gdb) disassemble /r mai<TAB>
But now:
(gdb) disassemble /r mai<TAB>
(gdb) disassemble /r main <CURSOR>
Which was my main motivation for working on this commit.
However, I have made a second change in the completion function.
Currently, the disassemble command calls the generic
location_completer function, however, the disassemble docs say:
Note that the 'disassemble' command's address arguments are specified
using expressions in your programming language (*note Expressions:
Expressions.), not location specs (*note Location Specifications::).
So, for example, if you want to disassemble function 'bar' in file
'foo.c', you must type 'disassemble 'foo.c'::bar' and not 'disassemble
foo.c:bar'.
And indeed, if I try:
(gdb) disassemble hello.c:main
No symbol "hello" in current context.
(gdb) disassemble hello.c::main
No symbol "hello" in current context.
(gdb) disassemble 'hello.c'::main
Dump of assembler code for function main:
... snip ...
But, if I do this:
(gdb) disassemble hell<TAB>
(gdb) disassemble hello.c:<CURSOR>
which is a consequence of using the location_completer function. So
in this commit, after calling skip_over_slash_fmt, I forward the bulk
of the disassemble command completion to expression_completer. Now
when I try this:
(gdb) disassemble hell<TAB>
gives nothing, which I think is an improvement. There is one slight
disappointment, if I do:
(gdb) disassemble 'hell<TAB>
I still get nothing. I had hoped that this would expand to:
'hello.c':: but I guess this is a limitation of the current
expression_completer implementation, however, I don't think this is a
regression, the previous expansion was just wrong. Fixing
expression_completer is out of scope for this commit.
I've added some disassembler command completion tests, and also a test
that disassembling using 'FILE'::FUNC syntax works, as I don't think
that is tested anywhere.
Move the function skip_over_slash_fmt into completer.c, and make it
extern, with a declaration in completer.h.
This is a refactor in order to support the next commit. I've not
changed any of the code in skip_over_slash_fmt.
There should be no user visible changes after this commit.
The disassembler gained a new /b flag in this commit:
commit d4ce49b7ac
Date: Tue Jun 21 20:23:35 2022 +0100
gdb: disassembler opcode display formatting
The /b and /r flags result in the instruction opcodes displayed in
different formats, so it's not possible to have both at the same
time. Currently the /b flag overrides the /r flag.
We have a similar situation with the /m and /s flags, but here, if the
user tries to use both flags then they will get an error.
I think the error is clearer, so in this commit I propose that we add
an error if /r and /b are both used.
Obviously this change breaks backwards compatibility. I don't have a
compelling argument for why we should make the change beyond my
feeling that it was a mistake not to add this error from the start,
and that the new behaviour is better.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
In a safety context, it could interesting to track the trampolines being
generated, ensuring there are expected or not.
bfd/ChangeLog:
* elf32-ppc.c (ppc_elf_relax_section): Log branch fixups.
ld/ChangeLog:
* ld.texi (--print-map): Add new item about fixups.
This patch provides some minimal thread-safety to BFD.
The BFD client can request thread-safety by providing a lock and
unlock function. The globals used during BFD creation (e.g.,
bfd_id_counter) are then locked, and the file descriptor cache is also
locked. A function to clean up any thread-local data is now provided
for BFD clients.
* bfd-in2.h: Regenerate.
* bfd.c (lock_fn, unlock_fn): New globals.
(bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New
functions.
* cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked.
(cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock
and unlock.
(cache_bclose): Add comment.
(cache_bflush, cache_bstat, cache_bmmap): Lock and unlock.
(_bfd_cache_init_unlocked): New function.
(bfd_cache_init): Use it. Lock and unlock.
(_bfd_cache_close_unlocked): New function.
(bfd_cache_close, bfd_cache_close_all): Use it. Lock and unlock.
(_bfd_open_file_unlocked): New function.
(bfd_open_file): Use it. Lock and unlock.
* doc/bfd.texi (BFD front end): Add Threading menu item.
* libbfd.h: Regenerate.
* opncls.c (_bfd_new_bfd): Lock and unlock.
* po/bfd.pot: Regenerate.
This makes _bfd_error_buf static and adds a way to clear it. I felt
that this made the subsequent patches a little cleaner.
* bfd.c (_bfd_error_buf): Now static.
(bfd_set_input_error): Use _bfd_clear_error_data.
(_bfd_clear_error_data): New function.
(bfd_init): Use _bfd_clear_error_data.
* libbfd.h: Regenerate.
* opncls.c (bfd_close_all_done): Use _bfd_clear_error_data.
* po/bfd.pot: Regenerate.
Enable the `+lse128' feature modifier which, together with new
internal feature flags, enables LSE128 instructions, which are
represented via the new `_LSE128_INSN' macro.
gas/ChangeLog:
* config/tc-aarch64.c (aarch64_features): Add new "lse128"
entry.
include/ChangeLog:
* include/opcode/aarch64.h (enum aarch64_feature_bit): New
AARCH64_FEATURE_LSE128 feature bit.
(enum aarch64_insn_class): New lse128_atomic instruction class.
opcodes/ChangeLog:
* opcodes/aarch64-tbl.h (aarch64_feature_lse128): New.
(LSE128): Likewise.
(_LSE128_INSN): Likewise.
Given the particular encoding of the LSE128 instructions, create the
necessary shared input+output operand register description and
handling in the code to allow for the encoding of the LSE128 128-bit
atomic operations.
gas/ChangeLog:
* config/tc-aarch64.c (parse_operands):
include/ChangeLog:
* opcode/aarch64.h (enum aarch64_opnd):
opcodes/ChangeLog:
* aarch64-opc.c (fields):
(aarch64_print_operand):
* aarch64-opc.h (enum aarch64_field_kind):
* aarch64-tbl.h (AARCH64_OPERANDS):
In preparation for the implementation of 128-bit system register
support across the toolchain, this patch adds the feature flag
F_REG_128 and adds it to relevant system registers in
`aarch64-sys-regs.def'.
Given the shared nature of this file, this change is made necessary
initially to implement argument validation in the `__arm_rsr128' and
`__armwsr128' ACLE intrinsics in GCC, but will be of subsequent use in
the binutils implementation of the corresponding `mrrs' and `msrr'
instructions.
Regression tested on aarch64-linux-gnu, no regressions.
opcodes/ChangeLog:
* aarch64-opc.h (F_REG_128): New flag.
* aarch64-sys-regs.def (par_el1): Add F_REG_128 flag.
(rcwmask_el1): Likewise.
(rcwsmask_el1): Likewise.
(ttbr0_el1): Likewise.
(ttbr0_el12): Likewise.
(ttbr0_el2): Likewise.
(ttbr1_el1): Likewise.
(ttbr1_el12): Likewise.
(ttbr1_el2): Likewise.
(vttbr_el2): Likewise.
Add Binutils support for system registers associated with the
Translation Hardening Extension (THE).
In doing so, we also add core feature support for THE, enabling its
associated feature flag and implementing the necessary
feature-checking machinery.
Regression tested on aarch64-linux-gnu, no regressions.
gas/ChangeLog:
* config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier.
* doc/c-aarch64.texi (AArch64 Extensions): Update
documentation for `the' option.
* testsuite/gas/aarch64/sysreg-8.s: Add tests for `the'
associated system registers.
* testsuite/gas/aarch64/sysreg-8.d: Likewise.
include/ChangeLog:
* opcode/aarch64.h (enum aarch64_feature_bit): Add
AARCH64_FEATURE_THE.
opcode/ChangeLog:
* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the'
system register check support.
* aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1'
* aarch64-tbl.h: Define `THE' preprocessor macro.
When compiling gdb with -fsanitize=address on ARM, I get a crash in test
gdb.arch/arm-disp-step.exp, reproduced easily with:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
=================================================================
==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494
Since it doesn't require running the program, it can be reproduced locally on a
dev machine other than ARM, after acquiring the test binary.
The length of the allocate buffer `buf` is 1, and we try to extract an
integer of size 2 from it. The length of 1 comes from the subtraction
`bpaddr - boundary`. Normally, on ARM, all instructions are aligned on
a multiple of 2, so it's weird for this subtraction to result in 1. In
this case, boundary comes from the result of find_pc_partial_function
returning 0x549:
(gdb) p/x bpaddr
$2 = 0x54a
(gdb) p/x boundary
$3 = 0x549
(gdb) p/x bpaddr - boundary
$4 = 0x1
0x549 is the address of the test_call_subr label, 0x548, with the thumb
bit enabled. Before doing some math with the address, I think we need
to strip the thumb bit, like is done elsewhere (for instance for bpaddr
earlier in the same function).
I wonder if find_pc_partial_function should do that itself, in order to
return an address that is suitable for arithmetic. In any case, that
would be a change with a broad impact, so for now just fix the issue
locally.
After the patch:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103.
Change-Id: I74fc458dbea0d2c1e1f5eadd90755188df089288
Approved-By: Luis Machado <luis.machado@arm.com>
PR ld/30722
Tests looking for certain .note-section recorded properties may not
involve object files from the underlying platform (e.g. via using the C
compiler for linking): Such object files may themselves have similar
note sections, and hence they may influence the overall outcome.
For now convert just the tests known to be affected by crt*.o coming
with "ISA v3 needed" notes. Eventually other tests ought to be
converted, too.
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
Contributors:
Mary Bennett <mary.bennett@embecosm.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu`
instruction class.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Added the necessary
operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCValu as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/cv-alu-boundaries.d: New test.
* testsuite/gas/riscv/cv-alu-boundaries.l: New test.
* testsuite/gas/riscv/cv-alu-boundaries.s: New test.
* testsuite/gas/riscv/cv-alu-fail-march.d: New test.
* testsuite/gas/riscv/cv-alu-fail-march.l: New test.
* testsuite/gas/riscv/cv-alu-fail-march.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test.
* testsuite/gas/riscv/cv-alu-insns.d: New test.
* testsuite/gas/riscv/cv-alu-insns.s: New test.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Disassemble xcb operand.
* riscv-opc.c: Defined the MASK and added XCValu instructions.
include/ChangeLog:
* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
for XCValu.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
for XCValu.
(enum riscv_insn_class): Added the XCValu instruction class.
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
Contributors:
Mary Bennett <mary.bennett@embecosm.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac`
instruction class.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Added the necessary
operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCVmac as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/cv-mac-fail-march.d: New test.
* testsuite/gas/riscv/cv-mac-fail-march.l: New test.
* testsuite/gas/riscv/cv-mac-fail-march.s: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.d: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.l: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.s: New test.
* testsuite/gas/riscv/cv-mac-insns.d: New test.
* testsuite/gas/riscv/cv-mac-insns.s: New test.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Disassemble information with
the EXTRACT macro implemented.
* riscv-opc.c: Defined the MASK and added
XCVmac instructions.
include/ChangeLog:
* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
for XCVmac.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
for uimm.
(enum riscv_insn_class): Added the XCVmac instruction class.
common-defs.h has a few defines that I suspect were used during the
transition to C++. These aren't needed any more, so remove them.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
When resizing from a big to small terminal size, and you have a
TUI python window that would then be outside of the new size,
valgrind shows this error:
==3389== Invalid read of size 1
==3389== at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167)
==3389== by 0xC3E3C9: wrefresh (lib_refresh.c:63)
==3389== by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134)
==3389== by 0x98921C: tui_py_window::rerender() (py-tui.c:183)
==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389== by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033)
==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389== by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81)
==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389== Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd
==3389== at 0x4A0A430: free (vg_replace_malloc.c:446)
==3389== by 0xC3CF7D: _nc_freewin (lib_newwin.c:121)
==3389== by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78)
==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389== by 0x8E40E9: captured_command_loop() (main.c:407)
==3389== by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324)
==3389== by 0x62AC04: main (gdb.c:39)
It's because tui_py_window::m_inner_window still has the outside
coordinates, and wnoutrefresh then does an out-of-bounds access.
Fix this by resetting m_inner_window on every resize, it will anyways
be recreated in the next rerender call.
Approved-By: Andrew Burgess <aburgess@redhat.com>
In AIX unused or constant variables are collected as garbage by the linker and in the dwarf dump
an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures stating
it cannot access memory.
This patch is a small change to get it working in AIX as well.
