mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2026-08-27 00:26:02 -04:00
e492fb22b7
Back-port the following upstream commits to enable core file support within GDB's DAP protocol implementation: *0a481bb9a6gdb/dap: add support for opening core files *4ecaac39c2gdb/python: new events.corefile_changed event *ecac42af73Always propagate exceptions in DAP *fc8e5a565bgdb: make structured core file mappings processing global *f69c1d03c4gdb/python: add Corefile.mapped_files method *7862554bcfgdb/python: introduce gdb.Corefile API The commit messages for each individual commit follow: ---0a481bb9a6: gdb/dap: add support for opening core files This patch adds core file support to GDB's DAP interface. Core files are supported as a GDB specific argument to 'attach', the new argument is 'coreFile', the name of the core file to debug. I think handling core files via attach makes the most sense; attach is for connecting to existing processes, but these targets are (usually) stopped as soon as GDB attaches, and that's what a core file looks like, a target that was running, but is now stopped. It just happens that core file targets are special in that the target cannot be resumed again, nor can the user modify the program state (e.g. write to memory or registers). Prior to starting this work I took a look at what lldb does. The documentation is not super clear, but this page seems to indicate that lldb might also use the 'coreFile' argument to 'attach': https://lldb.llvm.org/use/lldbdap.html#configuration-settings-reference Like I said, it's not very clear, but search for "coreFile" and you'll see it mentioned, just once, under the "attach" header. In order to be compatible with lldb I used the same argument name with the same capitalisation. The new argument is added to the documentation and mentioned in NEWS. I had to make some changes to testsuite/lib/dap-support.exp to support this new feature. There's a new dap_corefile proc to handle setting up the initial connection. This seemed cleaner that overloading dap_attach, even though under the hood it is still an 'attach' request that gets sent. The new test tries to write to memory and registers with the core file target in place, neither of these requests succeed, which is what we want, but the exceptions are logged into the dap log file. The dap_shutdown proc calls dap_check_log_file to check the log for exceptions, and these two exceptions are spotted and trigger a FAIL. To avoid this I've added a new "expected_exception_count" argument for dap_shutdown. Now we check that we see the expected number of exceptions. We don't check for the specific exception types right now, but as the test is already checking that the expected requests fail, I think we're OK. Approved-By: Tom Tromey <tom@tromey.com> ---4ecaac39c2: gdb/python: new events.corefile_changed event Add a new Python event registry, events.corefile_changed. This event is emitted each time the corefile within an inferior changes. The event object has a single 'inferior' attribute which is the gdb.Inferior object for which the core file changed. The user can then inspect Inferior.corefile to see details about the new core file, or this will be None if the core file was removed from the inferior. I've updated the existing test to cover this new event. The new test covers both the corefile_changed event, but also monitors the exited event. This ties into the work done in the previous commit where we use whether the inferior has exited or not as a guard for whether core_target::exit_core_file_inferior should be called. Unloading a core file should result in a single corefile_changed event and a single exited event. Reviewed-By: Eli Zaretskii <eliz@gnu.org> ---ecac42af73: Always propagate exceptions in DAP This changes the DAP exec_and_log function to always transform an exception into a DAPException and propagate it. As the bug points out, we haven't always wrapped calls when appropriate. I think it's better to cause the request to fail by default; if any spot truly needs to ignore errors, that is readily done at the point of call. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33346 ---fc8e5a565b: gdb: make structured core file mappings processing global In corelow.c, within core_target::build_file_mappings, we have code that wraps around a call to gdbarch_read_core_file_mappings and provides more structure to the results. Specifically, gdbarch_read_core_file_mappings calls a callback once for every region of every mapped file. The wrapper code groups all of the mappings for one file into an instance of 'struct mapped_file', this allows all of the mapped regions to be associated with the build-id and filename of a file. In the next commit I plan to make this information available via the Python API, and so I need to allow access to this structured wrapping outside of corelow.c. This commit renames 'struct mapped_file' to 'struct core_mapped_file' and moves the struct into gdbcore.h. Then a new global function gdb_read_core_file_mappings is created into which I move the code to build the structured data. Then corelow.c is updated to call gdb_read_core_file_mappings. This commit does not extend the Python API, that is for the next commit. There should be no user visible changes after this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Approved-By: Tom Tromey <tom@tromey.com> ---f69c1d03c4: gdb/python: add Corefile.mapped_files method Add a new Corefile.mapped_files method which returns a list of gdb.CorefileMappedFile objects. Each gdb.CorefileMappedFile object represents a file that was mapped into the process when the core file was created. A gdb.CorefileMappedFile has attributes: + filename -- A string, the name of the mapped file. + build_id -- A string or None, the build-id of the mapped file if GDB could find it (None if not). + is_main_executable -- A boolean, True if this mapping is the main executable. + regions -- A list containing the regions of this file that were mapped into the process. The 'regions' list is a list of gdb.CorefileMappedFileRegion objects, each of these objects has the following attributes: + start -- the start address within the inferior. + end -- the end address within the inferior. + file_offset -- the offset within the mapped file for this mapping. There are docs and tests. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Approved-By: Tom Tromey <tom@tromey.com> ---7862554bcf: gdb/python: introduce gdb.Corefile API This commit starts adding some core file related features to the Python API. In this initial commit I've tried to keep the changes as small as possible for easy review. There's a new Python class gdb.Corefile, which represents a loaded core file. This API doesn't allow the user to create their own gdb.Corefile objects, a core file must be loaded using the 'core-file' command, then a gdb.Corefile object can be obtained by querying the inferior in which the core file was loaded. There's a new attribute gdb.Inferior.corefile, this is None when no core file is loaded, or contains a gdb.Corefile object if a core file has been loaded. Currently, the gdb.Corefile object has one attribute, and one method, these are: gdb.Corefile.filename -- the file name of the loaded core file. gdb.Corefile.is_valid() -- indicates if a gdb.Corefile object is valid or not. See notes below. A gdb.Corefile object is only valid while the corresponding core file is loaded into an inferior. Unloading the core file, or loading a different one will cause a gdb.Corefile object to become invalid. For example: (gdb) core-file /tmp/core.54313 ... snip ... (gdb) python core=gdb.selected_inferior().corefile (gdb) python print(core) <gdb.Corefile inferior=1 filename='/tmp/core.54313'> (gdb) python print(core.is_valid()) True (gdb) core-file No core file now. (gdb) python print(core) <gdb.Corefile (invalid)> (gdb) python print(core.is_valid()) False (gdb) In order to track changes to the core file, there is a new observable 'core_file_changed', which accounts for the changes in corelow.c, observable,c, and observable.h. Currently, this observable is not visible as a Python event. I chose to access the core file via the inferior even though the core file BFD object is actually stored within the program_space. As such, it might seem that the natural choice would be to add the attribute as gdb.Progspace.corefile. For background reading on my choice, please see: https://inbox.sourceware.org/gdb-patches/577f2c47793acb501c2611c0e6c7ea379f774830.1668789658.git.aburgess@redhat.com This patch was never merged, it is still on my backlog, but the observation in that work is that some targets are not really shareable. For example, the core_target (corelow.c) stores information about the loaded core file within the target instance. As such, each target instance represents a single loaded core file. Except that the BFD part of the core file is stored in the program_space, which is a little weird. During review, Tom made the observation, that maybe we should investigate moving the core file BFD into the core_target. I'm inclined to agree with this as a direction of travel. All this leaves us with two observations: 1. Currently, loading a core file into an inferior, then using 'add-inferior' will try to share the core_target between inferiors. This is broken, and can trigger GDB crashes. The obvious fix, without reworking core_target, is just to prevent this sharing, making core_target per-inferior. 2. Having the core file information split between the core_target instance, and the BFD stored in the program_space is a little weird, and is really just historical. Planning for a future where the BFD is also stored in the core_target might be wise. So, if we imagine that the BFD is (one day) moved into the core_target, and that the core_target really becomes non-shareable, then it is, I think, clearer that the corefile attribute should live on the gdb.Inferior object, not the gdb.Progspace object. There's testing for all the functionality added in this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
49 lines
1.7 KiB
C++
49 lines
1.7 KiB
C++
/* Python event definitions -*- c++ -*-
|
|
|
|
Copyright (C) 2017-2025 Free Software Foundation, Inc.
|
|
|
|
This file is part of GDB.
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License as published by
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
(at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
/* To use this file, define GDB_PY_DEFINE_EVENT to expand how you
|
|
like, then include the file.
|
|
|
|
GDB_PY_DEFINE_EVENT has one parameter, the name of the event.
|
|
*/
|
|
|
|
GDB_PY_DEFINE_EVENT(stop)
|
|
GDB_PY_DEFINE_EVENT(cont)
|
|
GDB_PY_DEFINE_EVENT(exited)
|
|
GDB_PY_DEFINE_EVENT(new_objfile)
|
|
GDB_PY_DEFINE_EVENT(free_objfile)
|
|
GDB_PY_DEFINE_EVENT(clear_objfiles)
|
|
GDB_PY_DEFINE_EVENT(new_inferior)
|
|
GDB_PY_DEFINE_EVENT(inferior_deleted)
|
|
GDB_PY_DEFINE_EVENT(new_thread)
|
|
GDB_PY_DEFINE_EVENT(thread_exited)
|
|
GDB_PY_DEFINE_EVENT(inferior_call)
|
|
GDB_PY_DEFINE_EVENT(memory_changed)
|
|
GDB_PY_DEFINE_EVENT(register_changed)
|
|
GDB_PY_DEFINE_EVENT(breakpoint_created)
|
|
GDB_PY_DEFINE_EVENT(breakpoint_deleted)
|
|
GDB_PY_DEFINE_EVENT(breakpoint_modified)
|
|
GDB_PY_DEFINE_EVENT(before_prompt)
|
|
GDB_PY_DEFINE_EVENT(gdb_exiting)
|
|
GDB_PY_DEFINE_EVENT(connection_removed)
|
|
GDB_PY_DEFINE_EVENT(executable_changed)
|
|
GDB_PY_DEFINE_EVENT(new_progspace)
|
|
GDB_PY_DEFINE_EVENT(free_progspace)
|
|
GDB_PY_DEFINE_EVENT(tui_enabled)
|
|
GDB_PY_DEFINE_EVENT(corefile_changed)
|