aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-11-02aarch64: Add support for GCSB DSYNC instruction.Srinath Parvathaneni13-2299/+2295
This patch adds support for Guarded control stack data synchronization instruction (GCSB DSYNC). This instruction is allocated to existing HINT space and uses the HINT number 19 and to match this an entry is added to the aarch64_hint_options array.
2023-11-02aarch64: Add support for GCS extension.srinath12-2511/+2688
This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is optional from Armv9.4-A architecture and enabled by passing +gcs option to -march (eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file. Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx, gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr.
2023-11-02aarch64: Add support for Check Feature Status Extension.Srinath Parvathaneni12-12/+83
This patch adds support for Check Feature Status Extension (CHK) which is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction (hint #40).
2023-11-02aarch64: Add support for Armv8.9-A and Armv9.4-A Architectures.srinath4-3/+14
This patch adds AArch64 support for Armv8.9-A architecture (-march=armv8.9-a) and Armv9.4-A architecture (-march=armv9.4-a).
2023-11-02ld x86_64 tests: Accept x86-64-v3 as a needed ISANick Clifton4-3/+10
* testsuite/ld-x86-64/property-3.r: Update regexp to allow for targets which support x86-64-v3. * testsuite/ld-x86-64/property-4.r: Likewise. * testsuite/ld-x86-64/property-5.r: Likewise.
2023-11-01gprofng: remove dependency on help2manVladimir Mezentsev6-66/+2
help2man is no longer used to create the gprofng man pages. gprofng/ChangeLog 2023-10-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * configure.ac: Remove HELP2MAN. * Makefile.in: Rebuild. * configure: Rebuild. * doc/Makefile.in: Rebuild. * gp-display-html/Makefile.in: Rebuild. * src/Makefile.in: Rebuild.
2023-11-02Automatic date update in version.inGDB Administrator1-1/+1
2023-11-01gdb: use gdb::byte_vector instead of gdb::def_vector<gdb_byte>Simon Marchi4-6/+6
Use the gdb::byte_vector typedef when possible. Change-Id: Ib2199201c052496992011ea02979de023d4d8a9a
2023-11-01Fix typo in recent update to the ld/NEWS fileNick Clifton1-2/+2
2023-11-01ld: Support input section description keyword: REVERSENick Clifton18-39/+274
PR 27565 * ldlex.l: Add REVERSE. * ldgram.y: Allow REVERSE to be used wherever a sorting command can be used. * ld.h (struct wildcard_spec): Add 'reversed' field. * ldlang.h (lang_wild_statement_struct): Add 'filenames_reversed' field. * ldlang.c (compare_sections): Add reversed parameter. (wild_sort): Reverse the comparison if requested. (print_wild_statement): Handle the reversed field. * ld.texi: Document the new feature. * NEWS: Mention the new feature. * testsuite/ld-scripts/sort-file-reversed-1.d: New test driver. * testsuite/ld-scripts/sort-file-reversed-1.t: New test source. * testsuite/ld-scripts/sort-file-reversed-2.t: New test source. * testsuite/ld-scripts/sort-file-reversed-2.d: New test driver. * testsuite/ld-scripts/sort-sections-reversed-1.d: New test driver. * testsuite/ld-scripts/sort-sections-reversed-1.t: New test source. * testsuite/ld-scripts/sort-sections-reversed-2.t: New test source. * testsuite/ld-scripts/sort-sections-reversed-2.d: New test driver. * testsuite/ld-scripts/sort-sections-reversed-3.d: New test driver. * testsuite/ld-scripts/sort-sections-reversed-3.t: New test source.
2023-11-01Automatic date update in version.inGDB Administrator1-1/+1
2023-11-01[gdb/symtab] Work around gas PR28629Tom de Vries4-1/+130
When running test-case gdb.tui/tui-layout-asm-short-prog.exp on AlmaLinux 9.2 ppc64le, I run into: ... FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents ... The problem is that we get: ... 7 [ No Assembly Available ] ... because tui_get_begin_asm_address doesn't succeed. In more detail, tui_get_begin_asm_address calls: ... find_line_pc (sal.symtab, sal.line, &addr); ... with: ... (gdb) p *sal.symtab $5 = {next = 0x130393c0, m_compunit = 0x130392f0, m_linetable = 0x0, filename = "tui-layout-asm-short-prog.S", filename_for_id = "$gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S", m_language = language_asm, fullname = 0x0} (gdb) p sal.line $6 = 1 ... The problem is the filename_for_id which is the source file prefixed with the compilation dir rather than the source dir. This is due to faulty debug info generated by gas, PR28629: ... <1a> DW_AT_name : tui-layout-asm-short-prog.S <1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite <22> DW_AT_producer : GNU AS 2.35.2 ... The DW_AT_name is relative, and it's relative to the DW_AT_comp_dir entry, making the effective name $gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S. The bug is fixed starting version 2.38, where we get instead: ... <1a> DW_AT_name : $gdb/src/gdb/testsuite/gdb.tui/tui-layout-asm-short-prog.S <1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite <22> DW_AT_producer : GNU AS 2.38 ... Work around the faulty debug info by constructing the filename_for_id using the second directory from the directory table in the .debug_line header: ... The Directory Table (offset 0x22, lines 2, columns 1): Entry Name 0 $gdb/build/gdb/testsuite 1 $gdb/src/gdb/testsuite/gdb.tui ... Note that the used gas contains a backport of commit 3417bfca676 ("GAS: DWARF-5: Ensure that the 0'th entry in the directory table contains the current working directory."), because directory 0 is correct. With the unpatched 2.35.2 release the directory 0 entry is incorrect: it's a copy of entry 1. Add a dwarf assembly test-case that reflects the debug info as generated by unpatched gas 2.35.2. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-01[gdb/symtab] Add producer_is_gasTom de Vries3-2/+63
Add producer_is_gas, a generic way to get the gas version from the producer string. Tested on x86_64-linux.
2023-10-31Implement DAP setVariable requestTom Tromey6-21/+311
This patch implements the DAP setVariable request. setVariable is a bit odd in that it specifies the variable to modify by passing in the variable's container and the name of the variable. This approach can't handle variable shadowing (there are a couple of open DAP bugs on this topic), so this patch renames duplicates to avoid the problem.
2023-10-31Support Intel USER_MSRHu, Lin119-1171/+1522
This patches aims to support Intel USER_MSR. In addition to the usual support, this patch includes encoding and decoding support for MAP7 and immediate numbers as the last operand (ATT style). gas/ChangeLog: * NEWS: Support Intel USER_MSR. * config/tc-i386.c (smallest_imm_type): Reject imm32 in 64bit mode. (build_vex_prefix): Add VEXMAP7. (md_assemble): Handling the imm32 of USER_MSR. (match_template): Handling the unusual immediate. * doc/c-i386.texi: Document .user_msr. * testsuite/gas/i386/i386.exp: Run USER_MSR tests. * testsuite/gas/i386/x86-64.exp: Ditto. * testsuite/gas/i386/user_msr-inval.l: New test. * testsuite/gas/i386/user_msr-inval.s: Ditto. * testsuite/gas/i386/x86-64-user_msr-intel.d: Ditto. * testsuite/gas/i386/x86-64-user_msr-inval.l: Ditto. * testsuite/gas/i386/x86-64-user_msr-inval.s: Ditto. * testsuite/gas/i386/x86-64-user_msr.d: Ditto. * testsuite/gas/i386/x86-64-user_msr.s: Ditto. opcodes/ChangeLog: * i386-dis.c (struct instr_info): Add a new attribute has_skipped_modrm. (Gq): New. (Rq): Ditto. (q_mm_mode): Ditto. (Nq): Change mode from q_mode to q_mm_mode. (VEX_LEN_TABLE): (get_valid_dis386): Add VEX_MAP7 in VEX prefix. and handle the map7_f8 for save space. (OP_Skip_MODRM): Set has_skipped_modrm. (OP_E): Skip codep++ when has skipped modrm byte. (OP_R): Support q_mode and q_mm_mode. (REG_VEX_MAP7_F8_L_0_W_0): New. (PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64): Ditto. (X86_64_VEX_MAP7_F8_L_0_W_0_R_0): Ditto. (VEX_LEN_MAP7_F8): Ditto. (VEX_W_MAP7_F8_L_0): Ditto. (MOD_0F38F8): Ditto. (PREFIX_0F38F8_M_0): Ditto. (PREFIX_0F38F8_M_1_X86_64): Ditto. (X86_64_0F38F8_M_1): Ditto. (PREFIX_0F38F8): Remove. (prefix_table): Add PREFIX_0F38F8_M_1_X86_64. Remove PREFIX_0F38F8. (reg_table): Add REG_VEX_MAP7_F8_L_0_W_0, PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64. (x86_64_table): Add X86_64_0F38F8_PREFIX_3_M_1, X86_64_VEX_MAP7_F8_L_0_W_0_R_0 and X86_64_0F38F8_M_1. (vex_table): Add VEX_MAP7. (vex_len_table): Add VEX_LEN_MAP7_F8, VEX_W_MAP7_F8_L_0. (mod_table): New entry for USER_MSR and add MOD_0F38F8. * i386-gen.c (cpu_flag_init): Add CPU_USER_MSR_FLAGS and CPU_ANY_USER_MSR_FLAGS. Add add VEXMAP7. * i386-init.h: Regenerated. * i386-mnem.h: Ditto. * i386-opc.h (SPACE_VEXMAP7): New. (CPU_USER_MSR_FLAGS): Ditoo. (CPU_ANY_USER_MSR_FLAGS): Ditto. (i386_cpu_flags): Add cpuuser_msr. * i386-opc.tbl: Add USER_MSR instructions. * i386-tbl.h: Regenerated.
2023-10-30Remove some frame invalidation codeTom Tromey3-19/+3
I stumbled across a few spots that mention that a function "invalidates frame" and also assignments of NULL to a frame_info_ptr. This code isn't harmful, but is also unnecessary since the introduction of frame_info_ptr -- nowadays frame invalidations are handled automatically. Regression tested on x86-64 Fedora 38. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-10-31Automatic date update in version.inGDB Administrator1-1/+1
2023-10-30New Georgian translation for the ld sub-directoryNick Clifton2-0/+6620
2023-10-30gas: bpf: new test for MOV with C-like numbers ll suffixJose E. Marchesi4-0/+11
The BPF pseudo-c syntax supports both MOV and LDDW instructions: mov: r1 = EXPR lddw: r1 = EXPR ll Note that the white space between EXPR and `ll' is necessary in order to avoid ambiguity with the assembler's support for C-like numerical suffixes. This patch adds a new test to the GAS BPF testsuite to make sure that instructions like: r1 = 666ll are interpreted as `mov %r1,666', not as `lddw %r1,666'. This matches clang's assembler behavior. 2023-10-30 Jose E. Marchesi <jose.marchesi@oracle.com> * testsuite/gas/bpf/alu-pseudoc.s: Add test to make sure C-like suffix `ll' is not interpreted as lddw syntax. * testsuite/gas/bpf/alu-pseudoc.d: Update expected results. * testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
2023-10-30Fix fixed-point "return" on ARMTom Tromey1-3/+15
On a big-endian ARM machine, the "return" command resulted in the wrong value being returned when the function had a fixed-point return type. This patch fixes the problem by unpacking and repacking the fixed-point type appropriately. Approved-By: Luis Machado <luis.machado@arm.com>
2023-10-30Fix range-type "return" command on ARMTom Tromey1-0/+3
On big-endian ARM, "return"ing from a function that returned a range type did not work. This patch strips the range type to treat the function as though it were returning the underlying type instead. Approved-By: Luis Machado <luis.machado@arm.com>
2023-10-30Fix "finish" for vector types on ARMTom Tromey1-20/+6
On a big-endian ARM system, "finish" printed the wrong value when finishing from a function that returned a vector type. Similarly, calls to a function also resulted in the wrong value being passed. I think both the read- and write-functions here should ignore the endian-ness. I tested this using the AdaCore internal test suite; the test case that caught this is identical to gdb.base/gnu_vector.exp. Approved-By: Luis Machado <luis.machado@arm.com>
2023-10-30Fix "finish" with range types on ARMTom Tromey1-0/+3
On ARM (I tested big-endian but it may not matter), "finish" can sometimes print the wrong result when the return type is a range type. Range types should really be treated as their underlying type (normally integer, but sometimes fixed-point). This patch implements this. Approved-By: Luis Machado <luis.machado@arm.com>
2023-10-30Fix calls with small integers on ARMTom Tromey1-3/+0
On big-endian ARM, an inferior call with a small integer will pass the wrong value. This patch fixes the problem. Because the code here works using scalar values, and not just bytes, left-shifting is unnecessary. Approved-By: Luis Machado <luis.machado@arm.com>
2023-10-30Accept and ignore the R_BPF_64_NODLYD32 relocation.Nick Clifton4-2/+28
2023-10-30aarch64: Update aarch64-sys-regs.def headerVictor Do Nascimento1-0/+4
Given the shared use of the aarch64-sys-regs.def file across Binutils and GCC, add instructions for keeping the file synchronized across the two codebases. Namely, it should be made clear that all changes are first to be made in Binutils and the updated file copied across to GCC. opcodes/ChangeLog * opcodes/aarch64-sys-regs.def: Update file-description header comment.
2023-10-30Automatic date update in version.inGDB Administrator1-1/+1
2023-10-29Move read_addrmap_from_aranges to new fileTom Tromey6-186/+239
In the interest of shrinking dwarf2/read.c a little more, this patch moves the code that deciphers .debug_aranges into a new file. Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
2023-10-29Pre-read .debug_aranges sectionTom Tromey2-5/+7
While working on background DWARF reading, I found a race case that I tracked down to the handling of the .debug_aranges section. Currently the section data is only read in after the CUs have all been created. However, there's no real reason to do this -- it seems fine to read it a little earlier, when all the other necessary sections are read in. This patch makes this change, and updates the read_addrmap_from_aranges API to assert that the section is read in. This patch slightly changes the read_addrmap_from_aranges API as well, to reject an empty section. This seems better to me than what the current code does, which is try to read an empty section but then do no work. Regression tested on x86-64 Fedora 38. Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
2023-10-29Automatic date update in version.inGDB Administrator1-1/+1
2023-10-28gdb/gdbsupport/gdbserver: Require c++17Lancelot Six12-90/+4575
This patch proposes to require a C++17 compiler to build gdb / gdbsupport / gdbserver. Before this patch, GDB required a C++11 compiler. The general policy regarding bumping C++ language requirement in GDB (as stated in [1]) is: Our general policy is to wait until the oldest compiler that supports C++NN is at least 3 years old. Rationale: We want to ensure reasonably widespread compiler availability, to lower barrier of entry to GDB contributions, and to make it easy for users to easily build new GDB on currently supported stable distributions themselves. 3 years should be sufficient for latest stable releases of distributions to include a compiler for the standard, and/or for new compilers to appear as easily installable optional packages. Requiring everyone to build a compiler first before building GDB, which would happen if we required a too-new compiler, would cause too much inconvenience. See the policy proposal and discussion [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html). The first GCC release which with full C++17 support is GCC-9[2], released in 2019[3], which is over 4 years ago. Clang has had C++17 support since Clang-5[4] released in 2018[5]. A discussions with many distros showed that a C++17-able compiler is always available, meaning that this no hard requirement preventing us to require it going forward. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F [2] https://gcc.gnu.org/projects/cxx-status.html#cxx17 [3] https://gcc.gnu.org/gcc-9/ [4] https://clang.llvm.org/cxx_status.html [5] https://releases.llvm.org/ Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-28gdb/ax_cxx_compile_stdcxx.m4: upgradeLancelot Six4-74/+184
This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes available in [1] and regenerates the configure script. [1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-28gas: tc-bpf.c: fix formatting of commentJose E. Marchesi1-4/+5
2023-10-28opcodes: bpf-dis.c: fix typo in commentJose E. Marchesi1-1/+1
2023-10-28Automatic date update in version.inGDB Administrator1-1/+1
2023-10-27gdb: trim trailing spaces in i386-tdep.{c,h}Simon Marchi2-18/+18
Change-Id: I06c2e7c958c3451f00c70978538c1c2ad1b566df
2023-10-27RISC-V: Clarify the behaviors of SET/ADD/SUB relocations.Nelson Chu2-6/+17
We are used to generate these kinds of relocations by data directives. Considering the following example, .word (A + 3) - (B + 2) The GAS will generate a pair of ADD/SUB for this, R_RISCV_ADD, A + 1 R_RISCV_SUB, 0 The addend of R_RISCV_SUB will always be zero, and the summary of the constants will be stored in the addend of R_RISCV_ADD/SET. Therefore, we can always add the addend of these data relocations when doing relocations. But unfortunately, I had heard that if we are using .reloc to generate the data relocations will make the relocations failed. Refer to this, .reloc offset, R_RISCV_ADD32, A + 3 .reloc offset, R_RISCV_SUB32, B + 2 .word 0 Then we can get the relocations as follows, R_RISCV_ADD, A + 3 R_RISCV_SUB, B + 2 Then... Current LD does the relocation, B - A + 3 + 2, which is wrong obviously... So first of all, this patch fixes the wrong relocation behavior of R_RISCV_SUB* relocations. Afterwards, considering the uleb128 direcitve, we will get a pair of SET_ULEB128/SUB_ULEB128 relocations for it for now, .uleb128 (A + 3) - (B + 2) R_RISCV_SET_ULEB128, A + 1 R_RISCV_SUB_ULEB128, B + 1 Which looks also wrong obviously, the summary of the constants should only be stored into the addend of SET_ULEB128, and the addend of SUB_ULEB128 should be zero like other SUB relocations. But the current LD will still get the right relocation values since we only add the addend of SUB_ULEB128 by accident... Anyway, this patch also fixes the behaviors above, to make sure that no matter using .uleb128 or .reloc directives, we should always get the right values. bfd/ * elfnn-riscv.c (perform_relocation): Clarify that SUB relocations should substract the addend, rather than add. (riscv_elf_relocate_section): Since SET_ULEB128 won't go into perform_relocation, we should add it's addend here in advance. gas/ * config/tc-riscv.c (riscv_insert_uleb128_fixes): Set the addend of SUB_ULEB128 to zero since it should already be added into the addend of SET_ULEB128.
2023-10-27Automatic date update in version.inGDB Administrator1-1/+1
2023-10-26gdb/python: Add new gdb.Value.bytes attributeAndrew Burgess4-20/+230
Add a gdb.Value.bytes attribute. This attribute contains the bytes of the value (assuming the complete bytes of the value are available). If the bytes of the gdb.Value are not available then accessing this attribute raises an exception. The bytes object returned from gdb.Value.bytes is cached within GDB so that the same bytes object is returned each time. The bytes object is created on-demand though to reduce unnecessary work. For some values we can of course obtain the same information by reading inferior memory based on gdb.Value.address and gdb.Value.type.sizeof, however, not every value is in memory, so we don't always have an address. The gdb.Value.bytes attribute will convert any value to a bytes object, so long as the contents are available. The value can be one created purely in Python code, the value could be in a register, or (of course) the value could be in memory. The Value.bytes attribute can also be assigned too. Assigning to this attribute is similar to calling Value.assign, the value of the underlying value is updated within the inferior. The value assigned to Value.bytes must be a buffer which contains exactly the correct number of bytes (i.e. unlike value creation, we don't allow oversized buffers). To support this assignment like behaviour I've factored out the core of valpy_assign. I've also updated convert_buffer_and_type_to_value so that it can (for my use case) check the exact buffer length. The restrictions for when the Value.bytes can or cannot be written too are exactly the same as for Value.assign. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13267 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2023-10-26gdb: handle main thread exiting during detachAndrew Burgess5-8/+255
Overview ======== Consider the following situation, GDB is in non-stop mode, the main thread is running while a second thread is stopped. The user has the second thread selected as the current thread and asks GDB to detach. At the exact moment of detach the main thread exits. This situation currently causes crashes, assertion failures, and unexpected errors to be reported from GDB for both native and remote targets. This commit addresses this situation for native and remote targets. There are a number of different fixes, but all are required in order to get this functionality working correct for native and remote targets. Native Linux Target =================== For the native Linux target, detaching is handled in the function linux_nat_target::detach. In here we call stop_wait_callback for each thread, and it is this callback that will spot that the main thread has exited. GDB then detaches from everything except the main thread by calling detach_callback. After this the first problem is this assert: /* Only the initial process should be left right now. */ gdb_assert (num_lwps (pid) == 1); The num_lwps call will return 0 as the main thread has exited and all of the other threads have now been detached. I fix this by changing the assert to allow for 0 or 1 lwps at this point. As the 0 case can only happen in non-stop mode, the assert becomes: gdb_assert (num_lwps (pid) == 1 || (target_is_non_stop_p () && num_lwps (pid) == 0)); The next problem is that we do: main_lwp = find_lwp_pid (ptid_t (pid)); and then proceed assuming that main_lwp is not nullptr. In the case that the main thread has exited though, main_lwp will be nullptr. However, we only need main_lwp so that GDB can detach from the thread. If the main thread has exited, and GDB has already detached from every other thread, then GDB has finished detaching, GDB can skip the calls that try to detach from the main thread, and then tell the user that the detach was a success. For Remote Targets ================== On remote targets there are two problems. First is that when the exit occurs during the early phase of the detach, we see the stop notification arrive while GDB is removing the breakpoints ahead of the detach. The 'set debug remote on' trace looks like this: [remote] Sending packet: $z0,7f1648fe0241,1#35 [remote] Notification received: Stop:W0;process:2a0ac8 # At this point an unpatched gdbserver segfaults, and the connection # is broken. A patched gdbserver continues as below... [remote] Packet received: E01 [remote] Sending packet: $z0,7f1648ff00a8,1#68 [remote] Packet received: E01 [remote] Sending packet: $z0,7f1648ff132f,1#6b [remote] Packet received: E01 [remote] Sending packet: $D;2a0ac8#3e [remote] Packet received: E01 I was originally running into Segmentation Faults, from within gdbserver/mem-break.cc, in the function find_gdb_breakpoint. This function calls current_process() and then dereferences the result to find the breakpoint list. However, in our case, the current process has already exited, and so the current_process() call returns nullptr. At the point of failure, the gdbserver backtrace looks like this: #0 0x00000000004190e4 in find_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:982 #1 0x000000000041930d in delete_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:1093 #2 0x000000000042d8db in process_serial_event () at ../../src/gdbserver/server.cc:4372 #3 0x000000000042dcab in handle_serial_event (err=0, client_data=0x0) at ../../src/gdbserver/server.cc:4498 ... The problem is that, as a result non-stop being on, the process exiting is only reported back to GDB after the request to remove a breakpoint has been sent. Clearly gdbserver can't actually remove this breakpoint -- the process has already exited -- so I think the best solution is for gdbserver just to report an error, which is what I've done. The second problem I ran into was on the gdb side, as the process has already exited, but GDB has not yet acknowledged the exit event, the detach -- the 'D' packet in the above trace -- fails. This was being reported to the user with a 'Can't detach process' error. As the test actually calls detach from Python code, this error was then becoming a Python exception. Though clearly the detach has returned an error, and so, maybe, having GDB throw an error would be fine, I think in this case, there's a good argument that the remote error can be ignored -- if GDB tries to detach and gets back an error, and if there's a pending exit event for the pid we tried to detach, then just ignore the error and pretend the detach worked fine. We could possibly check for a pending exit event before sending the detach packet, however, I believe that it might be possible (in non-stop mode) for the stop notification to arrive after the detach is sent, but before gdbserver has started processing the detach. In this case we would still need to check for pending stop events after seeing the detach fail, so I figure there's no point having two checks -- we just send the detach request, and if it fails, check to see if the process has already exited. Testing ======= In order to test this issue I needed to ensure that the exit event arrives at the same time as the detach call. The window of opportunity for getting the exit to arrive is so small I've never managed to trigger this in real use -- I originally spotted this issue while working on another patch, which did manage to trigger this issue. However, if we trigger both the exit and the detach from a single Python function then we never return to GDB's event loop, as such GDB never processes the exit event, and so the first time GDB gets a chance to see the exit is during the detach call. And so that is the approach I've taken for testing this patch. Tested-By: Kevin Buettner <kevinb@redhat.com> Approved-By: Kevin Buettner <kevinb@redhat.com>
2023-10-26[gdb/testsuite] Add wait-for-index-cache in gdb.dwarf2/per-bfd-sharing.expTom de Vries1-0/+1
If we make writing an index-cache entry very slow by doing this in index_cache::store: ... try { + sleep (15); index_cache_debug ("writing index cache for objfile %s", bfd_get_filename (per_bfd->obfd)); ... we run into: ... FAIL: gdb.dwarf2/per-bfd-sharing.exp: \ couldn't remove files in temporary cache dir ... The FAIL happens because there is no index-cache entry in the cache dir. The problem is that gdb is killed (by gdb_exit) before the index-cache entry is written. Fix this by using "maint wait-for-index-cache". Tested on x86_64-linux. PR testsuite/30528 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30528
2023-10-25gdb/nat/aarch64-scalable-linux-ptrace.h: Don't include itselfThiago Jung Bauermann1-1/+0
GCC doesn't complain, but it's still wrong.
2023-10-26Automatic date update in version.inGDB Administrator1-1/+1
2023-10-25gdb/testsuite: add a clang XFAIL to gdb.python/py-watchpoint.expGuinevere Larsen1-1/+16
Clang doesn't use CFA information for variable locations. This makes it so software breakpoints get a false hit when rbp gets popped, causing a FAIL in gdb.python/py-watchpoint.exp. Since this is nothing wrong with GDB itself, add an xfail to reduce noise. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-25gdb/testsuite: fix running gdb.python/py-explore-cc with clangGuinevere Larsen1-1/+2
The test gdb.python/py-explore-cc.exp was showing one unexpected failure. This was due to how clang mapped instructions to lines, resulting in the inferior seemingly stopping at a different location. This patch adds a nop line in the relevant location so we don't need to add XFAILs for existing clang releases, if this gets solved in future versions. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-25gdbserver: don't leak program name in handle_v_runAndrew Burgess1-14/+56
I noticed that in handle_v_run (gdbserver/server.cc) we leak new_program_name (a string) each time GDB starts an inferior, in the case where GDB passes a program name to gdbserver. This bug was introduced with this commit: commit 7ab2607f97e5deaeae91018edf3ef5b4255a842c Date: Wed Apr 13 17:31:02 2022 -0400 gdbsupport: make gdb_abspath return an std::string When gdbserver receives a program name from GDB, this is first placed into a malloc'd buffer within handle_v_run, and this buffer is then used in this call: program_path.set (new_program_name); Prior to the above commit this call took ownership of the buffer passed to it, but now this call uses the buffer to initialise a std::string, which copies the buffer contents, leaving ownership with the caller. So now, after this call (in handle_v_run) new_program_name still owns a buffer. At no point in handle_v_run do we free new_program_name, as a result we are leaking the program name each time GDB starts a remote inferior. I could solve this by adding a 'free' call into handle_v_run, but I'd rather automate the memory management. So, to this end, I have added a new function in gdbserver/server.cc, decode_v_run_arg. This function takes care of allocating the memory buffer and decoding the vRun packet into the buffer, but returns a gdb::unique_xmalloc_ptr<char> (or nullptr on error). Back in handle_v_run I have converted new_program_name to also be a gdb::unique_xmalloc_ptr<char>. Now, after we call program_path.set(), the allocated buffer will be automatically released when it is no longer needed. It is worth highlighting that within the new decode_v_run_arg function, I have wrapped the call to hex2bin in a try/catch block. The hex2bin function can throw an exception if it encounters an invalid (non-hex) character. Back in handle_v_run, we have a local argument new_argv, which is of type std::vector<char *>. Each 'char *' in this vector is a malloc'd buffer. If we allow hex2bin to throw an exception and don't catch it in either decode_v_run_arg or handle_v_run then we are going to leak memory from new_argv. I chose to catch the exception in decode_v_run_arg, this seemed cleanest, but I'm not sure it really matters, so long as the exception is caught before we leave handle_v_run. I am working on a patch that changes new_argv to automatically manage its memory, but that isn't ready for posting yet. I think what I have here would be fine if my follow on patch never arrives. Additionally, within the handle_v_run loop I have changed an assignment of nullptr to new_program_name into an assert. Previously, the assignment could only trigger on the first iteration of the loop, if we had no new program name to assign. However, new_program_name always starts as nullptr, so, on the first loop iteration, if we have nothing to assign to new_program_name, its value must already be nullptr. There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-10-25gdb: make get_symbol_address a private method of symbolSimon Marchi2-14/+13
get_symbol_address is only used symbol::value_address, make it a private helper method. Change-Id: I318ddcfcf1269d95045b8efe9137812df9c5113c Approved-By: Tom Tromey <tom@tromey.com>
2023-10-25gdb: make get_msymbol_address a private method of minimal_symbolSimon Marchi2-15/+13
get_msymbol_address is only used in minimal_symbol::value_address. Make it a private helper method. Change-Id: I3f30e1b9d89ace6682fb08a7ebb91746db0ccf0f Approved-By: Tom Tromey <tom@tromey.com>
2023-10-24gprofng: Fix -Wformat= warningsVladimir Mezentsev13-82/+149
Added format attribute to several gprofng functions. Fixed -Wformat= warnings. gprofng/ChangeLog 2023-10-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * libcollector/heaptrace.c: Fixed -Wformat= warnings. * libcollector/hwprofile.c: Likewise. * libcollector/iolib.c: Likewise. * libcollector/iotrace.c: Likewise. * libcollector/jprofile.c: Likewise. * libcollector/profile.c: Likewise. * libcollector/synctrace.c: Likewise. * src/ClassFile.cc: Likewise. * src/SourceFile.cc: Likewise. * libcollector/libcol_util.h: Added format attribute. * src/Emsg.h: Likewise. * src/collector_module.h: Likewise. * src/data_pckts.h: Define fld_sizeof.
2023-10-25asan: _bfd_elf_slurp_version_tables memory leakAlan Modra1-2/+3
Extends commit 6136093c0d00 to handle verdefs as well as verrefs. PR 30886 * elf.c (_bfd_elf_slurp_version_tables): See free_contents for verdefs too. Use free_contents rather than elf_tdata fields.
generated by cgit v1.1 at 2024-11-26 10:55:11 +0000