aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
9 daysAutomatic date update in version.inHEADmasterGDB Administrator1-1/+1
10 daysor1k: Fix disassembly for little-endian binariesStafford Horne2-2/+2
There are some OpenRISC CPUs that have their binaries stored in little-endian format. Using objdump to disassemble these is problematic, as some instructions fail to disassemble, for example: objdump -D -b binary -EB -m or1k test_be.bin 0: 18 60 07 27 l.movhi r3,0x727 4: a8 63 0e 00 l.ori r3,r3,0xe00 8: 9c 63 ff ff l.addi r3,r3,-1 c: bc 43 00 00 l.sfgtui r3,0 10: 13 ff ff fe l.bf 0x8 14: 44 00 48 00 l.jr r9 objdump -D -b binary -EL -m or1k test_le.bin 0: 27 07 60 18 *unknown* 4: 00 0e 63 a8 l.ori r3,r3,0xe00 8: ff ff 63 9c *unknown* c: 00 00 43 bc l.sfgtui r3,0 10: fe ff ff 13 *unknown* 14: 00 48 00 44 l.jr r9 It was found that the hash function was using the still little-endian buffer to extract the opcode used for the hash lookup. This didn't work as it was pulling the wrong hashcode causing instruction lookup to fail. Fix the hash function by using the normalized/byte-swapped value instead of the buffer. Signed-off-by: Stafford Horne <shorne@gmail.com>
10 daysAutomatic date update in version.inGDB Administrator1-1/+1
10 daysgdbsupport: Use xsnprintf() instead of strcat() in print-utilsAleksandar Rikalo1-4/+2
Theoretically, in functions core_addr_to_string_nz() and core_addr_to_string(), strcat() can overflow, so use a safe approach using xsnprintf(). Change-Id: Ib9437450b3634dc35077234f462a03a8640242d4
10 daysgdb: Remove redundant null checkAleksandar Rikalo1-8/+2
This patch simplifies the code at two points by removing redundant null checks. There is no functional impact. Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Pedro Alves <pedro@palves.net> Change-Id: I76e1c7fad00e8fcb24ced7bfd75d19cdd6266c32
11 daysaarch64: Support 2024 Debug Architecture system registers.Srinath Parvathaneni10-0/+157
This patch adds support for following system registers and the spec can be found here[1]. 1. PMBSR_EL12, PMBSR_EL2, PMBSR_EL3, PMBMAR_EL1 depends on FEAT_SPE and Armv9.5-A architecture and these are enabled by passing -march=armv9.5-a+profile. 2. TRBSR_EL12, TRBSR_EL2, and TRBSR_EL3 depends Armv9.5-A architecture and these are enabled by passing -march=armv9.5-a. 3. HFGITR2_EL2 depends on Armv8.8-A architecture and enabled by passing -march=armv8.8-a. [1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Registers?lang=en
11 daysgdbserver: Update require_int function to parse offset for pread packetKirill Radkin3-4/+91
Currently gdbserver uses the require_int() function to parse the requested offset (in vFile::pread packet and the like). This function allows integers up to 0x7fffffff (to fit in 32-bit int), however the offset (for the pread system call) has an off_t type which can be larger than 32-bit. This patch allows require_int() function to parse offset up to the maximum value implied by the off_t type. Approved-By: Pedro Alves <pedro@palves.net> Change-Id: I3691bcc1ab1838c0db7f8b82d297d276a5419c8c
11 daysAutomatic date update in version.inGDB Administrator1-1/+1
11 daysgdb/testsuite: run isort on gdb.server/fileio-packets.pySimon Marchi1-1/+2
`pre-commit run --all-files` found this. Change-Id: I8db09b12cf184d32351ff2c579bdaa8cf6f80ac3
11 daysgdb/dwarf: change CUs -> units in print_statsSimon Marchi2-4/+4
Change the messages to reflect that these numbers includes type units, not only compile units. Change-Id: Id2f511d4666e5cf92112be917d72ff76791b7e1d Approved-by: Kevin Buettner <kevinb@redhat.com>
12 daysaarch64: Support for FEAT_LSFEEzra Sitorus13-582/+2025
FEAT_LSFE - Large System Float Extension - implements A64 base atomic floating-point in-memory instructions.
12 daysaarch64: Support for FEAT_SVE_F16F32MM, FEAT_F8F16M, FEAT_F8F32MMEzra Sitorus26-537/+841
FEAT_SVE_F16F32MM introduces the SVE half-precision floating-point matrix multiply-accumulate to single-precision instruction. FEAT_F8F32MM introduces the Advanced SIMD 8-bit floating-point matrix multiply-accumulate to single-precision instruction. FEAT_F8F16MM introduces the Advanced SIMD 8-bit floating-point matrix multiply-accumulate to half-precision instruction.
12 daysaarch64: Support for FEAT_CMPBREzra Sitorus24-3931/+6176
FEAT_CMPBR - Compare and branch instructions. This patch adds these instructions: - CB<CC> (register) - CB<CC> (immediate) - CBH<CC> - CBB<CC> where CC is one of the following: - EQ - NE - GT - GE - LT - LE - HI - HS - LO - LS
12 daysaarch64: Add occmo flag for FEAT_OCCMOEzra Sitorus8-18/+31
FEAT_OCCMO support was introduced, but the feature flags were missing. This patch adds these flags, as well as splitting up the tests to test occmo vs occmo+memtag operands.
12 daysaarch64: Support for FEAT_SVE_BFSCALEEzra Sitorus18-727/+1072
FEAT_SVE_BFSCALE introduces the SVE BFSCALE instruction, when the PE is not in Streaming SVE mode. If FEAT_SME2 is implemented, FEAT_SVE_BFSCALE also introduces SME multi-vector Z-targeting BFloat16 scaling instructions, BFSCALE and BFMUL.
12 daysgdb/python: introduce gdb.warning() functionAndrew Burgess5-0/+101
This commit adds a new gdb.warning() function. This function takes a string and then calls GDB's internal warning() function. This will display the string as a warning. Using gdb.warning() means that the message will get the new emoji prefix if the user has that feature turned on. Also, the message will be sent to gdb.STDERR without the user having to remember to print to the correct stream. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
12 daysAutomatic date update in version.inGDB Administrator1-1/+1
13 daysLoongArch: Batch-delete bytes at the end of each relax tripWANG Xuerui1-52/+298
Previously, memmove and reloc/symbol adjustments happened at each loongarch_relax_delete_bytes() call, which is O(n^2) time complexity and leads to unacceptable (multiple hours) linking times for certain inputs with huge number of relaxable sites -- see the linked issue for details. To get rid of the quadratic behavior, defer all delete ops to the end of each relax trip, with the buffer implemented with the splay tree from libiberty. The individual relaxation handlers are converted to handle symbol values and relocation offsets as if all preceding deletions actually happened, by querying a cumulative offset from the splay tree; the accesses should be efficient because they are mostly sequential during a relaxation trip. The exact relaxation behavior remains largely unchanged. Example running times before and after the change with the test case in the linked issue (mypy transpiled C), cross-linking on Threadripper 3990X: Before: 4192.80s user 1.09s system 98% cpu 1:10:53.52 total After: 1.76s user 0.74s system 98% cpu 2.539 total - ~1/2382 the time! Also tested with binutils (bootstrapping self), CPython 3.14 and LLVM 20.1.6; all passed the respective test suites. Link: https://github.com/loongson-community/discussions/issues/56 Signed-off-by: WANG Xuerui <git@xen0n.name>
13 daysAutomatic date update in version.inGDB Administrator1-1/+1
13 daysgdb: query inferior's filesystem for build-id debug filesFabian Kilger1-2/+4
This fixes a bug related to build-id files with linux namespaces. Specifically, we expect the debug files to be present inside the container, thus the container filesystem should be queried if the program is running inside one. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32956 Approved-By: Andrew Burgess <aburgess@redhat.com>
13 daysgdb: implement linux namespace support for fileio_lstat and vFile::lstatFabian Kilger9-2/+119
The new algorithm to look for a build-id-based debug file (introduced by commit 22836ca88591ac7efacf06d5b6db191763fd8aba) makes use of fileio_lstat. As lstat was not supported by linux-namespace.c, all lstat calls would be performed on the host and not inside the namespace. Fixed by adding namespace lstat support. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32956 Approved-By: Andrew Burgess <aburgess@redhat.com>
13 daysgdbserver: fix vFile:stat to actually use 'stat'Andrew Burgess5-8/+61
This commit continues the work of the previous two commits. In the following commits I added the target_fileio_stat function, and the target_ops::fileio_stat member function: * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet * 22836ca8859 gdb: check for multiple matching build-id files Unfortunately I messed up, despite being called 'stat' these function actually performed an 'lstat'. The 'lstat' is the correct (required) implementation, it's the naming that is wrong. Additionally, to support remote targets, these commit added the vFile::stat packet, which again, performed an 'lstat'. In the previous two commits I changed the GDB code to replace 'stat' with 'lstat' in the fileio function names. I then added a new vFile:lstat packet which GDB now uses instead of vFile:stat. And that just leaves the vFile:stat packet which is, right now, performing an 'lstat'. Now, clearly when I wrote this code I fully intended for this packet to perform an lstat, it's the lstat that I needed. But now, I think, we should "fix" vFile:stat to actually perform a 'stat'. This is risky. This is a change in remote protocol behaviour. Reasons why this might be OK: - vFile:stat was only added in GDB 16, so it's not been "in the wild" for too long yet. If we're quick, we might be able to "fix" this before anyone realises I messed up. - The documentation for vFile:stat is pretty vague. It certainly doesn't explicitly say "this does an lstat". Most implementers would (I think), given the name, start by assuming this should be a 'stat' (given the name). Only if they ran the full GDB testsuite, or examined GDB's implementation, would they know to use lstat. Reasons why this might not be OK: - Some other debug client could be connecting to gdbserver, sending vFile:stat and expecting to get lstat behaviour. This would break after this patch. - Some other remote server might have implemented vFile:stat support, and either figured out, or copied, the lstat behaviour from gdbserver. This remote server would technically be wrong after this commit, but as GDB no longer uses vFile:stat, then this will only become a problem if/when GDB or some other client starts to use vFile:stat in the future. Given the vague documentation for vFile:stat, and that it was only added in GDB 16, I think we should fix it now to perform a 'stat', and that is what this commit does. The change in behaviour is documented in the NEWS file. I've improved the vFile:stat documentation in the manual to better explain what is expected from this packet, and I've extended the existing test to cover vFile:stat. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
13 daysgdbserver: add vFile:lstat packet supportAndrew Burgess7-5/+296
In the following commits I added the target_fileio_stat function, and the target_ops::fileio_stat member function: * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet * 22836ca8859 gdb: check for multiple matching build-id files Unfortunately I messed up, despite being called 'stat' these function actually performed an 'lstat'. The 'lstat' is the correct (required) implementation, it's the naming that is wrong. In the previous commit I fixed the naming within GDB, renaming 'stat' to 'lstat' throughout. However, in order to support target_fileio_stat (as was) on remote targets, the above patches added the vFile:stat packet, which actually performed an 'lstat' call. This is really quite unfortunate, and I'd like to do as much as I can to try and clean up this mess. But I'm mindful that changing packets is not really the done thing. So, this commit doesn't change anything. Instead, this commit adds vFile:lstat as a new packet. Currently, this packet is handled identically as vFile:stat, the packet performs an 'lstat' call. I then update GDB to send the new vFile:lstat instead of vFile:stat for the remote_target::fileio_lstat implementation. After this commit GDB will never send the vFile:stat packet. However, I have retained the 'set remote hostio-stat-packet' control flag, just in case someone was trying to set this somewhere. Then there's one test in the testsuite which used to disable the vFile:stat packet, that test is updated to now disable vFile:lstat. There's a new test that does a more direct test of vFile:lstat. This new test can be extended to also test vFile:stat, but that is left for the next commit. And so, after this commit, GDB sends the new vFile:lstat packet in order to implement target_ops::fileio_lstat. The new packet is more clearly documented than vFile:stat is. But critically, this change doesn't risk breaking any other clients or servers that implement GDB's remote protocol. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
13 daysgdb: rename target_fileio_stat to target_fileio_lstatAndrew Burgess6-31/+31
In the following commits I added the target_fileio_stat function, and the target_ops::fileio_stat member function: * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet * 22836ca8859 gdb: check for multiple matching build-id files Unfortunately, I messed up when adding this API. The actual underlying call is lstat, not stat. This commit tries to clear up some of the confusion by renaming things to target_fileio_lstat and target_ops::fileio_lstat. After this change the function names now match the underlying implementation. One problem remains though. In order to support target_fileio_stat for remote target the above patches added the vFile:stat packet to GDB and gdbserver. The implementation of this packet still does an lstat though, which is a bit of a shame. I'm going to try and fix that in later commits. This commit is just a rename within GDB, there should be no user visible changes. Approved-By: Tom Tromey <tom@tromey.com>
13 daysgdb/dwarf: rename get_cu -> get_unitSimon Marchi4-15/+15
This method returns type units too, so "get_unit" is a better name. Change-Id: I6ec9de3f783637a3e206bcaaec96a4e00b4b7d31 Approved-By: Tom Tromey <tom@tromey.com>
13 daysgdb/dap: allow more requests when the process is runningoltolm1-3/+3
Makes it possible to set and remove other types of breakpoints while the process is running. Makes debugging more convenient. Approved-By: Tom Tromey <tom@tromey.com>
14 daysgdb/record: Support csrrci instruction in risc-vTimur1-1/+1
During testing csr instructions in risc-v, it occurs that instruction csrrci is unsupported for recording process and there is such warning: 'warning: Currently this instruction with len 4(100174f3) is unsupported', so recording failed. This patch fixes this error.
14 daysgdb: add Timur Golubovich to gdb/MAINTAINERStimurgol0071-0/+1
14 days[gdb/testsuite] Set interactive-mode to onTom de Vries1-0/+3
With MSYS2 and test-case gdb.ada/assign_1.exp, we get: ... (gdb) dir^M Reinitialize source path to empty? (y or n) \ [answered Y; input not from terminal]^M^M Source directories searched: $cdir;$cwd^M^M (gdb) ... GDB automatically answers the query, because interactive-mode is off: ... (gdb) show interactive-mode^M Debugger's interactive mode is auto (currently off).^M^M ... The correct value is on, because GDB was started in a terminal. For some reason, the auto value of interactive-mode is off instead. According to this patch [1], gdb doesn't recognize the pipes used by DejaGnu testsuite as an interactive setup. Fix this by adding "set interactive-mode on" to INTERNAL_GDBFLAGS, such that we get: ... (gdb) dir^M Reinitialize source path to empty? (y or n) y^M Source directories searched: $cdir;$cwd^M^M (gdb) ... and no longer need fixes like commit be740e7cc62 ("testsuite: skip confirmation in 'gdb_reinitialize_dir'") The fix is essentially the same as in aforementioned patch. For consistency, we apply the fix for all platforms. Co-Authored-By: Pierre Muller <muller@sourceware.org> Approved-By: Tom Tromey <tom@tromey.com> [1] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
14 days[gdb/testsuite] Set TERM to dumb by defaultTom de Vries1-0/+27
With MSYS2 and default TERM=xterm-256color (as well as with xterm and ansi), I get: ... builtin_spawn gdb -q ... ^[[6n(gdb) ERROR: GDB never initialized. ... This is not specific to gdb, other tools produce the same CSI sequence, and consequently we run into trouble in other places (like get_compiler_info). Fix this by default-setting TERM to dumb. We do this for all platforms, to avoid test-cases passing on one platform but failing on another. For test-cases that set TERM to something other than dumb, handle the CSI sequence in default_gdb_start. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/33072 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33072
2025-06-17Automatic date update in version.inGDB Administrator1-1/+1
2025-06-16bfd: fix a minor typoIndu Bhagat1-1/+1
2025-06-16gdb/doc: Explain linker namespacesGuinevere Larsen1-8/+15
Recent GDB commits added more features related to linker namespaces and documented them on the manual, but did not add a convenient way for a user to understand what they are. This commit adds a quick explanation of what they are. It also fixes the inconsistency of using "linker namespaces" and "linkage namespaces", by always using the first form to avoid user confusion. Approved-By: Eli Zaretskii <eliz@gnu.org>
2025-06-16gdb/doc: remove stray comma from gdb.flush descriptionAndrew Burgess1-1/+1
Remove comma from: gdb.flush([, stream]) . I suspect this was a copy and paste from gdb.write(string [, stream]) where the comma is correct.
2025-06-16gdb/amd-dbgapi: disable forward progress requirement in ↵Simon Marchi3-0/+160
amd_dbgapi_target_breakpoint::check_status ROCgdb handles target events very slowly when running a test case like this, where a breakpoint is preset on HipTest::vectorADD: for (int i=0; i < numDevices; ++i) { HIPCHECK(hipSetDevice(i)); hipLaunchKernelGGL(HipTest::vectorADD, dim3(blocks), dim3(threadsPerBlock), 0, stream[i], static_cast<const int*>(A_d[i]), static_cast<const int*>(B_d[i]), C_d[i], N); } What happens is: - A kernel is launched - The internal runtime breakpoint is hit during the second hipLaunchKernelGGL call, which causes amd_dbgapi_target_breakpoint::check_status to be called - Meanwhile, all waves of the kernel hit the breakpoint on vectorADD - amd_dbgapi_target_breakpoint::check_status calls process_event_queue, which pulls the thousand of breakpoint hit events from the kernel - As part of handling the breakpoint hit events, we write the PC of the waves that stopped to decrement it. Because the forward progress requirement is not disabled, this causes a suspend/resume of the queue each time, which is time-consuming. The stack trace where this all happens is: #32 0x00007ffff6b9abda in amd_dbgapi_write_register (wave_id=..., register_id=..., offset=0, value_size=8, value=0x7fffea9fdcc0) at /home/smarchi/src/amd-dbgapi/src/register.cpp:587 #33 0x00005555588c0bed in amd_dbgapi_target::store_registers (this=0x55555c7b1d20 <the_amd_dbgapi_target>, regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2504 #34 0x000055555a5186a1 in target_store_registers (regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/target.c:3973 #35 0x0000555559fab831 in regcache::raw_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:890 #36 0x0000555559fabd2b in regcache::cooked_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:915 #37 0x0000555559fc3ca5 in regcache::cooked_write<unsigned long, void> (this=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:850 #38 0x0000555559fab09a in regcache_cooked_write_unsigned (regcache=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:858 #39 0x0000555559fb0678 in regcache_write_pc (regcache=0x507000002240, pc=0x7ffff62bd900) at /home/smarchi/src/wt/amd/gdb/regcache.c:1460 #40 0x00005555588bb37d in process_one_event (event_id=..., event_kind=AMD_DBGAPI_EVENT_KIND_WAVE_STOP) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1873 #41 0x00005555588bbf7b in process_event_queue (process_id=..., until_event_kind=AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2006 #42 0x00005555588b1aca in amd_dbgapi_target_breakpoint::check_status (this=0x511000140900, bs=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:890 #43 0x0000555558c50080 in bpstat_stop_status (aspace=0x5070000061b0, bp_addr=0x7fffed0b9ab0, thread=0x518000026c80, ws=..., stop_chain=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/breakpoint.c:6126 #44 0x000055555984f4ff in handle_signal_stop (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:7169 #45 0x000055555984b889 in handle_inferior_event (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:6621 #46 0x000055555983eab6 in fetch_inferior_event () at /home/smarchi/src/wt/amd/gdb/infrun.c:4750 #47 0x00005555597caa5f in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/wt/amd/gdb/inf-loop.c:42 #48 0x00005555588b838e in handle_target_event (client_data=0x0) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1513 Fix that performance problem by disabling the forward progress requirement in amd_dbgapi_target_breakpoint::check_status, before calling process_event_queue, so that we can process all events efficiently. Since the same performance problem could theoritically happen any time process_event_queue is called with forward progress requirement enabled, add an assert to ensure that forward progress requirement is disabled when process_event_queue is invoked. This makes it necessary to add a require_forward_progress call to amd_dbgapi_finalize_core_attach. It looks a bit strange, since core files don't have execution, but it doesn't hurt. Add a test that replicates this scenario. The test launches a kernel that hits a breakpoint (with an always false condition) repeatedly. Meanwhile, the host process loads an unloads a code object, causing check_status to be called. Bug: SWDEV-482511 Change-Id: Ida86340d679e6bd8462712953458c07ba3fd49ec Approved-by: Lancelot Six <lancelot.six@amd.com>
2025-06-16gdb/amd-dbgapi: factor out require_forward_progress overload to target one ↵Simon Marchi1-20/+27
inferior A following patch will want to call require_forward_progress for a given inferior. Extract a new require_forward_progress overload from the existing require_forward_progress function that targets a specific inferior. Change-Id: I54f42b83eb8443d4d91747ffbc86eaeb017f1e49 Approved-by: Lancelot Six <lancelot.six@amd.com>
2025-06-16gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_one_eventSimon Marchi1-36/+19
Pass the amd_dbgapi_inferior_info object from process_event_queue to process_one_event. Since process_event_queue pulls events for one specific inferior, we know for which inferior the event is. This removes the need for process_one_event to do two dbgapi calls to get the relevant pid. If also removes one inferior lookup. Change-Id: I22927e4b6251513eb3be95785082058aa3d09954 Approved-by: Lancelot Six <lancelot.six@amd.com>
2025-06-16gdb/amd-dbgapi: pass amd_dbgapi_inferior_info to process_event_queueSimon Marchi1-16/+9
A following patch will make process_event_queue access a field of amd_dbgapi_inferior_info. Prepare for this by making process_event_queue accept an amd_dbgapi_inferior_info object, instead of a process id. Change-Id: I9adc491dd1ff64ff74c40aa7662fffb11bd8332b Approved-by: Lancelot Six <lancelot.six@amd.com>
2025-06-16gdb/amd-dbgapi: add assert in require_forward_progressSimon Marchi1-0/+6
I didn't have a problem in this area, but it seems to me that this pre-condition should always hold. We should only disable forward progress requirement if the target says it's ok to do so. Otherwise, we could get in a situation where we wait for events from amd-dbgapi, which will never arrive, because amd-dbgapi didn't actually resume things. Change-Id: Ifc49f55c7874924b7c47888b8391a07a01d960fc Approved-by: Lancelot Six <lancelot.six@amd.com>
2025-06-16gdb/amd-dbgapi: remove unnecessary AMD_DBGAPI_EVENT_KIND_NONE argumentSimon Marchi1-1/+1
Rely on the default value. Change-Id: I08c683de005806c5c5d29ed7f9b0c6de81b49a01 Approved-By: Lancelot Six <lancelot.six@amd.com>
2025-06-16[gdb/testsuite] Fix gdb.python/py-source-styling-2.exp with TERM=dumbTom de Vries1-12/+12
When running test-case gdb.python/py-source-styling-2.exp with TERM=dumb, I get: ... (gdb) set style enabled on^M warning: The current terminal doesn't support styling. \ Styled output might not appear as expected.^M (gdb) FAIL: $exp: set style enabled on ... Fix this by using with_ansi_styling_terminal on clean_restart. Tested on x86_64-linux.
2025-06-16Automatic date update in version.inGDB Administrator1-1/+1
2025-06-15Automatic date update in version.inGDB Administrator1-1/+1
2025-06-15objcopy: Correctly check archive element for LTO IRH.J. Lu2-1/+82
commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d Author: H.J. Lu <hjl.tools@gmail.com> Date: Sun May 4 05:12:46 2025 +0800 strip: Add GCC LTO IR support added: @@ -3744,6 +3768,12 @@ copy_archive (bfd *ibfd, bfd *obfd, const char *output_target, goto cleanup_and_exit; } +#if BFD_SUPPORTS_PLUGINS + /* Copy LTO IR file as unknown object. */ + if (bfd_plugin_target_p (ibfd->xvec)) ^^^^ A typo, should be this_element. + ok_object = false; + else +#endif if (ok_object) { ok = copy_object (this_element, output_element, input_arch); to check if the archive element is a LTO IR file. "ibfd" is the archive BFD. "this_element" should be used to check for LTO IR in the archive element. Fix it by replacing "ibfd" with "this_element". PR binutils/33078 * objcopy.c (copy_archive): Correctly check archive element for LTO IR. * testsuite/binutils-all/objcopy.exp (strip_test_archive): New. Run strip_test_archive. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-06-14* gdb/doc/gdb.texinfo (Emacs): Refer to Emacs manualJeremy Bryant1-130/+5
The manual section on using GDB under Emacs is out-of-date and duplicates existing and comprehensive documentation in the Emacs manual. Replace the section by a short introduction and reference. Approved-By: Eli Zaretskii <eliz@gnu.org>
2025-06-14or1k: Add support for numcores and coreid sprsStafford Horne7-273/+330
These are needed when running GCC tests for newlib toolchains built with multicore support. Without these SPRs we get the following warnings when running tests. spawn or1k-elf-run ./20000112-1.exe^M WARNING: l.mfspr with invalid SPR address 0x80^M WARNING: l.mfspr with invalid SPR address 0x81^M WARNING: l.mfspr with invalid SPR address 0x81^M WARNING: l.mfspr with invalid SPR address 0x81^M Support is added by defining the SPRs in the cgen machine definition and regenerating the machine code. In or1k/or1k.c we initialize NUMCORES to 1 and COREID to 0 as the sim has only one CPU. In or1k/traps.c we allow returning the NUMCORES and COREID spr values in the mfspr function. Signed-off-by: Stafford Horne <shorne@gmail.com>
2025-06-14Automatic date update in version.inGDB Administrator1-1/+1
2025-06-13gdbsupport: make gdb::parallel_for_each's n parameter a template parameterSimon Marchi3-9/+7
This value will likely never change at runtime, so we might as well make it a template parameter. This has the "advantage" of being able to remove the unnecessary param from gdb::sequential_for_each. Change-Id: Ia172ab8e08964e30d4e3378a95ccfa782abce674 Approved-By: Tom Tromey <tom@tromey.com>
2025-06-13gdb: re-work parallel-for-selftests.cSimon Marchi1-81/+56
I find this file difficult to work with and modify, due to how it uses the preprocessor to include itself, to generate variations of the test functions. Change it to something a bit more C++-y, with a test function that accepts a callback to invoke the foreach function under test. Change-Id: Ibf1e2907380a88a4f8e4b4b88df2b0dfd0e9b6c8
2025-06-13gdb/dwarf: make cooked_index_flag's to_string handle IS_SYNTHESIZEDSimon Marchi1-0/+1
Change-Id: Iaac252aa2abbe169153e79b84f956cda172c69d1
generated by cgit v1.1 at 2025-07-01 05:01:20 +0000