Xi Ruoyao [Mon, 12 Aug 2024 10:23:47 +0000 (18:23 +0800)]
LoongArch: Fix DT_RELR and relaxation interaction
Due to the way BFD implements DT_RELR as a part of relaxation, if in a
relax trip size_relative_relocs has changed the layout, when
relax_section runs only the vma of the section being relaxed is
guaranteed to be updated. Then bad thing can happen. For example, when
linking an auxilary program _freeze_module in the Python 3.12.4 building
system (with PGO + LTO), before sizing the .relr.dyn section, the vma of
.text is 30560 and the vma of .rodata is 2350944; in the final
executable the vma of .text is 36704 and the vma of .rodata is 2357024.
The vma increase is expected because .relr.dyn is squashed somewhere
before .text. But size_relative_relocs may see the state in which .text
is at 36704 but .rodata "is" still at 2350944. Thus the distance
between .text and .rodata can be under-estimated and overflowing
R_LARCH_PCREL20_S2 reloc can be created.
To avoid this issue, if size_relative_relocs is updating the size of
.relr.dyn, just supress the normal relaxation in this relax trip. In
this situation size_relative_relocs should have been demending the next
relax trip, so the normal relaxation can happen in the next trip.
Xi Ruoyao [Mon, 12 Aug 2024 10:23:46 +0000 (18:23 +0800)]
LoongArch: Fix assertion failure with DT_RELR
In the DT_RELR implementation I missed a code path emiting relative
reloc entries. Then the already packed relative reloc entries will be
(unnecessarily) pushed into .rela.dyn but we've not allocated the space
for them, triggering an assertion failure.
Unfortunately I failed to notice the issue until profiled bootstrapping
GCC with LTO and -Wl,-z,pack-relative-relocs. The failure can be easily
triggered by linking a "hello world" program with -fprofile-generate and
LTO:
And the reduced test case is just incredibly simple (included in the
patch) so it seems I'm just stupid enough to fail to detect it before.
Let's fix it now anyway.
Jan Beulich [Wed, 14 Aug 2024 09:25:12 +0000 (11:25 +0200)]
x86: correct .insn with opcode extension and VEX/XOP/EVEX encoding
When VexVVVV handling was re-worked, .insn broke: When an opcode
extension is in use, VexVVVV_DST needs using now, as ModR/M.reg is
already occupied, matching what c8866e3ec5e2 ("x86: Drop using
extension_opcode to encode vvvv register") did.
While adding (bad) POP2 forms, also slightly adjust existing ones:
No need to use XMM registers, and no need to specify %r8 when really
%rax is meant twice (EVEX.vvvv not really being the culprit there, or
else EVEX.V' would also have needed mentioning).
Felix Willgerodt [Mon, 18 Feb 2019 14:50:49 +0000 (15:50 +0100)]
btrace: Extend ptwrite event decoding.
Call the ptwrite filter function whenever a ptwrite event is decoded.
The returned string is written to the aux_data string table and a
corresponding auxiliary instruction is appended to the function segment.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
By default GDB will be printing the hex payload of the ptwrite package as
auxiliary information. To customize this, the user can register a ptwrite
filter function in python, that takes the payload and the PC as arguments and
returns a string which will be printed instead. Registering the filter
function is done using a factory pattern to make per-thread filtering easier.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Felix Willgerodt [Tue, 21 Jul 2020 09:12:08 +0000 (11:12 +0200)]
btrace, gdbserver: Add ptwrite to btrace_config_pt.
This enables gdb and gdbserver to communicate about ptwrite support. If
ptwrite support would be enabled unconditionally, GDBs with older libipt
versions would break.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Felix Willgerodt [Mon, 25 Feb 2019 14:30:29 +0000 (15:30 +0100)]
python: Add clear() to gdb.Record.
This function allows to clear the trace data from python, forcing to
re-decode the trace for successive commands.
This will be used in future ptwrite patches, to trigger re-decoding when
the ptwrite filter changes.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Felix Willgerodt [Thu, 21 Feb 2019 09:48:35 +0000 (10:48 +0100)]
python: Introduce gdb.RecordAuxiliary class.
Auxiliary instructions are no real instructions and get their own object
class, similar to gaps. gdb.Record.instruction_history is now possibly a
list of gdb.RecordInstruction, gdb.RecordGap or gdb.RecordAuxiliary
objects.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
btrace: Enable auxiliary instructions in record function-call-history.
Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
is encountered in the function-call-history. Printing is
active by default, it can be silenced with the /a modifier.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
btrace: Enable auxiliary instructions in record instruction-history.
Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX
is encountered in the instruction-history. Printing is active by default,
it can be silenced with the /a modifier.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Felix Willgerodt [Mon, 18 Feb 2019 12:49:25 +0000 (13:49 +0100)]
btrace: Introduce auxiliary instructions.
Auxiliary instructions are pseudo instructions pointing to auxiliary data.
This auxiliary data can be printed in all commands displaying (record
function-call-history, record instruction-history) or stepping through
(stepi etc.) the execution history, which will be introduced in the next
commits.
This patch is in preparation for the new ptwrite feature, which is based on
auxiliary instructions.
Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Mark unavailable bytes of limited-length arrays when allocating contents
I spotted that there was some code in value::record_latest relating to
limited-length arrays which appeared redundant. The code was added
with the first introduction on limited-length arrays in commit:
GDB: Introduce limited array lengths while printing values
The code in question is in value::record_latest. When the value being
recorded is lazy we need to fetch its value before adding it to the
history list. The code I spotted checks to see if the value is lazy,
if we currently have array limiting in effect, and if we do sets
m_limited_length to max_value_size before finally calling fetch_lazy.
The first thing fetch_lazy does is call allocate_contents to setup the
value's buffer, and in allocate_contents we perform the same set of
checks: if the value is an array, and array length limiting is in
effect then only allocate max_value_size buffer for the contents.
In ::allocate_contents the `if` condition check is spread out between
::allocate_contents and ::set_limited_array_length, but I'm certain
it's checking the same condition.
As such the checks and m_limited_length adjustment in ::record_latest
is redundant and can be removed.
Out of curiosity I went back to the original a0c07915778486a commit
and removed the same block of code from record_latest_value (as
value::record_latest was called back then) and non of the tests added
by commit a0c07915778486a failed. I think this block of code was
never needed.
Anyway, I removed the unnecessary code and retested and there are no
regressions.
There should be no user visible changes after this commit.
Alan Modra [Tue, 13 Aug 2024 02:53:03 +0000 (12:23 +0930)]
gas macro arg1 test
A number of targets pad out the data section, and there are targets
that have 2 or 4 octets per byte. And some even that don't have '#'
as a line comment char. tic6x-elf fails the test with "Error: too
many positional arguments".
* testsuite/gas/macros/arg1.s: Pad out data section. Use C style
comments.
* testsuite/gas/macros/arg1.d: Adjust to suit. Don't run on
multi-octet per byte targes. xfail tic6x.
Extend the -H option:
-H {off|on|N1[-N2]} disable , or enable heap tracing, or
specify the heap data collection range.
The default is "-H off".
gprofng/ChangeLog
2024-08-08 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* libcollector/heaptrace.c: Read the range in the -H option.
Do not collect data if the allocated memory is out of range.
* src/collctrl.h (heaptrace_mode): Define as char * value.
* src/envsets.cc: Updated since heaptrace_mode is changed.
* src/collctrl.cc: Accept the extended -H option.
* src/gp-collect-app.cc: Accept the extended -H option.
Remove unused code.
Dimitar Dimitrov [Mon, 12 Aug 2024 17:40:16 +0000 (20:40 +0300)]
sim: pru: Fix test case assembly with latest GAS
After the recent change in GAS [1], macro arguments must be quoted or
grouped with parenthesis. Add the necessary parenthesis in order to fix
assembly errors like:
mul.s:31: Error: too many positional arguments
Tom Tromey [Mon, 29 Jul 2024 15:38:29 +0000 (09:38 -0600)]
Simplify typename_concat
This patch simplifies typename_concat, changing the return type and
removing the obstack allocation code. The latter is possible because
the only caller using this mode uses the name when creating a new
type, and 'new_type' copies the string to the appropriate obstack
anyway. It also changes typename_concat to use 'concat'. This change
lets us remove a mildly fragile macro as well.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Mon, 12 Aug 2024 15:43:22 +0000 (08:43 -0700)]
gas: Add macro tests for PR gas/32073
1. Add a macro test for expression argument with inner white spaces and
a white space before argument added by C preprocessor.
2. Add a x86-64 specific macro test.
PR gas/32073
* testsuite/gas/i386/x86-64-macro-1.d: New file.
* testsuite/gas/i386/x86-64-macro-1.s: Likewise.
* testsuite/gas/i386/x86-64.exp: Run x86-64-macro-1.
* testsuite/gas/macros/arg1.d: New file.
* testsuite/gas/macros/arg1.s: Likewise.
* testsuite/gas/macros/macros.exp: Run arg1.
Bernd Edlinger [Mon, 12 Aug 2024 15:32:44 +0000 (17:32 +0200)]
[gdb/testsuite] Fix gdb.tui/wrap-line.exp with wrapping disabled
There are a couple of ways that readline wrapping can be disabled:
- using "set horizontal-scroll-mode on" in INPUTRC,
- using a TERM setting like TERM=dumb, and
- building gdb with stub-termcap.
Using a trigger patch in default_gdb_init that adds
"set horizontal-scroll-mode on" to INPUTRC:
...
- setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"]
+ setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"]
...
we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in
PR testsuite/31201 (which was reported for the stub-termcap case):
...
WARNING: timeout in accept_gdb_output
Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1):
0 Quit
1 <89012345678901234567890123456789W
2
...
23
FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap
...
Fix this by accepting the horizontal-scroll-mode style output. We do
this only when in CLI mode though, when in TUI wrapping works as before
because it doesn't rely on readline.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
Simon Marchi [Mon, 5 Aug 2024 14:39:15 +0000 (10:39 -0400)]
gdb/amd-dbgapi-target: adjust to amd-dbgapi 0.75.0
amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards
incompatible changes. Adjust the amd-dbgapi target code accordingly.
Given that the AMD GPU port in upstream GDB today is of limited use
(it's still missing important pieces), we don't really care about
supporting amd-dbgapi versions other than the latest stable one, so no
effort is made to keep compatibility with versions 6.1.2 and older.
The changes are:
- AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to
AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists
but is deprecated), use the latter.
- In the callbacks structure, the get_os_pid callback was replaced with
client_process_get_info, which is more general and extensible.
Convert our get_os_pid to a new, equivalent, client_process_get_info
callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE
query, but just return "not available".
- The xfer_global_memory callback was added to the callbacks structure,
add that new callback.
- Update configure.ac to check for amd-dbgapi >= 0.75.0.
Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981 Approved-By: Lancelot Six <lancelot.six@amd.com> Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Simon Marchi [Mon, 29 Jul 2024 03:25:58 +0000 (23:25 -0400)]
gdb: pass inferior to gdbarch_update_p
Make the current inferior reference bubble up one level. I think this
makes it clearer what gdbarch_update_p, which is update the passed
inferior's architecture (although the function name could probably be
better).
When gdbarch_find_by_info, it is possible for the new architecture's
init callback to be called. I have not audited all of them (there are
just too many), it's possible that some of them do care about the
current inferior, for some reason (for instance, if one of them makes a
target call). If so, they should be changed too.
Simon Marchi [Thu, 30 May 2024 20:28:21 +0000 (16:28 -0400)]
gdb: change names of enumerations in enum flags selftest
When reading this test (in the context of PR 31331), I had trouble
understanding the tests, because of the abbreviated names. I would
prefer if the names were a bit more explicit, like this.
Simon Marchi [Thu, 30 May 2024 20:28:19 +0000 (16:28 -0400)]
gdbsupport: remove C enum flags fallback
This might have been useful during the C -> C++ conversion (not sure),
but it doesn't appear useful today. I don't see when enum-flags.h would
be used in a C context.
Simon Marchi [Wed, 17 Jul 2024 03:52:02 +0000 (23:52 -0400)]
gdb: add program_space parameter to lookup_minimal_symbol
>From what I can see, lookup_minimal_symbol doesn't have any dependencies
on the global current state other than the single reference to
current_program_space. Add a program_space parameter and make that
current_program_space reference bubble up one level.
Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Wed, 17 Jul 2024 03:52:01 +0000 (23:52 -0400)]
gdb: remove lookup_bound_minimal_symbol
Now that lookup_minimal_symbol has default values for sfile and objf,
calling lookup_bound_minimal_symbol is identical to calling
lookup_minimal_symbol without sfile and objf. Remove
lookup_bound_minimal_symbol, replace call sites with
lookup_minimal_symbol.
Change-Id: I0a420fb56de1de8bee8a7303228c9e4546e3577b Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Wed, 17 Jul 2024 03:52:00 +0000 (23:52 -0400)]
gdb: make lookup_minimal_symbol objf and sfile parameters optional
Most calls to lookup_minimal_symbol don't pass a value for sfile and
objf. Make these parameters optional (have a default value of
nullptr). And since passing a value to `objf` is much more common than
passing a value to `sfile`, swap the order so `objf` comes first, to
avoid having to pass a nullptr value to `sfile` when wanting to pass a
value to `objf`.
Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27 Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Wed, 17 Jul 2024 03:51:59 +0000 (23:51 -0400)]
gdb: drop struct keyword when using bound_minimal_symbol
This is a simple find / replace from "struct bound_minimal_symbol" to
"bound_minimal_symbol", to make things shorter and more consisten
througout. In some cases, move variable declarations where first used.
Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849 Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Thu, 25 Jul 2024 17:41:36 +0000 (13:41 -0400)]
gdbsupport: remove #ifndef REALTIME_LO in signals.cc
REALTIME_LO was only possibly previously defined in config/nm-nto.h,
which is now removed. So we can remove the #ifndef protecting against a
redefinition of REALTIME_LO in gdbsupport/signals.cc.
Change-Id: I021b9518ceaa6223bd480ff1e07e9a978b0b241e Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Thu, 25 Jul 2024 17:41:35 +0000 (13:41 -0400)]
gdb: remove QNX Neutrino support
Remove the support for the QNX Neutrino OS (tdep and native bits). This
has been unmaintained for years, and we don't have a way to see if it
works (or even builds, for the native parts). Without somebody actively
maintaining it, this is just a burden for developers, especially that
this port does a few weird unique things that require reasoning about
when doing big change.
Support for GDBserver was removed in 2020, commit 613f149a90d6
("gdbserver: remove support for Neutrino").
Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d Approved-by: Kevin Buettner <kevinb@redhat.com>
Alan Modra [Fri, 9 Aug 2024 23:11:16 +0000 (08:41 +0930)]
PR32067, ld -Wl,--oformat,binary crash in _bfd_elf_link_keep_memory
The direct fix for this segfault is to test for a non-NULL bed in
_bfd_elf_link_keep_memory, but also there isn't much point in running
code for LTO if the output is binary.
PR 32067
* elflink.c (_bfd_elf_link_keep_memory): Test for non-NULL bed.
(elf_link_add_object_symbols): Don't run the loop setting
non_ir_ref_regular if the output hash table is not ELF.
Stephan Rohr [Sat, 3 Aug 2024 09:07:42 +0000 (02:07 -0700)]
gdb: adjust the default place of 'list' to main's prologue
The 'list' command prints around the 'main' function if the current
source location is not set. The prologue of 'main' is skipped and the
first real line of 'main' is offset by 'lines_to_print - 1'. This is
incorrect, the location should be defaulted to main's prologue without
applying offsets (similar to 'list main'). Printing around the selected
line is then done in 'list_around_line'.
The patch also fixes an issue if the list command is used before the
program is started. For example, with the following code:
Jan Beulich [Fri, 9 Aug 2024 10:00:26 +0000 (12:00 +0200)]
gas: drop scrubber states 14 and 15
While sadly 5262831592fb doesn't say anything on why these would have
been needed, the latest with the removal of most of the opcode vs
operands distinction in the scrubber these shouldn't be needed anymore.
The implementation was a little questionable anyway, in moving back to
states expecting labels, when clearly labels shouldn't really be
following predicates (in practice, due to another bug, at least ia64
permits such).
Jan Beulich [Fri, 9 Aug 2024 09:59:31 +0000 (11:59 +0200)]
gas: have scrubber retain more whitespace
According to the description of the state machine, the expectation
appears to be that (leaving aside labels) any insn mnemonic or
directive would be followed by a comma separated list of operands. That
may have been true very long ago, but the latest with the advent of more
elaborate macros this isn't rhe case anymore. Neither macro parameters
in macro definitions nor macro arguments in macro invocations are
required to be separated by commas. Hence whitespace serves a crucial
role there. Plus even without "real" macros issues exist, in e.g.
.irp n, ...
insn\n\(suffix) operand1, operand2
.endr
Whitespace following the closing parenthesis would have been removed
(ahead of even processing the .irp), as the "opcode" was deemed to have
ended earlier already.
Therefore, squash the distinction between "opcode" and operands, i.e.
fold state 10 back into state 3. Also drop most of the distinction
between "symbol chars" and "relatively normal" ones. Not entirely
unexpectedly this results in the need to skip whitespace in a few more
places in arch-specific code (and quite likely more changes are needed
for insn forms not covered by the testsuite).
As a result the D10V special case is no longer necessary.
In config/tc-sparc.c also move a comment to be next to the code being
commented.
In opcodes/cgen-asm.in some further cleanup is done, following the local
var adjustments.
Jan Beulich [Fri, 9 Aug 2024 09:52:42 +0000 (11:52 +0200)]
MIPS: relax gas testsuite whitespace expectations
In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
Jan Beulich [Fri, 9 Aug 2024 09:52:18 +0000 (11:52 +0200)]
aarch64: relax gas testsuite whitespace expectations
In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
Jan Beulich [Fri, 9 Aug 2024 09:51:47 +0000 (11:51 +0200)]
Arm: relax gas testsuite whitespace expectations
In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
Jan Beulich [Fri, 9 Aug 2024 09:48:32 +0000 (11:48 +0200)]
gas: respect CR_EOL also for scrubbing
While apparently intended to be only externally controlled (e.g. via
specifying CFLAGS at make invocation), we should still keep scrubber and
lexer in sync in this regard. There's one place which imo was previously
wrong already, but would go further wrong and hence is being adjusted
right here: An .mri directive can be terminated by any kind of "line"
(really: statement) separators.
Jan Beulich [Fri, 9 Aug 2024 09:48:05 +0000 (11:48 +0200)]
gas: have scrubber also respect quoted labels
For the handling of ':' elsewhere in the scrubber to be correct with
regard to labels, the state after parsing a string found at the start of
a line must match that after finding a symbol character at the start of
a line. (Things are largely okay when there's whitespace ahead of the
label: Whitespace after the colon then is retained rather than dropped
for typical targets like x86, but read.c will know to deal with that.)
The .option arch/rvc/norvc/push/pop directives can only take effect for a
small/large specific code region, so they are not file-level architecture
setting. They should only affect the mapping symbols only rather than the
file-level elf architecture attribute. Otherwise, the elf architecture
attribute will appear to missing some extensions when -flto merges files
with different .option architecture settings.
gas/
PR 32014
* config/tc-riscv.c (file_arch_str): New const char *, rather than the
arch_str in the riscv_rps_as.subset_list, it's file-level so only be
affected by .attribute arch directive.
(riscv_reset_subsets_list_arch_str): Renamed to riscv_set_arch_str, and
also can handle both file_arch_str and arch_str in subset_list, just
give the pointer address as the input.
(riscv_set_arch): Called by -march and .attribute arch, so set both
file_arch_str and arch_str in subset_list.
(s_riscv_option): Updated .option arch/rvc/norvc/push/pop that only
set the arch_str in subset_list.
(riscv_write_out_attrs): Output elf architecture attribute according to
file_arch_str. Freed file_arch_str.
* doc/c-riscv.texi: Added destrbution that .option directives shouldn't
affect the elf attribute settings.
* testsuite/gas/riscv/option-arch.s: From option-arch-01/02/03 merged.
* testsuite/gas/riscv/option-arch-dis.d: Likewise, for dis-assembler.
* testsuite/gas/riscv/option-arch-attr.d: Likewise, to check readelf -A.
gas: sparc: Fix faligndatai assembly and disassembly
The first operand is a general register, not an fp register;
the third operand is encoded into RS2, not RS3;
the second operand must match the destination operand.
Tom de Vries [Thu, 8 Aug 2024 21:52:00 +0000 (23:52 +0200)]
[gdb/python] Fix handling of ^C during disassembly
Inspired by the trigger patch I used here [1], I tried this in
gdbpy_print_insn:
...
/* Call into the registered disassembler to (possibly) perform the
disassembly. */
+ set_quit_flag ();
PyObject *insn_disas_obj = (PyObject *) disasm_info;
gdbpy_ref<> result (PyObject_CallFunctionObjArgs (hook.get (),
insn_disas_obj,
...
and with test-case gdb.python/py-disasm-exec.exp ran into:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x00000000004101ac <+0>: Python Exception <class 'KeyboardInterrupt'>: ^M
^M
unknown disassembler error (error = -1)^M
(gdb)
...
This is incorrect, the KeyboardInterrupt should propagate and interrupt the
command.
Fix this by using gdbpy_print_stack_or_quit instead of gdbpy_print_stack in
gdbpy_print_insn, giving us instead:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x00000000004101ac <+0>: ^M
Quit^M
(gdb)
...
Tested on aarch64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-July/210798.html
Tom de Vries [Thu, 8 Aug 2024 21:52:00 +0000 (23:52 +0200)]
[gdb] Handle ^C during disassembly
In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while
disassembling.
I managed to reproduce this on aarch64-linux in a Leap 15.5 container using
this trigger patch:
...
gdb_disassembler_memory_reader::dis_asm_read_memory
(bfd_vma memaddr, gdb_byte *myaddr, unsigned int len,
struct disassemble_info *info) noexcept
{
+ set_quit_flag ();
return target_read_code (memaddr, myaddr, len);
}
...
and a simple gdb command line calling the disassemble command:
...
$ gdb -q -batch a.out -ex "disassemble main"
...
The following scenario leads to the fatal error:
- the disassemble command is executed,
- set_quit_flag is called in
gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a
user pressed ^C,
- target_read_code calls QUIT, which throws a
gdb_exception_quit,
- the exception propagation mechanism reaches c code in libopcodes and a fatal
error triggers because the c code is not compiled with -fexception.
Fix this by:
- wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in
catch_exceptions (which consequently needs moving to a header file), and
- reraising the caught exception in default_print_insn using QUIT.
Tested on aarch64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025
Jan Beulich [Wed, 7 Aug 2024 14:32:15 +0000 (16:32 +0200)]
gas: drop dead VMS code from command line handling
The only time 'v' was overridden, allowing for an optional value, was
when OBJ_VMS support still existed (until a little less than 20 years
ago). Drop the respective leftovers.
With that OPTION_VERBOSE also becomes redundant and hence is being
dropped.
Jan Beulich [Wed, 7 Aug 2024 14:31:54 +0000 (16:31 +0200)]
VAX: drop OBJ_VMS leftovers
OBJ_VMS support was dropped almost 20 years ago (e330299ed5ee). Drop
respective code from tc-vax.c as well.
While there, make adjustments for OBJ_ELF as well: -K was dropped over
20 years ago (530556a951f5), yet left in md_shortopts. OPTION_PIC isn't
really necessary either; 'k' can be used instead. And then the ELF
options available weren't displayed by md_show_usage().
Jan Beulich [Wed, 7 Aug 2024 14:31:00 +0000 (16:31 +0200)]
gas: improve unrecognized command line option diagnostic
Printing optc with %c makes sense only when optc is actually a
character. Add logic to also deal with unrecognized long options,
rejected by md_parse_option() rather than get_opt_long_only(). Also
quote the reproduced strings, such that possible included whitespace
can be recognized.
Alan Modra [Tue, 6 Aug 2024 22:26:33 +0000 (07:56 +0930)]
loongarch ld testsuite xpasses
Some tests started passing with commit 3a83f0342e54. However,
supporting a changed ld output format is not so simple, and the change
to the loongarch_elf_hash_table macro needs further changes to the
rest of the code. It is true that some uses of
loongarch_elf_hash_table do not need to check the type of the hash
table, but others like loongarch_elf_relax_section do need to check.
bfd_relax_section is called in lang_size_sections using the input bfd,
not the output bfd. If the input bfd may be of different type to the
output, then the hash table type must be checked before accessing
elements of the hash table. This patch corrects
loongarch_elf_relax_section. I haven't checked all the uses of the
hash table throughout the loongarch backend.
Hannes Domani [Tue, 6 Aug 2024 17:34:18 +0000 (19:34 +0200)]
Mark unavailable bytes of limited-length arrays when allocating contents
Using 'output' to print arrays larger than max-value-size, with only
repeating elements, can cause gdb to crash:
```
$ cat a.c:
char a[1000000];
int main()
{
return a[0];
}
$ gdb -q a
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
Using 'print' works, because value::record_latest sets the unavailable
bytes of the value when it's added to the value history.
But 'outout' doesn't do that, so the printing tries to access more bytes
than are available.
The original problem in PR32015 was about using 'print' of a dynamic
array in a D program.
Here the crash happens because for 'print' the value was a struct with
length/ptr fields, which is converted in d-valprint.c into an array.
So value::record_latest didn't have a chance to mark the unavailable
bytes in this case.
To make sure the unavailable bytes always match the contents, this fixes
it by marking the unavailable bytes immediately after the contents are
allocated.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015 Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Indu Bhagat [Tue, 6 Aug 2024 16:46:06 +0000 (09:46 -0700)]
gas: scfi: replace verbose expressions with local vars
Replace the scattered and repeated uses of verbose expressions with
variables. E.g.,
ginsn_get_src_reg (src1) -> src1_reg
ginsn_get_src_type (src1) -> src1_type
etc.
This hopefully makes the logic bit more maintainable. While at it,
include minor adjustments to make few checks in gen_scfi_ops () more
precise:
- When getting imm value from src operand, ensure the src type is
GINSN_SRC_IMM,
- When getting reg from src operand, ensure the src type is checked
too (GINSN_SRC_REG or GINSN_SRC_INDIRECT as appropriate).
On the other hand, the changes in verify_heuristic_traceable_reg_fp ()
and verify_heuristic_traceable_stack_manipulation () are purely
mechanical.
gas/
* scfi.c (verify_heuristic_traceable_reg_fp): Add new local
vars and reuse them.
(verify_heuristic_traceable_stack_manipulation): Likewise.
(gen_scfi_ops): Likewise. Additionally, make some conditionals
more precise.
Hau Hsu [Tue, 6 Aug 2024 03:56:18 +0000 (11:56 +0800)]
RISC-V: map zext.h to pack/packw if Zbkb is enabled
The `zext.h` is zero-extend halfword instruction that belongs to Zbb.
Currently `zext.h` falls back to 2 shifts if Zbb is not enabled. However, the
encoding and operation is a special case of `pack/packw rd, rs1, rs2`, which
belongs to Zbkb. The instructions pack the low halves of rs1 and rs2 into rd.
When rs2 is zero (x0), they behave like zero-extend instruction, and the
encoding are exactly the same as zext.h.
Thus we can map `zext.h` to `pack` or `packw` (rv64) if Zbkb is enabled,
instead of 2 shifts. This reduces one instruction.
This patch does this by making `zext.h` also available for Zbkb.
opcodes/
* riscv-opc.c (riscv_opcodes): Update `zext.h` entries to use
`ZBB_OR_ZBKB` instruction class.
gas/
* testsuite/gas/riscv/zext-to-pack.s: Add test for mapping zext to
pack/packw encoding.
* testsuite/gas/riscv/zext-to-pack-encoding.d: Likewise.
* testsuite/gas/riscv/zext-to-packw-encoding.d: Likewise.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Add custom operands `Xc6` and `Xc7`.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Note XCVbitmanip as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/march-help.l: Add xcvbitmanip.
* testsuite/gas/riscv/x-cv-bitmanip-fail.d: New Test.
* testsuite/gas/riscv/x-cv-bitmanip-fail.l: New Test.
* testsuite/gas/riscv/x-cv-bitmanip-fail.s: New Test.
* testsuite/gas/riscv/x-cv-bitmanip.d: New Test.
* testsuite/gas/riscv/x-cv-bitmanip.s: New Test.
include/opcode/ChangeLog:
* riscv-opc.h: Add corresponding MATCH and MASK macros for
XCVbitmanip.
* riscv.h: Add corresponding EXTRACT and ENCODE macros for
XCVbitmanip.
(enum riscv_insn_class): Add the XCVbitmanip instruction class.
Jan Beulich [Mon, 5 Aug 2024 14:29:54 +0000 (16:29 +0200)]
gas: maintain line numbers correctly after #APP / #NO_APP
Maintaining line numbers correctly both inside the region and past it
requires special care. The SB produced there is somewhat different from
that produced for e.g. macro expansions, and hence also needs treating
differently: In particular we aren't doing anything resembling macro
expansion here.
The new testcase may be a little misplaced in macros/, but that's where
all the other #APP / #NO_APP ones are.
For one '#' may not be in line_comment_chars[] in the first place. Look
for just it when it is (these "directives" are akin to C preprocessor
directives after all), but accept any other line comment character
otherwise (in read.c further requiring a match on the counterpart
"directive").
Then, when in the middle of a file, the constructs should be all on
their own on a line. There needs to be a newline ahead of them and
after them.
Finally '\n' may not be the only end-of-line character. Accept any (but
not end-of-statement ones) in read.c, while making sure in input-file.c
there is one in the first place - merely any kind of whitespace isn't
good enough.
Jan Beulich [Mon, 5 Aug 2024 14:28:43 +0000 (16:28 +0200)]
gas: recognize #APP at start-of-physical-line only
It's not valid to recognize it after mere line separators (often
semicolon) or after labels, let alone after tc_unrecognized_line()
perhaps having parsed off parts of a line. It shouldn't even be
preceded by whitespace, aiui.
However, keep ignoring line comments as before, for backwards
compatibility.
Tom de Vries [Mon, 5 Aug 2024 12:00:42 +0000 (14:00 +0200)]
[gdb] Notice when stepping into different file
Consider the following test-case:
...
$ cat -n test.c
1 int var;
2
3 int
4 foo (void)
5 {
6 var = 1;
7 #include "test.h"
8 }
9
10 int
11 main ()
12 {
13 return foo ();
14 }
$ cat -n test.h
1 return 1;
$ gcc test.c -g
...
When stepping through the test-case, gdb doesn't make it explicit that line 1
is not in test.c:
...
Temporary breakpoint 1, main () at test.c:13
13 return foo ();
(gdb) step
foo () at test.c:6
6 var = 1;
(gdb) n
1 return 1;
(gdb)
8 }
(gdb)
...
which makes it easy to misinterpret the output.
This is with the default "print frame-info" == auto, with documented
behaviour [1]:
...
stepi will switch between source-line and source-and-location depending on the
program counter.
...
What is actually implemented is that source-line is used unless stepping into
or out of a function.
The problem can be worked around by using
"set print frame-info source-and-location", but that's a bit verbose.
Instead, change the behaviour of "print frame-info" == auto to also use
source-and-location when stepping into another file, which gets us:
...
(gdb) n
foo () at test.h:1
1 return 1;
...
Tested on x86_64-linux.
Reviewed-By: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
PR gdb/32011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011
mengqinggang [Fri, 28 Jun 2024 06:24:19 +0000 (14:24 +0800)]
LoongArch: Add support for OUTPUT_FORMAT("binary")
In binary output format, loongarch_elf_hash_table return NULL and result
in segment fault.
When ld output binary file, it seems that elf related functions should
not be called. But loongarch_elf_relax_section be called and
loongarch_elf_hash_table cause segment fault.
Just redefined loongarch_elf_hash_table and always return
link_info->hash.
The tests of binutils, glibc and gcc is ok.
0 loongarch_elf_relax_section ()
1 0x000055555557ab28 in lang_size_sections_1 ()
2 0x000055555557a16c in lang_size_sections_1 ()
3 0x000055555557b0a8 in one_lang_size_sections_pass ()
4 0x000055555557b478 in lang_size_sections ()
5 0x000055555557e65c in lang_relax_sections ()
6 0x000055555559f9c8 in ldelf_map_segments ()
7 0x000055555559783c in gldelf64loongarch_after_allocation ()
8 0x000055555558dac0 in ldemul_after_allocation ()
9 0x000055555557f6c0 in lang_process ()
10 0x0000555555585314 in main ()
H.J. Lu [Sat, 3 Aug 2024 02:52:00 +0000 (19:52 -0700)]
LTO: Restore the wrapper symbol check for standard function
Call unwrap_hash_lookup to restore the wrapper symbol check for standard
function since reference to standard function may not show up in LTO
symbol table:
[hjl@gnu-tgl-3 pr31956-3]$ nm foo.o 00000000 T main
U __real_malloc 00000000 T __wrap_malloc
[hjl@gnu-tgl-3 pr31956-3]$ lto-dump -list foo.o
Type Visibility Size Name
function default 0 malloc
function default 0 __real_malloc
function default 3 main
function default 5 __wrap_malloc
[hjl@gnu-tgl-3 pr31956-3]$ make
gcc -O2 -flto -Wall -c -o foo.o foo.c
gcc -Wl,--wrap=malloc -O2 -flto -Wall -o x foo.o
/usr/local/bin/ld: /tmp/ccsPW0a9.ltrans0.ltrans.o: in function `main':
<artificial>:(.text.startup+0xa): undefined reference to `__wrap_malloc'
collect2: error: ld returned 1 exit status
make: *** [Makefile:22: x] Error 1
[hjl@gnu-tgl-3 pr31956-3]$
Also add a test to verify that the unused wrapper is removed.
PR ld/31956
* plugin.c (get_symbols): Restore the wrapper symbol check for
standard function.
* testsuite/ld-plugin/lto.exp: Run the malloc test and the
unused test.
* testsuite/ld-plugin/pr31956c.c: New file.
* testsuite/ld-plugin/pr31956d.c: New file.
* testsuite/ld-plugin/pr31956d.d: New file.
Now that all known uses of VLAs within GDB are removed, remove the
`-Wno-vla-cxx-extension` (which was used to silence clang warnings) and
add `-Wvla`, such that any use of a VLA will trigger a warning.
Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025 Reviewed-By: Keith Seitz <keiths@redhat.com>
Simon Marchi [Wed, 31 Jul 2024 18:06:12 +0000 (14:06 -0400)]
gdb: remove uses of VLA
Remove uses of VLAs, replace with gdb::byte_vector. There might be more
in files that I can't compile, but it's difficult to tell without
actually compiling on all platforms.
Many thanks to the Linaro pre-commit CI for helping find some problems
with an earlier iteration of this patch.
Change-Id: I3e5e34fcac51f3e6b732bb801c77944e010b162e Reviewed-by: Keith Seitz <keiths@redhat.com>
Guinevere Larsen [Fri, 31 May 2024 13:48:54 +0000 (10:48 -0300)]
gdb,testsuite: fix gdb.base/list-dot-nodebug and make it more robust
Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not
actually compiling the test with some debuginfo in the relevant part,
and while fixing I noticed that the base assumption of the "some" case
was wrong, GDB would select some symtab as a default location and the
test would always fail. This fix makes printing the default location
only be tested when there is no debuginfo.
When testing with no debuginfo, if a system had static libc debuginfo,
the test would also fail. To add an extra layer of robustness to the
test, this rewrite also strips any stray debuginfo from the executable.
The test would only fail now if it runs in a system that can't handle
stripped debuginfo and has static debuginfo pre-installed.
Reported-By: Tom de Vries <tdevries@suse.de> Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721 Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Tue, 30 Jul 2024 14:47:58 +0000 (10:47 -0400)]
gdb: remove inline_frame::skipped_frames
While reviewing [1], it occurred to me that having both the
skipped_frames counter and the skipped_syms vector is redundant. When
stepping into an inline frame, we can just pop the last element.
projects / thirdparty / binutils-gdb.git / log
