diff options
author | Andrew Burgess <aburgess@redhat.com> | 2025-08-25 16:47:20 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2025-10-06 16:56:55 +0100 |
commit | fc8e5a565b3ae1b304dfb2de664b23722d97b794 (patch) | |
tree | e6c47538b9320c5d90cc3e3a2839fb4521454fbb /gdb/python/py-corefile.c | |
parent | 7862554bcf4fc067000f5fcead577c6f8492e8d7 (diff) | |
download | binutils-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