aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-corefile.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2025-08-25 16:47:20 +0100
committerAndrew Burgess <aburgess@redhat.com>2025-10-06 16:56:55 +0100
commitfc8e5a565b3ae1b304dfb2de664b23722d97b794 (patch)
treee6c47538b9320c5d90cc3e3a2839fb4521454fbb /gdb/python/py-corefile.c
parent7862554bcf4fc067000f5fcead577c6f8492e8d7 (diff)
downloadbinutils-fc8e5a565b3ae1b304dfb2de664b23722d97b794.zip
binutils-fc8e5a565b3ae1b304dfb2de664b23722d97b794.tar.gz
binutils-fc8e5a565b3ae1b304dfb2de664b23722d97b794.tar.bz2
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>
Diffstat (limited to 'gdb/python/py-corefile.c')
0 files changed, 0 insertions, 0 deletions