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