[PATCH 2/2] Documentation and testcase
Pedro Alves
palves@redhat.com
Tue Mar 24 23:48:00 GMT 2015
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
More information about the Gdb-patches
mailing list