This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 2/2] Documentation and testcase
- From: Pedro Alves <palves at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>
- Date: Tue, 24 Mar 2015 10:12:16 +0000
- 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>
On 03/24/2015 06:37 AM, Sergio Durigan Junior wrote:
> The Linux kernel uses the bit 4 on the coredump_filter file to determine
> whether it should dump ELF headers or not. According to vma_dump_size:
> So maybe this is what you meant above by "that one ends up always
> dumped...", when refering to the first page of the text segment? Well,
> that is partially true: if you unset bit 4, you will see that this page
> does not get dumped at all (and therefore we see the "Cannot access
> memory..." error; I did some experiments here and confirmed that).
Ah, indeed I probably had bit 4 set.
> 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).
> Phew! What a confusion... :-/. I hope things are clearer with this