Re: [PATCH 2/2] Documentation and testcase

[Pedro Alves <palves@redhat.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).

Sounds good.

> 
> Phew!  What a confusion...  :-/.  I hope things are clearer with this
> e-mail.

Thanks,
Pedro Alves