aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-08-022.41 Release sourcesbinutils-2_41-releaseNick Clifton288-20767/+159122
2023-08-01gprofng: Fix build with 64bit file offset on 32bit machinesKhem Raj1-3/+6
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.
2023-08-02Automatic date update in version.inGDB Administrator1-1/+1
2023-08-02Don't declare xmalloc and others in ldmisc.hAlan Modra7-7/+10
* 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.
2023-08-02Don't declare xmalloc or xrealloc in bucomm.hAlan Modra3-6/+2
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.
2023-08-02Regen ld/configureAlan Modra1-1/+1
For commit 3d05c80b5dc4.
2023-08-01Implement DAP "source" requestTom Tromey4-4/+97
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
2023-08-01Handle Source in DAP breakpointLocationsTom Tromey2-8/+20
This changes the DAP breakpointLocations request to accept a Source and to decode it properly.
2023-08-01Introduce sourceReference handling in DAPTom Tromey3-20/+41
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.
2023-08-01Don't supply DAP 'path' for non-file shared librariesTom Tromey1-2/+4
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
2023-08-01Implement ValueFormat for DAPTom Tromey4-78/+124
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
2023-08-01Respect supportsMemoryReferences in DAPTom Tromey5-12/+13
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.
2023-08-01Add DAP support for C++ exceptionsTom Tromey3-4/+119
This adds DAP support for the various C++ exception-catching operations. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30682
2023-08-01Implement DAP 'terminated' eventTom Tromey3-1/+41
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
2023-08-01Do not send "new breakpoint" event when breakpoint is setTom Tromey2-13/+34
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
2023-08-01Move DAP breakpoint event code to breakpoint.pyTom Tromey2-39/+40
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.
2023-08-01Full paths in DAP stackTrace responsesTom Tromey2-51/+82
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
2023-08-01Add "cwd" parameter to DAP launch requestTom Tromey4-17/+70
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>
2023-08-01Refactor dap_launchTom Tromey3-28/+43
This patch refactors dap_launch to make it more extensible and also easier to use.
2023-08-01Rename private member of FrameDecoratorTom Tromey1-4/+4
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.
2023-08-01Add thread exited eventSimon Farre1-7/+18
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>
2023-08-01Fix "--only-keep-debug for ELF relocatables" binutils test for compilers ↵Nick Clifton1-1/+6
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.
2023-08-01gas: rework timestamp preservation on doc/asconfig.texiJan Beulich2-2/+2
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.
2023-08-01Add note to check that all changes have been pushed before creating the ↵Nick Clifton1-1/+5
source tarballs
2023-08-01ld: Fix test failures with --enable-textrel-check=errorSam James8-8/+8
2023-07-31gprofng: create a list of available viewsVladimir Mezentsev2-2/+14
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.
2023-08-01Automatic date update in version.inGDB Administrator1-1/+1
2023-07-31[gdb/testsuite] Set TSAN_OPTIONS by default to history_size=7Tom de Vries1-0/+8
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
2023-07-31Fix bug in fixed-point handlingTom Tromey3-0/+13
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.
2023-07-31ld: fix typo in --enable-warn-rwx-segments helpSam James1-1/+1
2023-07-31gdb/amdgpu: Fix debugging multiple inferiors using the ROCm runtimeLancelot Six3-3/+207
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>
2023-07-31gdb/testsuite/rocm: Add the hip_devices_support_debug_multi_process procLancelot Six1-0/+20
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>
2023-07-31Set PYTHONMALLOC in the test suiteTom Tromey1-0/+4
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.
2023-07-31bpf: opcodes: fix regression in BPF disassemblerJose E. Marchesi2-1/+7
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.
2023-07-31Updated Spanish translation for the gprof directoryNick Clifton1-42/+42
2023-07-31Restore previous sigmask in gdb.block_signalsTom Tromey1-2/+2
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
2023-07-31RISC-V: Fix typo in the test case nameTsukasa OI4-3/+3
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.
2023-07-31bpf: sim: do not overflow instruction immediates in testsJose E. Marchesi5-11/+11
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>
2023-07-31Automatic date update in version.inGDB Administrator1-1/+1
2023-07-30GDB Global Maintainer update (3 maintainers stepping down)Joel Brobecker1-5/+3
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.
2023-07-30bpf: include, bfd, opcodes: add EF_BPF_CPUVER ELF header flagsJose E. Marchesi12-22/+77
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.
2023-07-30bpf: gas: add field overflow checking to the BPF assemblerJose E. Marchesi19-8/+162
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.
2023-07-30Update how to make a release document after the 2.41 releaseNick Clifton1-12/+17
2023-07-30Automatic date update in version.inGDB Administrator1-1/+1
2023-07-29Automatic date update in version.inGDB Administrator1-1/+1
2023-07-28bpf: remove spurious comment from tc-bpf.cJose E. Marchesi1-2/+0
2023-07-28bpf: gas: support relaxation of V4 jump instructionsJose E. Marchesi9-308/+858
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.
2023-07-28[gdb] Rename variable main_thread to main_thread_idTom de Vries1-4/+4
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>
2023-07-28Re-acquire GIL earlier in gdbpy_parse_and_evalTom Tromey1-2/+10
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
2023-07-28gas: amend X_unsigned usesJan Beulich5-4/+37
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.
generated by cgit v1.1 at 2024-08-26 08:21:20 +0000