[minicoredumper] Handling of unavailable bytes in minicoredumps by GDB

[Simon Marchi]

Hi!

I'd like to show you a prototype of GDB that handles the bytes that are
unavailable in the minicoredump (which are read as zeros currently).

The principle is very similar to the GDB tracepoints, where you also have
the concept of unavailable bytes.  Since a lot of work has been done to put the
infrastructure in place for tracepoints, it's not so bad to do it now for the
minicoredumps.

I made some minimal modifications to minicoredumper, in order to save what
memory was collected as part of the minicoredump.  I am saving the data in a
file called "dumped" which is next to the core dump.  Having this data directly
in the core dump, in a section of its own, would be much better.

To get a feel of it, I invite you to build the following branch of gdb:

  https://github.com/simark/binutils-gdb/tree/minicore-for-linutronix

It's a simple ./configure && make.  The gdb binary will be in the gdb directory.

You can then find the modified version of minicoredumper in the following
branch:

  https://github.com/simark/minicoredumper/tree/collected-for-linutronix


Inspecting memory that was collected yields the expected result:

(gdb) x/10w buf
0x601060 <buf>:    0x03020100 0x07060504 0x0b0a0908 0x0f0e0d0c
0x601070 <buf+16>: 0x13121110 0x17161514 0x1b1a1918 0x1f1e1d1c
0x601080 <buf+32>: 0x23222120 0x27262524


Inspecting memory that was not dumped now shows <unavailable> rather than
(wrong) zeros:

(gdb) x/10w buf_not_dumped
0x604b20 <buf_not_dumped>:    <unavailable> <unavailable> <unavailable> <unavailable>
0x604b30 <buf_not_dumped+16>: <unavailable> <unavailable> <unavailable> <unavailable>
0x604b40 <buf_not_dumped+32>: <unavailable> <unavailable>


If bytes are unavailable but the address falls into a read-only section, GDB
will fall back to read from the executable.  So it's still possible to read the
code, for example:

(gdb) disassemble main
Dump of assembler code for function main:
   0x000000000040076d <+0>: push   %rbp
   0x000000000040076e <+1>: mov    %rsp,%rbp
   0x0000000000400771 <+4>: sub    $0x20,%rsp
   0x0000000000400775 <+8>: movq   $0x0,-0x8(%rbp)
   ...

This also has the consequence that GDB features that rely on read memory will
now fail if they try to read uncollected memory.  This is probably good, because
we want to know when they are doing so, instead of silently reading false zeros.

That's it, comments are very welcome!

Simon