The relatively new "globals" scope code in DAP has a fairly obvious
bug -- the fetch_one_child method should return a tuple with two
elements, but instead just returns the variable's value.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029
Reviewed-By: Tom de Vries <tdevries@suse.de>
With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada
print pck.fp1_var^M
$1 = 0.3125^M
(gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var
...
The problem is that the thumb prologue analyzer overshoot, setting the
breakpoint for main after line 49:
...
46 int
47 main (void)
48 {
49 pck__fp1_var++;
...
and consequently we see the value of pck.fp1_var after line 49 instead of
before line 49. This is PR tdep/31981.
Work around this by removing line 49 and all similar subsequent lines, which
turn out to be dead code.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on arm-linux.
On arm-linux I run into:
...
(gdb) p *kernel_user_helper_version^M
Cannot access memory at address 0xffff0ffc^M
(gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version
...
What the test-case is trying to do, is to access a special address in the arm
linux kernel [1] using ptrace, which doesn't seem to work.
This is with kernel version 6.1.55. Perhaps this used to work, but the kernel
was modified to be more strict with respect to access to this special address.
Fix this by making the inferior access that special address instead.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/32070
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070
[1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
My previous patch
commit 8958aefd34 (HEAD)
Author: Felix Willgerodt <felix.willgerodt@intel.com>
Date: Mon Feb 25 15:30:29 2019 +0100
python: Add clear() to gdb.Record.
exposed a clear function for btrace data in python and added some tests
for it. That caused a regression (PR 32086) when recording with bts.
This is reproducible even without my patch, when adding
"maintenance btrace clear" to the test.
When comparing the instructions that get recorded in both cases, the traces
are almost identical, just that the first 3 instructions are missing.
Before clear:
(gdb) record instruction-history 1,100
1 0x0000555555555163 <main+12>: movl $0x0,-0x4(%rbp)
2 0x000055555555516a <main+19>: movl $0x0,-0x8(%rbp)
3 0x0000555555555171 <main+26>: jmp 0x555555555184 <main+45>
4 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
5 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
6 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
7 0x0000555555555176 <main+31>: mov %eax,%edi
...
After clear:
(gdb) record instruction-history 1,100
1 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
2 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
3 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
4 0x0000555555555176 <main+31>: mov %eax,%edi
...
The GDB manual describes this behaviour already:
maint btrace clear
Discard the branch trace data. The data will be fetched anew and
the branch trace will be recomputed when needed.
This implicitly truncates the branch trace to a single branch trace
buffer. When updating branch trace incrementally, the branch trace
available to GDB may be bigger than a single branch trace buffer.
The test with BTS is updating the recorded trace incrementally. After the
clear, the buffer of raw trace data available is not enough to recompute the
whole trace as it was before the clear(), and the first 3 instructions are
missing.
As increasing the buffer size for BTS didn't help, I propose to fix the test
by moving the testing of clear to the end of the test.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086
While 919b75f7e2 ("Trailing space in opcodes/ generated files") took
care of permanently zapping trailing whitespace, 5471128011
("opcodes: cris: move desc & opc files from sim/") then didn't enhance
the newly added code accordingly.
This reverts commit cfa18744d4.
commit 6ae8a30d44
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Aug 9 11:59:31 2024 +0200
gas: have scrubber retain more whitespace
has been reverted to fix PR gas/32073.
This reverts commit a1b7023447.
commit 6ae8a30d44
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Aug 9 11:59:31 2024 +0200
gas: have scrubber retain more whitespace
has been reverted to fix PR gas/32073.
This reverts commit 2231ac9b9e.
commit 6ae8a30d44
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Aug 9 11:59:31 2024 +0200
gas: have scrubber retain more whitespace
has been reverted to fix PR gas/32073.
This reverts commit c0e9aca554.
commit 6ae8a30d44
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Aug 9 11:59:31 2024 +0200
gas: have scrubber retain more whitespace
has been reverted to fix PR gas/32073.
While working on something else, I noticed that this is relatively
common:
scoped_restore_current_language save;
set_language (something);
This patch adds a second constructor to
scoped_restore_current_language to simplify this idiom.
Reviewed-By: Tom de Vries <tdevries@suse.de>
With commit 6ae8a30d44, arguments followed
by a C-style comment ended up with a trailing space. That extra space
character confused the PRU register name matching, leading to spurious
errors about unrecognized registers. This affected existing code like
newlib's setjmp.s for pru.
Fix by stripping the trailing whitespace for any argument.
Even with 6ae8a30d44 reverted, this patch
is safe to be applied.
Successfully regression-tested with GCC and newlib testsuites for pru-unknown-elf.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
When plugin_object_p is called by elf_link_is_defined_archive_symbol to
check if a symbol in archive is a real definition, set archive member
plugin_format to bfd_plugin_yes_unused to avoid including the unused LTO
archive members in linker output. When plugin_object_p is called as
known used, call plugin claim_file if plugin_format is bfd_plugin_unknown
or bfd_plugin_yes_unused.
To get the proper support for archives with LTO common symbols with GCC,
the GCC fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361
is needed.
bfd/
PR ld/32083
* archures.c (bfd_arch_get_compatible): Treat bfd_plugin_yes_unused
the same as bfd_plugin_yes.
* elflink.c (elf_link_is_defined_archive_symbol): Likewise.
* bfd.c (bfd_plugin_format): Add bfd_plugin_yes_unused.
* plugin.c (try_claim): Try claim_file_v2 first.
* bfd-in2.h: Regenerated.
ld/
PR ld/32083
* plugin.c (plugin_call_claim_file): Add an argument to return
if LDPT_REGISTER_CLAIM_FILE_HOOK_V2 is used.
(plugin_object_p): When KNOWN_USED is false, we call plugin
claim_file if plugin_format is bfd_plugin_unknown and set
plugin_format to bfd_plugin_yes_unused on LTO object. When
KNOWN_USED is true, we call plugin claim_file if plugin_format
is bfd_plugin_unknown or bfd_plugin_yes_unused.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
I think it would be useful for gdb's DAP logs to come with the version
and configuration information. This might make debugging some bug
reports a little simpler.
A DAP user noticed that breakpoints set by address were never updated
to show their location after the DAP launch request. It turns out
that gdb does not emit the breakpoint-modified event when this sort of
breakpoint is updated.
This patch changes gdb to notify the breakpoint-modified observer when
a breakpoint location's symbol changes. This in turn causes the DAP
event to be emitted.
Reviewed-by: Keith Seitz <keiths@redhat.com>
While working on earlier patches, I noticed that the DAP C++ exception
test had some strange results in the log. Digging into this, I found
that while the Ada catchpoints emit a "bkptno" field in the MI result,
the C++ ones do not -- but the DAP code was relying on this.
This patch fixes the problem by changing which field is examined, and
then updates the tests to verify this.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Currently, when a DAP client uses setInstructionBreakpoints, the
resulting breakpoints are created as "verified", even though there is
no symbol file and thus the breakpoint can't possibly have a source
location.
This patch changes the DAP code to assume that all breakpoints are
unverified before launch.
Reviewed-by: Keith Seitz <keiths@redhat.com>
This adds a new exec_mi_and_log function that wraps gdb.execute_mi and
logs the command. This can be handy when debugging DAP.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Linker checks if a symbol in an archive member is a real definition, not
common, before including the archive member in the link output so that
only a real definition in archive will override the common symbol in
object file. Add an LTO test to verify that a real definition in archive
overrides the common symbol in object file.
* testsuite/ld-plugin/common-1.c: New file.
* testsuite/ld-plugin/definition-1.c: Likewise.
* testsuite/ld-plugin/lto.exp: Run common tests.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
I noticed that initialize_block_iterator has a default value for one
of its arguments, but this is not needed as this function has a single
caller that always passes all arguments. This patch removes the
default. Tested by rebuilding.
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.
I tried to make a reduced test case but failed.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
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:
$ PATH=$HOME/ld-test:$PATH gcc hw.c -fprofile-generate -Wl,-z,pack-relative-relocs -flto
/home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628
/home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628
collect2: error: ld returned 1 exit status
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.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
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 c8866e3ec5 ("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).
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>
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>
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>
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>
Print the auxiliary data when stepping. Don't allow to goto an auxiliary
instruction.
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>
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>
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>
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>
While reviewing this commit:
commit 8fdd2b2bcd
Date: Tue Aug 6 19:34:18 2024 +0200
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:
commit a0c0791577
Date: Fri Feb 10 23:49:19 2023 +0000
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 a0c0791577 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 a0c0791577 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.
Approved-By: John Baldwin <jhb@FreeBSD.org>
Never set non_ir_ref_regular for debug reference since references in
debug sections shouldn't impact LTO output.
* elflink.c (elf_link_add_object_symbols): Don't check strip for
references in debug sections when setting non_ir_ref_regular.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
This is a very small patch to straighten out dot-space-space in these
comments in the gdbarch generated files:
- /* Skip verify of short_bit, invalid_p == 0 */
+ /* Skip verify of short_bit, invalid_p == 0. */
There is no functional change after this commit.
Approved-By: Andrew Burgess <aburgess@redhat.com>
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.
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
[1] https://sourceware.org/pipermail/binutils/2024-July/136053.html
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
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>
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.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
