public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/2] Documentation and testcase
Date: Tue, 24 Mar 2015 23:15:00 -0000	[thread overview]
Message-ID: <87egoe2dij.fsf@redhat.com> (raw)
In-Reply-To: <55113880.4060707@redhat.com> (Pedro Alves's message of "Tue, 24	Mar 2015 10:12:16 +0000")

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
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.

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.

Thanks,

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

  reply	other threads:[~2015-03-24 23:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19 23:22 [PATCH v4 0/2] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Sergio Durigan Junior
2015-03-19 23:22 ` [PATCH 2/2] Documentation and testcase Sergio Durigan Junior
2015-03-20 19:46   ` Pedro Alves
2015-03-20 21:03     ` Sergio Durigan Junior
2015-03-20 22:09       ` Pedro Alves
2015-03-22 20:46         ` Sergio Durigan Junior
2015-03-23 20:27           ` Pedro Alves
2015-03-23 21:08             ` Sergio Durigan Junior
2015-03-23 23:06               ` Pedro Alves
2015-03-24  6:37                 ` Sergio Durigan Junior
2015-03-24 10:12                   ` Pedro Alves
2015-03-24 23:15                     ` Sergio Durigan Junior [this message]
2015-03-24 23:48                       ` Pedro Alves
2015-03-19 23:22 ` [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter Sergio Durigan Junior
2015-03-20 19:12   ` Pedro Alves
2015-03-20 20:02     ` Sergio Durigan Junior
2015-03-20 22:02       ` Pedro Alves
2015-03-23 18:40         ` Sergio Durigan Junior
2015-03-23 20:36           ` Pedro Alves
2015-03-24 23:57 [PATCH v4 0/2] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Sergio Durigan Junior
2015-03-24 23:57 ` [PATCH 2/2] Documentation and testcase Sergio Durigan Junior
2015-03-27  9:53   ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87egoe2dij.fsf@redhat.com \
    --to=sergiodj@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).