This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 2/2] Documentation and testcase
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>
- Date: Tue, 24 Mar 2015 19:15:32 -0400
- Subject: Re: [PATCH 2/2] Documentation and testcase
- Authentication-results: sourceware.org; auth=none
- References: <1426807358-18295-1-git-send-email-sergiodj at redhat dot com> <1426807358-18295-3-git-send-email-sergiodj at redhat dot com> <550C7905 dot 9090501 at redhat dot com> <87mw37wfd6 dot fsf at redhat dot com> <550C9A7C dot 90705 at redhat dot com> <87wq283gmx dot fsf at redhat dot com> <5510773D dot 4010107 at redhat dot com> <87wq274e1w dot fsf at redhat dot com> <55109C7E dot 2040504 at redhat dot com> <87619q2961 dot fsf at redhat dot com> <55113880 dot 4060707 at redhat dot com>
On Tuesday, March 24 2015, Pedro Alves wrote:
>> Therefore, if *also* considers tha case when the mapping is file-backed
>> private (which my patch doesn't do).
>> All this boils down to: my patch is incorrectly dumping the .text
>> segment when I ask it not to do that (i.e., when I ask it to ignore
>> file-backed private mappings and to dump anonymous private mappings),
>> and it is *not* dumping the .text segment when I ask it to dump it
>> (i.e., when I ask it to dump file-backed private mappings and to ignore
>> anonymous private mappings).
>> So, here's what I propose: I will rework this part of the patch and try
>> to come up with a better way of identifying these situations (mainly:
>> when a file-backed mapping has anonymous contents), and I will resubmit
>> it tomorrow. Along with that, I should be able to extend the testcase
>> to cover the disassemble case (and it should start to work fine once I
>> make those adjustments).
> Sounds good.
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...
I adjusted my patch to mimic this behavior. However, there is one more
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
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.
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible