aboutsummaryrefslogtreecommitdiff
path: root/gdb/NEWS
diff options
context:
space:
mode:
authorKevin Buettner <kevinb@redhat.com>2020-07-03 21:55:51 -0700
committerKevin Buettner <kevinb@redhat.com>2020-07-22 12:50:30 -0700
commit09c2f5d45cda73009e5e68e6cc84be6722f386fb (patch)
treeae7be890b182451292b01ff98106ae64c4d23a67 /gdb/NEWS
parent9c5ec5c2dab18154b44a7bbb430cc7d393424116 (diff)
downloadgdb-09c2f5d45cda73009e5e68e6cc84be6722f386fb.zip
gdb-09c2f5d45cda73009e5e68e6cc84be6722f386fb.tar.gz
gdb-09c2f5d45cda73009e5e68e6cc84be6722f386fb.tar.bz2
Add new command "maint print core-file-backed-mappings"
I wrote a read_core_file_mappings method for FreeBSD and then registered this gdbarch method. I saw some strange behavior while testing it and wanted a way to make sure that mappings were being correctly loaded into corelow.c, so I wrote the new command which is the topic of this commit. I think it might be occasionally useful for debugging strange corefile behavior. With regard to FreeBSD, my work isn't ready yet. Unlike Linux, FreeBSD puts all mappings into its core file note. And, unlike Linux, it doesn't dump load segments which occupy no space in the file. So my (perhaps naive) implementation of a FreeBSD read_core_file_mappings didn't work all that well: I saw more failures in the corefile2.exp tests than without it. I think it should be possible to make FreeBSD work as well as Linux, but it will require doing something with all of the mappings, not just the file based mappings that I was considering. In the v4 series, Pedro asked the following: I don't understand what this command provides that "info proc mappings" doesn't? Can you give an example of when you'd use this command over "info proc mappings" ? On Linux, "info proc mappings" and "maint print core-file-backed-mappings" will produce similar, possibly identical, output. This need not be the case for other OSes. E.g. on FreeBSD, had I finished the implementation, the output from these commands would have been very different. The FreeBSD "info proc mappings" command would show additional (non-file-backed) mappings in addition to at least one additional field (memory permissions) for each mapping. As noted earlier, I was seeing some unexpected behavior while working on the FreeBSD implementation and wanted to be certain that the mappings were being correctly loaded by corelow.c. "info proc mappings" prints the core file mappings, but doesn't tell us anything about whether they've been loaded by corelow.c This new maintenance command directly interrogates the data structures and prints the values found there. gdb/ChangeLog: * corelow.c (gdbcmd.h): Include. (core_target::info_proc_mappings): New method. (get_current_core_target): New function. (maintenance_print_core_file_backed_mappings): New function. (_initialize_corelow): Add core-file-backed-mappings to "maint print" commands.
Diffstat (limited to 'gdb/NEWS')
0 files changed, 0 insertions, 0 deletions