Re: [PATCH 2/2] Documentation and testcase

[Pedro Alves <palves@redhat.com>]

On 03/24/2015 11:15 PM, Sergio Durigan Junior wrote:

> And I am back, with new investigations and results.  This whole thing is
> starting to driving me crazy.
> 
> What I found is interesting.  When a memory mapping is file-backed, but
> contains Anonymous: pages, the Linux kernel dumps this region when:
> 
>   - The user asks for anonymous pages, *OR*
> 
>   - The user asks for file-backed pages
> 
> Yes, it dumps the mapping in *both* scenarios.  It is like a
> "file-backed anonymous" mapping...

It makes sense to me.

> 
> I adjusted my patch to mimic this behavior.  However, there is one more
> thing...
> 
> For some reason, when I run the binary inside GDB, the .text segment
> *contains* Anonymous: pages.  However, when I run the binary outside
> GDB, the Anonymous: counter is always zero.  This means that, inside
> GDB, when we ask for a corefile that excludes file-backed private
> mappings (i.e., the .text segment), according to the Linux kernel's
> rules, the .text segment *still* should be dumped because it contains
> Anonymous: pages.

I'd guess those were pages gdb poked/wrote to?  Breakpoints, most
likely.  That should trigger a COW of the poked page.

> Unfortunately, I was not able to generate a binary whose .text segment
> contained Anonymous: pages outside GDB.  However, I made a binary
> that has Anonymous: pages on a file-backed mapping, and I made the Linux
> kernel generate a corefile for it while asking it to exclude file-backed
> mappings, and I could confirm that the Linux kernel indeed includes this
> mapping in the corefile.
> 
> My final proposal, which will be reflected in a patch that will be
> submitted soon, is to relax the test of the the disassembly of main.
> This way, we can still mimic what the Linux kernel does and make GDB
> compatible with it.

Not sure what relax means, but I'll just wait for the patch.  :-)

Thanks,
Pedro Alves