aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2023-09-20Remove explanatory comments from includesTom Tromey89-127/+124
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-09-20gdb/dap: only include sourceReference if file path does not existGregory Anders2-9/+16
According to the DAP specification if the "sourceReference" field is included in a Source object, then the DAP client _must_ make a "source" request to the debugger to retrieve file contents, even if the Source object also includes path information. If the Source's path field is a valid path that the DAP client is able to read from the filesystem, having to make another request to the debugger to get the file contents is wasteful and leads to incorrect results (DAP clients will try to get the contents from the server and display those contents as a file with the name in "source.path", but this will conflict with the _acutal_ existing file at "source.path"). Instead, only set "sourceReference" if the source file path does not exist. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20gdb/dap: use breakpoint fullname to resolve sourceGregory Anders1-3/+3
If the breakpoint has a fullname, use that as the source path when resolving the breakpoint source information. This is consistent with other callers of make_source which also use "fullname" if it exists (see e.g. DAPFrameDecorator which returns the symtab's fullname). Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20gdb/dap: ignore unused keyword args in step_outGregory Anders2-1/+8
Some DAP clients may send additional parameters in the stepOut command (e.g. "granularity") which are not used by GDB, but should nonetheless be accepted without error. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20gdb/dap: check for breakpoint source before unpackingGregory Anders2-8/+19
Not all breakpoints have a source location. For example, a breakpoint set on a raw address will have only the "address" field populated, but "source" will be None, which leads to a RuntimeError when attempting to unpack the filename and line number. Before attempting to unpack the filename and line number from the breakpoint, ensure that the source information is not None. Also populate the source and line information separately from the "instructionReference" field, so that breakpoints that include only an address are still included. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20Run 'black' on printing.pyTom Tromey1-1/+5
The buildbot pointed out that I neglected to re-run 'black' after making some changes. This patch fixes the oversight.
2023-09-20gdb/tui: add 'set tui mouse-events off' to restore mouse selectionMatthew "strager" Glazar6-2/+52
Rationale: I use the mouse with my terminal to select and copy text. In gdb, I use the mouse to select a function name to set a breakpoint, or a variable name to print, for example. When gdb is compiled with ncurses mouse support, gdb's TUI mode intercepts mouse events. Left-clicking and dragging, which would normally select text, seems to do nothing. This means I cannot select text using my mouse anymore. This makes it harder to set breakpoints, print variables, etc. Solution: I tried to fix this issue by editing the 'mousemask' call to only enable buttons 4 and 5. However, this still caused my terminal (gnome-terminal) to not allow text to be selected. The only way I could make it work is by calling 'mousemask (0, NULL);'. But doing so disables the mouse code entirely, which other people might want. I therefore decided to make a setting in gdb called 'tui mouse-events'. If enabled (the default), the behavior is as it is now: terminal mouse events are given to gdb, disabling the terminal's default behavior. If disabled (opt-in), the behavior is as it was before the year 2020: terminal mouse events are not given to gdb, therefore the mouse can be used to select and copy text. Notes: I am not attached to the setting name or its description. Feel free to suggest better wording. Testing: I tested this change in gnome-terminal by performing the following steps manually: 1. Run: gdb --args ./myprogram 2. Enable TUI: press ctrl-x ctrl-a 3. Click and drag text with the mouse. Observe no selection. 4. Input: set tui mouse-events off 5. Click and drag text with the mouse. Observe that selection works now. 6. Input: set tui mouse-events on. 7. Click and drag text with the mouse. Observe no selection.
2023-09-20[gdb/symtab] Error out for .debug_types section in dwz fileTom de Vries5-0/+143
There are two methods to factor out type information in a dwarf4 executable: - use -fdebug-info-types to generate type units in a .debug_types section, and - use dwz to create partial units. The dwz method has an extra benefit: it also allows to factor out information between executables into a newly created .dwz file, pointed to by a .gnu_debugaltlink section. There is nothing prohibiting a .gnu_debugaltlink file to contain a .debug_types section. It's just not generated by dwz or any other tool atm, and consequently gdb has no support for it. Enhancement PR symtab/30838 is open about the lack of support. Make the current situation explicit by emitting a dwarf error: ... (gdb) file struct-with-sig-2^M Reading symbols from struct-with-sig-2...^M Dwarf Error: .debug_types section not supported in dwz file^M ... and add an assert in write_gdbindex: ... + /* See enhancement PR symtab/30838. */ + gdb_assert (!(per_cu->is_dwz && per_cu->is_debug_types)); ... to clarify why we can use: ... data_buf &cu_list = (per_cu->is_debug_types ? types_cu_list : per_cu->is_dwz ? dwz_cu_list : objfile_cu_list); ... The test-case is a modified copy from gdb.dwarf2/struct-with-sig.exp, so it keeps the copyright years range. Tested on x86_64-linux. Tested-By: Guinevere Larsen <blarsen@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30838
2023-09-19Handle pointers and references correctly in DAPTom Tromey3-0/+153
A user pointed out that the current DAP variable code does not let the client deference a pointer. Oops! Fixing this oversight is simple enough -- adding a new no-op pretty-printer for pointers and references is quite simple. However, doing this naive caused a regession in scopes.exp, which expected there to be no children of a 'const char *' variable. This problem was fixed by the preceding patches in the series, which ensure that a C type of this kind is recognized as a string. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30821
2023-09-19Give a language to a typeTom Tromey9-94/+98
This changes main_type to hold a language, and updates the debug readers to set this field. This is done by adding the language to the type-allocator object. Note that the non-DWARF readers are changed on a "best effort" basis. This patch also reimplements type::is_array_like to use the type's language, and it adds a new type::is_string_like as well. This in turn lets us change the Python implementation of these methods to simply defer to the type.
2023-09-19Add is_array_like and to_array to language_defnTom Tromey3-0/+34
This adds new is_array_like and to_array methods to language_defn. This will be used in a subsequent patch that generalizes the new Python array- and string-handling code.
2023-09-19Regularize some DWARF type initializationTom Tromey1-11/+13
In one spot, it will be convenient for a subsequent patch if the CU is passed to a type-creation helper function. In another spot, remove the redundant 'objfile' parameter to another such function.
2023-09-19Pass a type allocator to init_fixed_point_typeTom Tromey3-5/+5
init_fixed_point_type currently takes an objfile and creates its own type allocator. However, for a later patch it is more convenient if this function accepts a type allocator. This patch makes this change.
2023-09-19Use gdb::checked_static_cast for catchpointsTom Tromey3-7/+9
This replaces some casts to various kinds of catchpoint with checked_static_cast. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-19Use gdb::checked_static_cast for code_breakpointTom Tromey2-3/+5
This replaces some casts to 'code_breakpoint *' with checked_static_cast. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-19Use gdb::checked_static_cast for tracepointsTom Tromey10-50/+61
This replaces some casts to 'tracepoint *' with checked_static_cast. Some functions are changed to accept a 'tracepoint *' now, for better type safety. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-19Use gdb::checked_static_cast for watchpointsTom Tromey3-156/+149
This replaces some casts to 'watchpoint *' with checked_static_cast. In one spot, an unnecessary block is also removed. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-19gdb, breakpoint: add a destructor to the watchpoint structMohamed Bouhaouel4-0/+83
Make sure to unlink the related breakpoint when the watchpoint instance is deleted. This prevents having a wp-related breakpoint that is linked to a NULL watchpoint (e.g. the watchpoint instance is being deleted when the 'watch' command fails). With the below scenario, having such a left out breakpoint will lead to a GDB hang, and this is due to an infinite loop when deleting all inferior breakpoints. Scenario: (gdb) set can-use-hw-watchpoints 0 (gdb) awatch <SCOPE VAR> Can't set read/access watchpoint when hardware watchpoints are disabled. (gdb) rwatch <SCOPE VAR> Can't set read/access watchpoint when hardware watchpoints are disabled. (gdb) <continue the program until the end> >> HANG << Signed-off-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> Reviewed-by: Bruno Larsen <blarsen@redhat.com>
2023-09-19gdb/cli: fixes to newly added "list ." commandGuinevere Larsen4-25/+28
After the series that added this command was pushed, Pedro mentioned that the news description could easily be misinterpreted, as well as some code and test improvements that should be made. While fixing the test, I realized that code repetition wasn't happening as it should, so I took care of that too. Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-09-18More type safety for symbol_searchTom Tromey1-5/+5
This patch changes class symbol_search to store a block_enum rather than an int. Regression tested on x86-64 Fedora 38. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-18Move val_prettyformat to valprint.hTom Tromey2-14/+11
I stumbled across an ancient FIXME comment that was easy to fix -- val_prettyformat does not need to be in defs.h, and is easily moved to valprint.h, where (despite what the comment says) it belongs. Tested by rebuilding.
2023-09-17gdb: remove unused free_actions declarationSimon Marchi1-2/+0
This appears to be a leftover from a past change. Change-Id: I8e747edbf291400e4f417f5c6875049479a1669a
2023-09-16[gdb/symtab] Fix overly large gdb-index file check for 32-bitTom de Vries1-2/+82
Add a unit test which checks that write_gdb_index_1 will throw an error when the size of the file would exceed the maximum value capable of being represented by 'offset_type'. The unit test fails on 32-bit systems due to wrapping overflow. Fix this by changing the type of total_len in write_gdbindex_1 from size_t to uint64_t. Tested on x86_64-linux. Co-Authored-By: Kevin Buettner <kevinb@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
2023-09-15gdb: remove -Werror annotations from MAINTAINERS fileSimon Marchi1-38/+37
I don't think these are useful nowadays, since we now expect all code to be -Werror clean (it's the default in development branches). Change-Id: I8c3b86c70d683bd41344d27add0ac2627a474d20 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-15gdb/amdgpu: add precise-memory supportSimon Marchi12-8/+683
The amd-dbgapi library exposes a setting called "memory precision" for AMD GPUs [1]. Here's a copy of the description of the setting: The AMD GPU can overlap the execution of memory instructions with other instructions. This can result in a wave stopping due to a memory violation or hardware data watchpoint hit with a program counter beyond the instruction that caused the wave to stop. Some architectures allow the hardware to be configured to always wait for memory operations to complete before continuing. This will result in the wave stopping at the instruction immediately after the one that caused the stop event. Enabling this mode can make execution of waves significantly slower. Expose this option through a new "amdgpu precise-memory" setting. The precise memory setting is per inferior. The setting is transferred from one inferior to another when using the clone-inferior command, or when a new inferior is created following an exec or a fork. It can be set before starting the inferior, in which case GDB will attempt to apply what the user wants when attaching amd-dbgapi. If the user has requested to enable precise memory, but it can't be enabled (not all hardware supports it), GDB prints a warning. If precise memory is disabled, GDB prints a warning when hitting a memory exception (translated into GDB_SIGNAL_SEGV or GDB_SIGNAL_BUS), saying that the stop location may not be precise. Note that the precise memory setting also affects memory watchpoint reporting, but the watchpoint support for AMD GPUs hasn't been upstreamed to GDB yet. When we do upstream watchpoint support, GDB will produce a similar warning message when stopping due to a watchpoint if precise memory is disabled. Add a handful of tests. Add a util proc "hip_devices_support_precise_memory", which indicates if all devices used for testing support that feature. [1] https://github.com/ROCm-Developer-Tools/ROCdbgapi/blob/687374258a27b5aab1309a7e8ded719e2f1ed3b1/include/amd-dbgapi.h.in#L6300-L6317 Change-Id: Ife1a99c0e960513da375ced8f8afaf8e47a61b3f Approved-By: Lancelot Six <lancelot.six@amd.com>
2023-09-15gdb/testsuite: add linux target check in allow_hipcc_testsSimon Marchi1-0/+4
ROCm / HIP tests should only run on Linux for now, existing gdb.rocm tests miss such a check. Add an "istarget linux" check in allow_hipcc_tests. Change-Id: I71f69e510a754f2fdadc32de53b923ebb9835ab5 Approved-By: Lancelot Six <lancelot.six@amd.com>
2023-09-15gdb: add inferior_cloned observableSimon Marchi3-0/+7
The following patch makes the amdgpu port transfer a property from the original inferior to the new inferior when using the clone-inferior command. Add the inferior_cloned observable to help with this. Change-Id: Id845a799813ec49b1b7b2fcb97b07d0a1e5e2631 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-15gdb/amdgpu: Silence wave termination messagesLaurent Morichetti1-1/+1
After commit 9d7d58e7262, the amdgpu target started printing "thread exited" messages when pruning waves that had terminated. ... [AMDGPU Wave ?:?:?:2045 (?,?,?)/? exited] [AMDGPU Wave ?:?:?:2046 (?,?,?)/? exited] [AMDGPU Wave ?:?:?:2047 (?,?,?)/? exited] [AMDGPU Wave ?:?:?:2048 (?,?,?)/? exited] ... The issue was that before commit 9d7d58e7262, delete_thread was silent by default due to a bug that the commit fixed. Replaced the amdgpu target call to delete_thread with a call to delete_thread_silent. Change-Id: Ie5d5a4c5be851f092d2315b2afa6a36a30a05245 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-15gdb: add Lancelot Six as maintainer of the AMD GPU portSimon Marchi1-0/+3
Lancelot has accepted to take the role of maintainer for the AMD GPU port. The AMD GPU port (amdgpu as I've written in the MAINTAINERS file) is an umbrella term for everything needed to make this work: the amdgcn arch, the amd-dbgapi target, solib-rocm, etc. Thanks for accepting the role, and congratulations! Change-Id: I4c898042fda49b45dcb0d54ca94731bb57287f71
2023-09-15Rename split_style::DOTTom Tromey4-5/+6
This renames split_style::DOT, to avoid name clashes when building gdb with an old version of Bison (2.3, the version available on macOS). In particular the error looks like: ./split-name.h:34:3: error: expected identifier DOT, ^ m2-exp.c:163:13: note: expanded from macro 'DOT' Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30286
2023-09-15gdb: small cleanup in symbol_file_add_with_addrsAndrew Burgess1-8/+3
While looking at how gdb::observers::new_objfile was used, I found some code in symbol_file_add_with_addrs that I thought could be improved. Instead of: if (condition) { ... return; } ... return; Where some parts of '...' identical between the two branches. I think it would be nicer if the duplication is removed, and we just use: if (!condition) ... to guard the one statement that should only happen when the condition is not true. There is one change in this commit though that is (possibly) significant, there is a call to bfd_cache_close_all() that was only present in the second block. After this commit we now call that function for both paths. The call to bfd_cache_close_all was added in commit: commit ce7d45220e4ed342d4a77fcd2f312e85e1100971 Date: Fri Jul 30 12:05:45 2004 +0000 with the purpose of ensuring that GDB doesn't hold the BFDs open unnecessarily, thus preventing the files from being updated on some hosts (e.g. Win32). In the early exit case we previously didn't call bfd_cache_close_all, with the result that GDB would continue to hold open some BFD objects longer than needed. After this commit, but calling bfd_cache_close_all for both paths this problem is solved. I'm not sure how this change could be tested, I don't believe there's any GDB (maintenance) command that displays the BFD cache contents, so we can't check the cache contents easily. Ideas are welcome though. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-15gdb: add some missing filename stylingAndrew Burgess2-10/+14
Spotted a few places where we can add filename styling. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-15gdb/testsuite: explicitly test for stderr in gdb.mi/mi-dprintf.expGuinevere Larsen2-3/+22
As mentioned in commit 3f5bbc3e2075ef5061a815c73fdc277218489f22, some compilers such as clang don't add debug information about stderr by default, leaving it to external debug packages. This commit adds a way to check if GDB has access to stderr information when in MI mode, and uses this new mechanism to skip the related section of the test gdb.mi/mi-dprintf.exp. It also fixes an incorrect name for a test in that file. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Kevin Buettner <kevinb@redhat.com>
2023-09-14Throw error when creating an overly large gdb-index fileKevin Buettner1-1/+8
The header in a .gdb_index section uses 32-bit unsigned offsets to refer to other areas of the section. Thus, there is a size limit of 2^32-1 which is currently unaccounted for by GDB's code for outputting these sections. At the moment, when GDB creates an overly large section, it will exit abnormally due to an internal error, which is caused by a failed assert in assert_file_size, which in turn is called from write_gdbindex_1, both of which are in gdb/dwarf2/index-write.c. This is what happens when that assert fails: $ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/" Reading symbols from ./libgraph_tool_inference.so... No executable file now. Discard symbol table from `libgraph_tool_inference.so'? (y or n) n Not confirmed. ../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x55fddb4d78b0 gdb_internal_backtrace_1 ../../gdb/bt-utils.c:122 0x55fddb4d78b0 _Z22gdb_internal_backtracev ../../gdb/bt-utils.c:168 0x55fddb98b5d4 internal_vproblem ../../gdb/utils.c:396 0x55fddb98b8de _Z15internal_verrorPKciS0_P13__va_list_tag ../../gdb/utils.c:476 0x55fddbb71654 _Z18internal_error_locPKciS0_z ../../gdbsupport/errors.cc:58 0x55fddb5a0f23 assert_file_size ../../gdb/dwarf2/index-write.c:1069 0x55fddb5a1ee0 assert_file_size /usr/include/c++/13/bits/stl_iterator.h:1158 0x55fddb5a1ee0 write_gdbindex_1 ../../gdb/dwarf2/index-write.c:1119 0x55fddb5a51be write_gdbindex ../../gdb/dwarf2/index-write.c:1273 [...] --------------------- ../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed. This problem was encountered while building the python-graph-tool package on Fedora. The Fedora bugzilla bug can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1773651 This commit prevents the internal error from occurring by calling error() when the file size exceeds 2^32-1. Using a gdb built with this commit, I now see this behavior instead: $ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/" Reading symbols from ./libgraph_tool_inference.so... No executable file now. Discard symbol table from `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so'? (y or n) n Not confirmed. Error while writing index for `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so': gdb-index maximum file size of 4294967295 exceeded (gdb) I wish I could provide a test case, but due to the sizes of both the input and output files, I think that testing resources would be strained or exceeded in many environments. My testing on Fedora 38 shows no regressions. Approved-by: Tom Tromey <tom@tromey.com>
2023-09-14gdb: fix buffer overflow in DWARF readerAndrew Burgess1-1/+1
In this commit: commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e Date: Fri Nov 19 10:12:44 2021 -0700 Handle multiple addresses in call_site_target a buffer overflow bug was introduced when the following code was added: CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR, addresses.size ()); std::copy (addresses.begin (), addresses.end (), saved); The definition of XOBNEWVAR is (from libiberty.h): #define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S))) So 'saved' is going to point to addresses.size () bytes of memory, however, the std::copy will write addresses.size () number of CORE_ADDR sized entries to the address pointed to by 'saved', this is going to result in memory corruption. The mistake is that we should have used XOBNEWVEC, which allocates a vector of entries, the definition of XOBNEWVEC is: #define XOBNEWVEC(O, T, N) \ ((T *) obstack_alloc ((O), sizeof (T) * (N))) Which means we will have set aside enough space to create a copy of the contents of the addresses vector. I'm not sure how to create a test for this problem, this issue cropped up when debugging a particular i686 built binary, which just happened to trigger a glibc assertion (likely due to random memory corruption), debugging the same binary built for x86-64 appeared to work just fine. Using valgrind on the failing GDB binary pointed straight to the cause of the problem, and with this patch in place there are no longer valgrind errors in this area. If anyone has ideas for a test I'm happy to work on something. Co-Authored-By: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-09-14[gdb/exp] Clean up asap in value_print_array_elementsTom de Vries9-3/+361
I've been running the test-suite on an i686-linux laptop with 1GB of memory, and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb not being able to spawn for a large number of test-cases afterwards. So I investigated the memory usage, on my usual x86_64-linux development platform. The test-case is compiled with -DCRASH_GDB=2097152, so this: ... static int a[CRASH_GDB], b[CRASH_GDB]; ... with sizeof (int) == 4 represents two arrays of 8MB each. Say we add a loop around the "print a" command and print space usage statistics: ... gdb_test "maint set per-command space on" for {set i 0} {$i < 100} {incr i} { gdb_test "print a" } ... This gets us: ... (gdb) print a^M $1 = {0 <repeats 2097152 times>}^M Space used: 478248960 (+469356544 for this command)^M (gdb) print a^M $2 = {0 <repeats 2097152 times>}^M Space used: 486629376 (+8380416 for this command)^M (gdb) print a^M $3 = {0 <repeats 2097152 times>}^M Space used: 495009792 (+8380416 for this command)^M ... (gdb) print a^M $100 = {0 <repeats 2097152 times>}^M Space used: 1308721152 (+8380416 for this command)^M ... In other words, we start out at 8MB, and the first print costs us about 469MB, and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the i686-linux laptop, the first print costs us 335MB. ] The subsequent 8MBs are consistent with the values being saved into the value history, but the usage for the initial print seems somewhat excessive. There is a PR open about needing sparse representation of large arrays (PR8819), but this memory usage points to an independent problem. The function value_print_array_elements contains a scoped_value_mark to free allocated values in the outer loop, but it doesn't prevent the inner loop from allocating a lot of values. Fix this by adding a scoped_value_mark in the inner loop, after which we have: ... (gdb) print a^M $1 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M (gdb) print a^M $2 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M (gdb) print a^M $3 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M ... (gdb) print a^M $100 = {0 <repeats 2097152 times>}^M Space used: 8892416 (+0 for this command)^M ... Note that the +0 here just means that the mallocs did not trigger an sbrk. This is dependent on malloc (which can use either mmap or sbrk or some pre-allocated memory) and will likely vary between different tunings, versions and implementations, so this does not give us a reliable way detect the problem in a minimal way. A more reliable way of detecting the problem is: ... void value_free_to_mark (const struct value *mark) { + size_t before = all_values.size (); auto iter = std::find (all_values.begin (), all_values.end (), mark); if (iter == all_values.end ()) all_values.clear (); else all_values.erase (iter + 1, all_values.end ()); + size_t after = all_values.size (); + if (before - after >= 1024) + fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after); ... which without the fix tells us: ... +print a value_free_to_mark freed 2097152 items $1 = {0 <repeats 2097152 times>} ... Fix a similar problem for Fortran: ... +print array1 value_free_to_mark freed 4194303 items $1 = (0, <repeats 2097152 times>) ... in fortran_array_printer_impl::process_element. The problem also exists for Ada: ... +print Arr value_free_to_mark freed 2097152 items $1 = (0 <repeats 2097152 times>) ... but is fixed by the fix for C. Add Fortran and Ada variants of the test-case. The *.exp files are similar enough to the original to keep the copyright years range. While writing the Fortran test-case, I ran into needing an additional print setting to print the entire array in repeat form, filed as PR exp/30817. I managed to apply the compilation loop for the Ada variant as well, but with a cumbersome repetition style. I noticed no other test-case uses gnateD, so perhaps there's a better way of implementing this. The regression test included in the patch is formulated in its weakest form, to avoid false positive FAILs, which also means that smaller regressions may not get detected. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-14[gdb/testsuite] Modernize gdb.base/huge.expTom de Vries1-18/+33
Rewrite test-case gdb.base/huge.exp: - use build_executable rather than gdb_compile, - use save_vars, - factor out hardcoded loop limits min and max, - handle compilation failure using require, and - avoid using . in regexp to match $, {} and <>. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-12gdb/mi: remove warning about mi1Simon Marchi1-10/+0
Remove a warning about mi1. mi1 was removed in 975249ff4e26 ("Remove MI version 1"). It is no longer possible to reach this warning, since trying to use interpreter mi1 bails out before: $ ./gdb -nx -q --data-directory=data-directory -i mi1 Interpreter `mi1' unrecognized Change-Id: Ie43b21e01bca1407995150c729531a70ee662003 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-12Avoid spurious breakpoint-setting failure in DAPTom Tromey2-3/+14
A user pointed out that if a DAP setBreakpoints request has a 'source' field in a SourceBreakpoint object, then the gdb DAP implementation will throw an exception. While SourceBreakpoint does not allow 'source' in the spec, it seems better to me to accept it. I don't think we should fully go down the "Postel's Law" path -- after all, we have the type-checker -- but at the same time, if we do send errors, they should be intentional and not artifacts of the implementation. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30820
2023-09-12gdb: Fix -Wuninitialized issueEnze Li1-0/+1
I see the following warning when building GDB on FreeBSD/amd64 with Clang 14, ====================================================================== CXX mdebugread.o mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized] f->set_loc_enumval (tsym.value); ^ mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning struct field *f; ^ = nullptr ====================================================================== after digging a little, I realized that we can not simply do what Clang 14 says. The root cause of this issue is that we lost the initialization of the variable 'f' in this commit, commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e Date: Thu Aug 31 09:37:44 2023 +0200 [gdb/symtab] Factor out type::{alloc_fields,copy_fields} we have made these modifications, --------------------------------------------------------------------- --- a/gdb/mdebugread.c +++ b/gdb/mdebugread.c @@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend, t->set_code (type_code); t->set_length (sh->value); - t->set_num_fields (nfields); - f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field))); - t->set_fields (f); + t->alloc_fields (nfields, false); --------------------------------------------------------------------- The problem is that the variable 'f' is used in the second half of parse_symbol, that's why Clang complained. To fix this issue we need to ensure that the varibale 'f' is initialized. Calling the fields method is an obvious way to fix this issue. Tested on FreeBSD/amd64 by rebuilding. Approved-By: Tom de Vries <tdevries@suse.de>
2023-09-12gdb/testsuite/rocm: fix rocm-multi-inferior-gpu.cppLancelot Six1-1/+1
The gdb/testsuite/gdb.rocm/multi-inferior-gpu.cpp testcase contains a call to execl which does not have NULL as a last argument. This is an invalid use of execl. This patch fixes this oversight. Change-Id: I03b60abe30468d71ba5089b240c6d00f9b8883b2 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-11Specialize std::hash for ptid_tTom Tromey2-2/+2
This changes hash_ptid to instead be a specialization of std::hash. This makes it a little easier to use with standard containers. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-09-11Update Python signal-handling documentationTom Tromey1-2/+4
I noticed a typo in the "Basic Python" node, and when fixing it realized that the paragraph could use a link to the block_signals function. This patch is the result. Approved-By: Eli Zaretskii <eliz@gnu.org>
2023-09-11gdb/testsuite: use foreach_with_prefix in gdb.guile/scm-ports.expSimon Marchi1-60/+54
Simplify things a bit using foreach_with_prefix. The only expected change is in the naming of tests. Change-Id: Icb5e55207e0209e0d44d9e7c16a2f5e11aa29017 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-09-11testsuite, fortran: Fix regression due to fix for ifort's 'start' behaviorIjaz, Abdul B1-5/+5
Got a regression email due to merge of commit in CI config tcwg_gdb_check/master-aarch64 : https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=41439185cd0075bbb1aedf9665685dba0827cfec Begining of test "gdb.fortran/array-slices-bad.exp" was updated in above commit to start the test from running to line with tag "First Breakpoint" instead of "fortran_runto_main". Reason of the regression is shared libraries are still loaded after hitting the breakpoint as "nosharedlibrary" is already called before hitting the breakpoint. So now after this change test is updated accordingly to disable and unload shared libraries symbols after hitting the first breakpoint. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-09-11gdb: c++ify btrace_target_infoMarkus Metzger3-148/+95
Following the example of private_thread_info and private_inferior, turn struct btrace_target_info into a small class hierarchy. Also merge btrace_tinfo_bts with btrace_tinfo_pt and inline into linux_btrace_target_info. Fixes PR gdb/30751.
2023-09-11gdb, btrace: move xml parsing into remote.cMarkus Metzger3-324/+317
The code is only used in remote.c and all functions can be declared static.
2023-09-10gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUsSimon Marchi1-1/+1
I see the following failure when running this test on an AMD machine: p/x $fioff^M $24 = 0x0^M (gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff The register that GDB calls fioff normally contains the address of the last instruction executed by the x87 unit. It is available through the FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE area. You can read about it in the Intel manual [1] at section "10.5.1 FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD manual [2] at section "11.4.4 Saving Media and x87 Execution Unit State". The test therefore expects that after executing the FLD1 instruction, the fioff register contains the address of the FLD1 instruction. However, the FXSAVE and XSAVE instructions (which the kernel uses to dump x87 register state which it provides GDB through ptrace) behave differently on AMD CPUs. In section "11.4.4.3 FXSAVE and FXRSTOR Instructions" of the AMD manual, we read: The FXSAVE and FXRSTOR instructions save and restore the entire 128-bit media, 64-bit media, and x87 state. These instructions usually execute faster than FSAVE/FNSAVE and FRSTOR because they do not normally save and restore the x87 exception pointers (last-instruction pointer, last data-operand pointer, and last opcode). The only case in which they do save the exception pointers is the relatively rare case in which the exception-summary bit in the x87 status word (FSW.ES) is set to 1, indicating that an unmasked exception has occurred. So, unless a floating point exception happened and that exception is unmasked in the x87 FPU control register (which isn't by default on Linux, from what I saw), the "last instruction address" register (or fioff as GDB calls it) will always be 0 on an AMD CPU. For this reason, I think it's fine to change the test to accept the value 0 - that's just how the processor works. I toyed with the idea of changing the test program to make it so the CPU would generate a non-zero fioff. That is by unmasking an FPU exception and executing an instruction to raise that kind exception. It worked, but then I would have to change the test more extensively, and it didn't seem to be worth it. [1] https://cdrdv2.intel.com/v1/dl/getContent/671200 [2] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf Change-Id: If2e1d932f600ca01b15f30b14b8d38bf08a3e00b Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-09-08Run 'black' on recent test caseTom Tromey1-0/+1
The auto-builders pointed out that I neglected to run 'black' after a rest testcase change. This patch fixes the oversight.
2023-09-08gdb/doc: describe x87 registersSimon Marchi1-0/+19
While investigating this [1], I initially had no idea what register "fioff" stood for, making it difficult to map it to something in the Intel or AMD manuals. Similarly, I can imaging someone familiar with x87 to want to print the "x87 last instruction address", and have no clue that GDB makes it available as register "fioff". The names of the x87 state fields don't seem to be standardized, they even change between sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area descriptions). Add some details to the doc to help one map GDB register names to x87 state fields. [1] https://inbox.sourceware.org/gdb-patches/20230908022722.430741-1-simon.marchi@efficios.com/T/#u Change-Id: I0ea1eb648358e62da4aa87eea3515ee8a09f2762 Approved-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Pedro Alves <pedro@palves.net>
generated by cgit v1.1 at 2025-01-15 16:55:08 +0000