Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
gprofng/ChangeLog
2023-07-31 Khem Raj <raj.khem@gmail.com>
* libcollector/iotrace.c: Define open64, fgetpos64, and fsetpos64
only when __USE_LARGEFILE64 and __USE_FILE_OFFSET64 are not
defined.
|
|
|
|
* ldmisc.h (xmalloc, xrealloc, xexit, yyerror): Don't declare.
* emultempl/pdp11.em: Include libiberty.h.
* emultempl/ticoff.em: Likewise.
* emultempl/vms.em: Likewise.
* ldctor.c: Likewise.
* ldelfgen.c: Likewise.
* ldgram.y: Likewise.
(yyerror): Prototype and make static.
|
|
It's better to include the proper header, which has declarations with
various attributes. Commit 096aefc040 in 1994 introduced this wart.
* bucomm.h (xmalloc, xrealloc): Delete declaration.
* od-macho.c: Include libiberty.h.
* od-xcoff.c: Include libiberty.h.
|
|
For commit 3d05c80b5dc4.
|
|
This implements the DAP "source" request. I renamed the
"loadedSources" function from "sources" to "loaded_sources" to avoid
any confusion. I also moved the loadedSources test to the new
sources.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30691
|
|
This changes the DAP breakpointLocations request to accept a Source
and to decode it properly.
|
|
This changes the gdb DAP implementation to emit a real
sourceReference, rather than emitting 0. Sources are tracked in some
maps in sources.py, and a new helper function is introduced to compute
the "Source" object that can be sent to the client.
|
|
The DAP 'module' event may include a 'path' component. I noticed that
this is supplied even when the module in question does not come from a
file.
This patch only emits this field when the objfile corresponds to a
real file.
No test case, because I wasn't sure how to write a portable one.
However, it's clear from gdb.log on Linux:
{"type": "event", "event": "module", "body": {"reason": "new", "module": {"id": "system-supplied DSO at 0x7ffff7fc4000", "name": "system-supplied DSO at 0x7ffff7fc4000"}}, "seq": 21}
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30676
|
|
This patch implements ValueFormat for DAP. Currently this only means
supporting "hex".
Note that StackFrameFormat is defined to have many more options, but
none are currently recognized. It isn't entirely clear how these
should be handled. I'll file a new gdb bug for this, and perhaps an
upstream DAP bug as well.
New in v2:
- I realized that the "hover" context was broken, and furthermore
that we only had tests for "hover" failing, not for it succeeding.
This version fixes the oversight and adds a test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30469
|
|
I noticed that the support for memoryReference in the "variables"
output is gated on the client "supportsMemoryReferences" capability.
This patch implements this and makes some other changes to the DAP
memory reference code:
* Remove the memoryReference special case from _SetResult.
Upstream DAP fixed this oversight in response to
https://github.com/microsoft/debug-adapter-protocol/issues/414
* Don't use the address of a variable as its memoryReference -- only
emit this for pointer types. There's no spec support for the
previous approach.
* Use strip_typedefs to handle typedefs of pointers.
|
|
This adds DAP support for the various C++ exception-catching
operations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30682
|
|
This implements the DAP 'terminated' event. Vladimir Makaev noticed
that VSCode will not report the debug session as over unless this is
sent.
It's not completely clear when exactly this event ought to be sent.
Here I've done it when the inferior exits.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30681
|
|
When the DAP client sets a breakpoint, gdb currently sends a "new
breakpoint" event. However, Vladimir Makaev discovered that this
causes VSCode to think there are two breakpoints.
This patch changes gdb to suppress the event in this case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30678
|
|
A subsequent patch will add the ability to suppress breakpoint events
to DAP. My first attempt at this ended up with recurse imports,
causing Python failures. So, this patch moves all the DAP breakpoint
event code to breakpoint.py in preparation for the change.
I've renamed breakpoint_descriptor here as well, because it can now be
private to breakpoint.py.
|
|
Vladimir Makaev noticed that, in some cases, a DAP stackTrace response
would include a relative path name for the "path" component.
This patch changes the frame decorator code to add a new DAP-specific
decorator, and changes the DAP entry point to frame filters to use it.
This decorator prefers the symtab's full name, and does not fall back
to the solib's name.
I'm not entirely happy with this patch, because if a user frame filter
uses FrameDecorator, it may still do the wrong thing. It would be
better to have frame filters return symtab-like objects instead, or to
have a separate method to return the full path to the source file.
I also tend to think that the solib fallback behavior of
FrameDecorator is a mistake. If this is ever needed, it seems to me
that it should be a separate method.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30665
|
|
This adds the "cwd" parameter to the DAP launch request.
This came up here:
https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/issues/90
... and seemed like a good idea.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This patch refactors dap_launch to make it more extensible and also
easier to use.
|
|
In Python, a member name starting with "__" is specially handled to
make it "more private" to the class -- it isn't truly private, but it
is renamed to make it less likely to be reused by mistake. This patch
ensures that this is done for the private method of FrameDecorator.
|
|
Reports a thread exit according to the DAP spec:
https://microsoft.github.io/debug-adapter-protocol/specification#Events_Thread
This patch requires the ThreadExitedEvent to be checked in,
in order to work. That patch is found here https://sourceware.org/pipermail/gdb-patches/2023-June/200071.html
Formatted correctly using black
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30474
Approved-By: Tom Tromey <tom@tromey.com>
|
|
which add .debug_macro sections to object files.
PR 30699
* binutils/testsuite/binutils-all/objcopy.exp (keep_debug_symbols_for_elf_relocatable): Do not add sections containing the string "debug_" to the list of non-debug sections.
|
|
PR 28909
Sadly "cp -p", doing more than just preserving the time stamp, can fail
e.g. upon trying to preserve ownership (which we don't care about), as
can be observed on e.g. Cygwin. Replace the use of -p by a use of touch,
this way also only preserving modification time.
|
|
source tarballs
|
|
|
|
In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use
the output of gp-display-text to display the data.
gp-display-text did not report available views.
gprofng/ChangeLog
2023-07-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/Command.cc: Add commands for gprofng GUI.
* src/gprofng.rc: Set defaults for gprofng GUI.
|
|
|
|
I build gdb with -fsanitize=thread and ran the testsuite, and ran into the
case that a race is detected, but we see the full stack trace only for one of
the two accesses, and the other one is showing "failed to restore the stack".
Try to prevent this by setting ThreadSanitizer flag history_size [1] to the
maximum (7) by default, as suggested here [2].
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags
[2] https://groups.google.com/g/thread-sanitizer/c/VzSWE7UxhIE
|
|
Alexandre Oliva found a bug in gdb's handling of fixed-point -- a
certain Ada fixed-point type would be misintepreted. The bug was that
the DW_AT_small looked like:
<1><13cd>: Abbrev Number: 16 (DW_TAG_constant)
<13ce> DW_AT_GNU_numerator: 1
<13cf> DW_AT_GNU_denominator: 0x8000000000000000
... but gdb interpreted the denominator as a negative value.
|
|
|
|
When debugging a multi-process application where a parent spawns
multiple child processes using the ROCm runtime, I see the following
assertion failure:
../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x556e9a318540 gdb_internal_backtrace_1
../../gdb/bt-utils.c:122
0x556e9a318540 _Z22gdb_internal_backtracev
../../gdb/bt-utils.c:168
0x556e9a730224 internal_vproblem
../../gdb/utils.c:396
0x556e9a7304e0 _Z15internal_verrorPKciS0_P13__va_list_tag
../../gdb/utils.c:476
0x556e9a87aeb4 _Z18internal_error_locPKciS0_z
../../gdbsupport/errors.cc:58
0x556e9a29f446 process_one_event
../../gdb/amd-dbgapi-target.c:1071
0x556e9a29f446 process_event_queue
../../gdb/amd-dbgapi-target.c:1156
0x556e9a29faf2 _ZN17amd_dbgapi_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../gdb/amd-dbgapi-target.c:1262
0x556e9a6b0965 _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../gdb/target.c:2586
0x556e9a4c221f do_target_wait_1
../../gdb/infrun.c:3876
0x556e9a4d8489 operator()
../../gdb/infrun.c:3935
0x556e9a4d8489 do_target_wait
../../gdb/infrun.c:3964
0x556e9a4d8489 _Z20fetch_inferior_eventv
../../gdb/infrun.c:4365
0x556e9a87b915 gdb_wait_for_event
../../gdbsupport/event-loop.cc:694
0x556e9a87c3a9 gdb_wait_for_event
../../gdbsupport/event-loop.cc:593
0x556e9a87c3a9 _Z16gdb_do_one_eventi
../../gdbsupport/event-loop.cc:217
0x556e9a521689 start_event_loop
../../gdb/main.c:412
0x556e9a521689 captured_command_loop
../../gdb/main.c:476
0x556e9a523c04 captured_main
../../gdb/main.c:1320
0x556e9a523c04 _Z8gdb_mainP18captured_main_args
../../gdb/main.c:1339
0x556e9a24b1bf main
../../gdb/gdb.c:32
---------------------
../../gdb/amd-dbgapi-target.c:1071: internal-error: process_one_event: Assertion `runtime_state == AMD_DBGAPI_RUNTIME_STATE_UNLOADED' failed.
A problem internal to GDB has been detected,
Before diving into why this error appears, let's explore how things are
expected to work in normal circumstances. When a process being debugged
starts using the ROCm runtime, the following happens:
- The runtime registers itself to the driver.
- The driver creates a "runtime loaded" event and notifies the debugger
that a new event is available by writing to a file descriptor which is
registered in GDB's main event loop.
- GDB core calls the callback associated with this file descriptor
(dbgapi_notifier_handler). Because the amd-dbgapi-target is not
pushed at this point, the handler pulls the "runtime loaded" event
from the driver (this is the only event which can be available at this
point) and eventually pushes the amd-dbgapi-target on the inferior's
target stack.
In a nutshell, this is the expected AMDGPU runtime activation process.
From there, when new events are available regarding the GPU threads, the
same file descriptor is written to. The callback sees that the
amd-dbgapi-target is pushed so marks the amd_dbgapi_async_event_handler.
This will later cause amd_dbgapi_target::wait to be called. The wait
method pulls all the available events from the driver and handles them.
The wait method returns the information conveyed by the first event, the
other events are cached for later calls of the wait method.
Note that because we are under the wait method, we know that the
amd-dbgapi-target is pushed on the inferior target stack. This implies
that the runtime activation event has been seen already. As a
consequence, we cannot receive another event indicating that the runtime
gets activated. This is what the failing assertion checks.
In the case when we have multiple inferiors however, there is a flaw in
what have been described above. If one inferior (let's call it inferior
1) already has the amd-dbgapi-target pushed to its target stack and
another inferior (inferior 2) activates the ROCm runtime, here is what
can happen:
- The driver creates the runtime activation for inferior 2 and writes to
the associated file descriptor.
- GDB has inferior 1 selected and calls target_wait for some reason.
- This prompts amd_dbgapi_target::wait to be called. The method pulls
all events from the driver, including the runtime activation event for
inferior 2, leading to the assertion failure.
The fix for this problem is simple. To avoid such problem, we need to
make sure that amd_dbgapi_target::wait only pulls events for the current
inferior from the driver. This is what this patch implements.
This patch also includes a testcase which could fail before this patch.
This patch has been tested on a system with multiple GPUs which had more
chances to reproduce the original bug. It has also been tested on top
of the downstream ROCgdb port which has more AMDGPU related tests. The
testcase has been tested with `make check check-read1 check-readmore`.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
It is not possible to debug multiple processes simultaneously on all
generations of AMDGPU devices. As some tests will need to debug
multiple inferiors using AMDGPU devices, we need to ensure that all
devices available have the required capability. Failing to do so would
result in GDB not being able to debug all inferiors properly.
Add the hip_devices_support_debug_multi_process helper function used to
ensure that all devices available can debug multiple processes.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Setting PYTHONMALLOC helped me locate an earlier bug. It seems to me
that there aren't big downsides to always setting this during testing,
and it might help find other bugs in the future.
|
|
This patch fixes a regression recently introduced in the BPF
disassembler, that was assuming an abfd was always available in
info->section->owner. Apparently this is not so in GDB, and therefore
https://sourceware.org/bugzilla/show_bug.cgi?id=30705.
Tested in bpf-unkonwn-none.
opcodes/ChangeLog:
2023-07-31 Jose E. Marchesi <jose.marchesi@oracle.com>
PR 30705
* bpf-dis.c (print_insn_bpf): Check that info->section->owner is
actually available before using it.
|
|
|
|
Tom de Vries found a bug where, sometimes, a SIGCHLD would be
delivered to a non-main thread, wreaking havoc.
The problem is that gdb.block_signals after first blocking a set of
signals, then unblocked the same set rather than restoring the initial
situation. This function being called from the DAP thread lead to
SIGCHLD being unblocked there.
This patch fixes the problem by restoring the previous set of signals
instead.
Tested-by: Tom de Vries <tdevries@suse.de>
Reviewed-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30680
|
|
gas/ChangeLog:
* testsuite/gas/riscv/rouding-fail.s: Moved to...
* testsuite/gas/riscv/rounding-fail.s: ...here.
* testsuite/gas/riscv/rouding-fail.d: Moved to...
* testsuite/gas/riscv/rounding-fail.d: ...here.
* testsuite/gas/riscv/rouding-fail.l: Moved to...
* testsuite/gas/riscv/rounding-fail.l: ...here.
|
|
This patch fixes some instructions in the BPF tests that overflow the
signed immediates. Note that this happened to work before by chance,
as GAS would silently truncate.
Tested in bpf-unknown-none.
Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>
|
|
|
|
Doug Evans, Yao Qi and myself are stepping down as GDB Global
Maintainers. This commit therefore moves our entries to the
"Past Maintainers" section.
I've also removed myself as Ada maintainer, as well as MIPS
authorized committer.
|
|
This patch adds support for EF_BPF_CPUVER bits in the ELF
machine-dependent header flags. These bits encode the BPF CPU
version for which the object file has been compiled for.
The BPF assembler is updated so it annotates the object files it
generates with these bits.
The BPF disassembler is updated so it honors EF_BPF_CPUVER to use the
appropriate ISA version if the user didn't specify an explicit ISA
version in the command line. Note that a value of zero in
EF_BPF_CPUVER is interpreted by the disassembler as "use the later
supported version" (the BPF CPU versions start with v1.)
The readelf utility is updated to pretty print EF_BPF_CPUVER when it
prints out the ELF header:
$ readelf -h a.out
ELF Header:
...
Flags: 0x4, CPU Version: 4
Tested in bpf-unknown-none.
include/ChangeLog:
2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
* elf/bpf.h (EF_BPF_CPUVER): Define.
* opcode/bpf.h (BPF_XBPF): Change from 0xf to 0xff so it fits in
EF_BPF_CPUVER.
binutils/ChangeLog:
2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
* readelf.c (get_machine_flags): Recognize and pretty print BPF
machine flags.
opcodes/ChangeLog:
2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-dis.c: Initialize asm_bpf_version to -1.
(print_insn_bpf): Set BPF ISA version from the cpu version ELF
header flags if no explicit version set in the command line.
* disassemble.c (disassemble_init_for_target): Remove unused code.
gas/ChangeLog:
2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
* config/tc-bpf.h (elf_tc_final_processing): Define.
* config/tc-bpf.c (bpf_elf_final_processing): New function.
|
|
This patch makes the BPF assembler to throughfully check for overflow
in immediates. This includes relaxed instructions.
Tested in bpf-unknown-none.
gas/ChangeLog:
2023-07-30 Jose E. Marchesi <jose.marchesi@oracle.com>
* config/tc-bpf.c (signed_overflow): Copy function from
tc-aarch64.c.
(encode_insn): Check for overflow in constant immediates.
(add_relaxed_insn): Pass relax argument to encode_insn.
(add_fixed_insn): Likewise.
* testsuite/gas/bpf/disp16-overflow.d: New file.
* testsuite/gas/bpf/disp16-overflow.s: Likewise.
* testsuite/gas/bpf/disp16-overflow.l: Likewise.
* testsuite/gas/bpf/disp32-overflow.d: Likewise.
* testsuite/gas/bpf/disp32-overflow.s: Likewise.
* testsuite/gas/bpf/disp32-overflow.l: Likewise.
* testsuite/gas/bpf/imm32-overflow.d: Likewise.
* testsuite/gas/bpf/imm32-overflow.s: Likewise.
* testsuite/gas/bpf/imm32-overflow.l: Likewise.
* testsuite/gas/bpf/offset16-overflow.d: Likewise.
* testsuite/gas/bpf/offset16-overflow.s: Likewise.
* testsuite/gas/bpf/offset16-overflow.l: Likewise.
* testsuite/gas/bpf/disp16-overflow-relax.d: Likewise.
* testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
* testsuite/gas/bpf/disp16-overflow-relax.s: Likewise.
* testsuite/gas/bpf/jump-relax-jump-be.d: New file.
* testsuite/gas/bpf/bpf.exp: Run new tests.
|
|
|
|
|
|
|
|
|
|
The BPF jump-always instruction (JA), like all other jump instructions
in the ISA, get a signed 16-bit displacement target argument denoted
in number of 64-bit words minus one. This can sometimes be overflown.
The BPF V4 ISA thus introduced support for a jump-always
instruction (JAL) that gets a signed 32-bit displacement instead.
This patch makes the BPF assembler to perform the following
relaxations when the disp16 field gets overflown, unless the option
-mno-relax is specified:
JA disp16 -> JAL disp32
Jxx disp16 -> Jxx +1; JA +1; JAL disp32
Documentation and tests added.
Tested in bpf-unknown-none.
gas/ChangeLog:
2023-07-28 Jose E. Marchesi <jose.marchesi@oracle.com>
PR gas/30690
* config/tc-bpf.c (struct bpf_insn): Add fields is_relaxable and
relaxed_exp.
(enum options): Add OPTION_NO_RELAX.
(md_longopts): Likewise for -mno-relax.
(do_relax): New global.
(md_parse_option): Handle OPTION_NO_RELAX.
(RELAX_BRANCH_ENCODE): Define.
(RELAX_BRANCH_P): Likewise.
(RELAX_BRANCH_LENGTH): Likewise.
(RELAX_BRANCH_CONST): Likewise.
(RELAX_BRANCH_UNCOND): Likewise.
(relaxed_branch_length): New function.
(md_estimate_size_before_relax): Likewise.
(read_insn_word): Likewise.
(encode_int16): Likewise.
(encode_int32): Likewise.
(write_insn_bytes): Likewise.
(md_convert_frag): Likewise.
(encode_insn): Likewise.
(install_insn_fixups): Likewise.
(add_fixed_insn): Likewise.
(add_relaxed_insn): Likewise.
(md_assemble): Move instruction encoding logic to the above
new functions.
* testsuite/gas/bpf/jump-relax-ja.d: New test.
* testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja.s: And corresponding source.
* testsuite/gas/bpf/jump-relax-jump.d: New test.
* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
* testsuite/gas/bpf/jump-relax-jump.s: And corresponding source.
* testsuite/gas/bpf/bpf.exp: Run new tests.
* doc/c-bpf.texi (BPF Options): Document -mno-relax.
|
|
I noticed that the variable main_thread:
...
/* The main thread. */
static std::thread::id main_thread;
...
has a confusing name and corresponding comment, because it doesn't contain the
main thread, but rather the main thread's std::thread::id.
Fix this by renaming to main_thread_id.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Tom de Vries filed a bug about an intermittent gdb DAP failure -- and
coincidentally, at the same time, Alexandra Hájková sent email about a
somewhat similar failure.
After looking into this for a while (with no results) using ASan and
valgrind, I found that setting PYTHONMALLOC=malloc_debug found the bug
instantly.
The problem is that gdbpy_parse_and_eval releases the GIL while
calling parse_and_eval, but fails to re-acquire it before calling
value_to_value_object. This is easily fixed by introducing a new
scope.
I wonder whether the test suite should unconditionally set
PYTHONMALLOC=malloc_debug.
Tested-by: Tom de Vries <tdevries@suse.de>
Reviewed-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30686
|
|
PR gas/30688
X_unsigned being clear does not indicate a negative number; it merely
indicates a signed one (whose sign may still be clear). Amend two uses
by an actual value check.
|