Re: [PATCH v2 4/5] Provide access to non SEC_HAS_CONTENTS core file sections

[Pedro Alves <palves@redhat.com>]

On 5/21/20 4:09 PM, Kevin Buettner wrote:
> On Thu, 21 May 2020 15:23:00 +0100
> Pedro Alves <palves@redhat.com> wrote:
>>
>> Thus, take 3:
>>
>> The question should have been -- why are there SEC_ALLOC && !SEC_HAS_CONTENTS
>> load segments for that data that should be read from the executable?
>> Or rather, why did the kernel decide to output a .bss-like load segment with
>> no contents for that mapping?  If there wasn't such a load segment
>> in the core, then we wouldn't need this heuristic.  This is looking like a kernel
>> bug to me.  Like, if the mapping was file backed and wasn't touched, then it
>> should have been skipped.  If it was touched (or for some other reason
>> that could justify dumping the mapping), then the kernel should have
>> included its current contents in the dump, instead of
>> indicating "no contents".  No?
> 
> The kernel simply dumps all of the memory that it knows about.  It
> doesn't try to filter anything out.  Should it determine that an area
> has a file based backing or that it was never written to (or several other
> conditions: MADV_DONTDUMP, I/O areas, etc), it'll skip dumping the
> contents, but will still dump a header.

I see.  I thought I'd check what other OSs do, so I found a Solaris 11
box, and did a bit of testing with a simple 

  #include <stdlib.h>
  int main { abort (); }

program.

Solaris has this coreadm utility that lets you configure what kind of
data is dumped on the core:
  https://docs.oracle.com/cd/E19253-01/816-5166/coreadm-1m/index.html

Comparing dumps with
  $ coreadm -I none
vs 
  $ coreadm -I default

I see that Solaris dumps the exact same set of segments in both
cases, though in the "none" case, segments whose contents were not
dumped have headers with !CONTENTS.  Like:

 -  6 load2         00000000  0000000000400000  0000000000000000  00000000  2**0
 -                  ALLOC, READONLY, CODE
 +  6 load2         00001000  0000000000400000  0000000000000000  00003068  2**0
 +                  CONTENTS, ALLOC, LOAD, READONLY, CODE

So seems like this isn't a Linux-specific thing...

I think this means that we're probably going to be stuck with this
basically forever, and should do the best we can with the info we have.

Let me answer the other question about the info proc mappings idea in
response to your previous email.

Thanks,
Pedro Alves