We already use unique_ptr with notif_event and stop_reply in some
places around the remote target, but not fully. There are several
code paths that still use raw pointers. This commit makes all of the
ownership of these objects tracked by unique pointers, making the
lifetime flow much more obvious, IMHO.
I notice that it fixes a leak -- in remote_notif_stop_ack, We weren't
destroying the stop_reply object if it was of TARGET_WAITKIND_IGNORE
kind.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Id81daf39653d8792c8795b2a145772176bfae77c
struct cached_reg_t owns its data buffer, but currently that is
managed manually. Convert it to use a unique_xmalloc_ptr.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I05a107098b717299e76de76aaba00d7fbaeac77b
tdesc_data is not part of a union, since commit 4f3681cc33 ("Fix thread's
gdbarch when SVE vector length changes"). Remove the stale comment and
constructor.
Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503
Suffix the instruction description of conditional branch extended
mnemonics with their condition (e.g. "on A high"). This complements
the optional printing of instruction descriptions as comments in the
disassembly.
Due to the added text the maximum description length is increased from
80 to 128 characters (including the trailing '\0' character).
opcodes/
* s390-mkopc.c: Add suffix to conditional branch extended
mnemonic instruction descriptions.
gas/
* testsuite/gas/s390/zarch-insndesc.s: Add test cases for
printing of suffixed instruction description of conditional
branch extended mnemonics.
* testsuite/gas/s390/zarch-insndesc.d: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Print instruction description as comment in disassembly with s390
architecture specific option "insndesc":
- For objdump it can be enabled with option "-M insndesc"
- In gdb it can be enabled with "set disassembler-options insndesc"
Since comments are not column aligned the output can enhanced for
readability by postprocessing using a filter such as "expand":
... | expand -t 8,16,24,32,40,80
Or when using in combination with objdump option --visualize-jumps:
... | expand | sed -e 's/ *#/\t#/' | expand -t 1,80
Note that the instruction descriptions add about 128 KB to s390-opc.o:
s390-opc.o without instruction descriptions: 216368 bytes
s390-opc.o with instruction descriptions : 348432 bytes
binutils/
* NEWS: Mention new s390-specific disassembler option
"insndesc".
include/
* opcode/s390.h (struct s390_opcode): Add field to hold
instruction description.
opcodes/
* s390-mkopc.c: Copy instruction description from s390-opc.txt
into generated operation code table s390-opc.tab.
* s390-opc.c (s390_opformats): Provide NULL as description in
.insn pseudo-mnemonics opcode table.
* s390-dis.c: Add s390-specific disassembler option "insndesc"
and optionally print the instruction description as comment in
the disassembly when it is specified.
gas/
* testsuite/gas/s390/s390.exp: Add new test disassembly test
case "zarch-insndesc".
* testsuite/gas/s390/zarch-insndesc.s: New test case for s390-
specific disassembler option "insndesc".
* testsuite/gas/s390/zarch-insndesc.d: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Use strncpy() and snprintf() instead of strcpy() and strcat(). Define
and use macros for string lengths, such as mnemonic, instruction
format, and instruction description.
This is a mechanical change, although some buffers have increased in
length by one character. This has been confirmed by verifying that the
generated opcode/s390-opc.tab is unchanged.
opcodes/
* s390-mkopc.c: Use strncpy() and strncat().
Suggested-by: Nick Clifton <nickc@redhat.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
When the s390-mkopc utility detects an error it prints an error message
to strerr and either continues processing or exists with a non-zero
return code. If it continues without detecting any further error the
final return code was zero, potentially hiding the detected error.
Introduce a global variable to hold the final return code and initialize
it to EXIT_SUCCESS. Introduce a helper function print_error() that
prints an error message to stderr and sets the final return code to
EXIT_FAILURE. Use it to print all error messages. Return the final
return code at the end of the processing.
While at it enhance error messages to state more clearly which mnemonic
an error was detected for. Also continue processing for cases where
subsequent mnemonics can be processed.
opcodes/
* s390-mkopc.c: Enhance error handling. Return EXIT_FAILURE
in case of an error, otherwise EXIT_SUCCESS.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Provide descriptions for instructions introduced with commit ba2b480f10
("IBM Z: Implement instruction set extensions"). This complements commit
69341966de ("IBM zSystems: Add support for z16 as CPU name."). Use
instruction names from IBM z/Architecture Principles of Operation [1] as
instruction description.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
opcodes/
* s390-opc.txt: Add descriptions for IBM z16 (arch14)
instructions.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Change the bitwise operations names "and" and "or" to lower case. Change
the register name abbreviations "FPR", "GR", and "VR" to upper case.
opcodes/
* s390-opc.txt: Align letter case of instruction descriptions.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Suffix the s390-mkopc build utility executable file name with
EXEEXT_FOR_BUILD. Otherwise it cannot be located when building with
EXEEXT_FOR_BUILD. Use pattern used for other architecture build
utilities and compile and link s390-mkopc in two steps.
While at it also specify the dependencies of s390-mkopc.c.
opcodes/
* Makefile.am: Add target to build s390-mkopc.o. Correct
target to build s390-mkopc$(EXEEXT_FOR_BUILD).
* Makefile.in: Regenerate.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Fix one minor pointer-sign warning to enable warnings in general
for this file. Reading the data as signed and then returning it
as unsigned should be functionally the same in this case.
Revert most of this patch, it isn't correct to free the BFD_IN_MEMORY
iostream in io_reinit.
PR 31145
* format.c (io_reinit): Revert last change. Comment.
* opncls.c (_bfd_delete_bfd): Likewise.
Here, we write single complete registers, we don't need the
functionality of put_frame_register_bytes, use put_frame_register
instead.
Change-Id: I987867a27249db4f792a694b47ecb21c44f64d08
Approved-By: Tom Tromey <tom@tromey.com>
This comment is no longer relevant, put_frame_register_bytes now accepts
the "next frame".
Change-Id: I077933a03f8bdb886f8ba10a98d1202a38bce0a9
Approved-By: Tom Tromey <tom@tromey.com>
This patch add support for FEAT_ECBHB "Exploitative control using
branch history information" adding the "clrbhb" instruction. AFAIU
the same alias was originally added as "clearbhb" before the
architecture was finalized (Mandatory v8.9-a/v9.4-a; Optional
v8.0-a+/v9.0-a+).
This patch add supports for FEAT_SPECRES2 "Enhanced speculation
restriction instructions" adding the "cosp" instruction.
This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+. It is
enabled by the +predres2 march flag.
gdbarches usually register functions to check when a frame is destroyed
which is used with software watchpoints, since the expression of the
watchpoint is no longer vlaid at this point. On amd64, this wasn't done
anymore because GCC started using CFA for variable locations instead.
However, clang doesn't use the CFA and instead relies on specifying when
an epilogue has started, meaning software watchpoints get a spurious hit
when a frame is destroyed. This patch re-adds the code to register the
function that detects when a frame is destroyed, but only uses this when
the producer is LLVM, so gcc code isn't affected. The logic that
identifies the epilogue has been factored out into the new function
amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it
directly, and its behavior isn't changed.
This can also remove the XFAIL added to gdb.python/pq-watchpoint tests
that handled this exact flaw in clang.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Since AVX10.1/256 will also allow 64 bit mask register, we will
remove the restriction for size of the mask register in AVX10.
gas/ChangeLog:
* config/tc-i386.c (VSZ128, VSZ256, VSZ512): New.
(VEX_check_encoding): Remove opcode_modifier check for vsz.
* testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask
registers since they are not needed.
* testsuite/gas/i386/avx10-vsz.s: Ditto.
opcodes/ChangeLog:
* i386-gen.c: Remove Vsz.
* i386-opc.h: Ditto.
* i386-opc.tbl: Remove kvsz.
* i386-tbl.h: Regenerated.
Even in shared objects, la.got -> la.pcrel relaxation can still be
performed for symbols with hidden visibility. For example, if a.c is:
extern int x;
int f() { return x++; }
and b.c is:
int x = 114514;
If compiling and linking with:
gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c
Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f
should be like:
pcaddi $t0, x
ldptr.w $a0, $t0, 0
addi.w $t1, $a0, 1
stptr.w $t1, $t0, 0
ret
Remove bfd_link_executable from the condition of la.got -> la.pcrel
relaxation so this will really happen. The SYMBOL_REFERENCES_LOCAL
check is enough not to wrongly relax preemptable symbols (for e.g.
when -fvisibility=hidden is not used).
Note that on x86_64 this is also relaxed and the produced code is like:
lea x(%rip), %rdx
mov (%rdx), %rax
lea 1(%rax), %ecx
mov %ecx, (%rdx)
ret
Tested by running ld test suite, bootstrapping and regtesting GCC with
the patched ld, and building and testing Glibc with the patched ld. No
regression is observed.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
This came up testing the CRC optimization work from Mariam@RAU.
Basically to optimize some CRC loops into table lookups or carryless
multiplies, we may need to do a bit reflection, which on the mcore
processor is done using a rotate instruction.
Unfortunately the simulator implementation of rotates has the exact same
problem as we saw with right shifts. The input value may have been sign
extended from 32 to 64 bits. When we rotate the extended value, we get
those sign extension bits and thus the wrong result.
The fix is the same. Rather than using a "long", use a uint32_t for the
type of the temporary. This fixes a handful of tests in the GCC testsuite:
This fixes issues reported by David Edelsohn <dje.gcc@gmail.com>, and by
Eric Gallager <egallager@gcc.gnu.org>.
ChangeLog:
* Makefile.def (gettext): Disable (via missing)
{install-,}{pdf,html,info,dvi} and TAGS targets. Set no_install
to true. Add --disable-threads --disable-libasprintf.
* Makefile.in: Regenerate.
When using --print-memory-usage, the printed size can be zero and in
that case, the unit should be B and not GB.
ld/
* ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB.
* testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region.
* testsuite/ld-scripts/print-memory-usage-1.t: Define empty region.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
This isn't a particularly worrying memory leak, but fix it anyway.
PR 31162
* ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc.
Add %E to error messages.
The gdb.threads/thread-specific-bp.exp test has been a little
problematic, see commits:
commit 89702edd93
Date: Thu Mar 9 12:31:26 2023 +0100
[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver
and
commit 2e5843d87c
Date: Fri Nov 19 14:33:39 2021 +0100
[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp
But I recently saw a test failure for that test, which looked like
this:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected
continue -a
Continuing.
Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
29 }
(gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
...
This only crops up (for me) when running on a loaded machine, and
still only occurs sometimes. I've had to leave the test running in a
loop for 10+ minutes sometimes in order to see the failure.
The problem is that we use gdb_test_multiple to try and match two
patterns:
(1) The 'Thread-specific breakpoint 3 deleted ....' message, and
(2) The GDB prompt.
As written in the test, we understand that these patterns can occur in
any order, and we have a flag for each pattern. Once both patterns
have been seen then we PASS the test.
The problem is that once expect has matched a pattern, everything up
to, and including the matched text is discarded from the input
buffer. Thus, if the input buffer contains:
<PATTERN 2><PATTERN 1>
Then expect will first try to match <PATTERN 1>, which succeeds, and
then expect discards the entire input buffer up to the end of the
<PATTERN 1>. As a result, we will never spot <PATTERN 2>.
Obviously we can't just reorder the patterns within the
gdb_test_multiple, as the output can legitimately (and most often
does) occur in the other order, in which case the test would mostly
fail, and only occasionally pass!
I think the easiest solution here is just to have the
gdb_test_multiple contain two patterns, each pattern consists of the
two parts, but in the alternative orders, thus, for a particular
output configuration, only one regexp will match. With this change in
place, I no longer see the intermittent failure.
Approved-By: Tom Tromey <tom@tromey.com>
