[PATCH 2/2] Documentation and testcase
Pedro Alves
palves@redhat.com
Mon Mar 23 23:06:00 GMT 2015
On 03/23/2015 09:08 PM, Sergio Durigan Junior wrote:
> On Monday, March 23 2015, Pedro Alves wrote:
>
>> On 03/22/2015 08:45 PM, Sergio Durigan Junior wrote:
>>
>>> +# We do not do file-backed mappings in the test program, but it is
>>> +# important to test this anyway. One way of performing the test is to
>>> +# load GDB with a corefile but without a binary, and then ask for the
>>> +# disassemble of a function (i.e., the binary's .text section). GDB
>>> +# should fail in this case. However, it must succeed if the binary is
>>> +# provided along with the corefile. This is what we test here.
>>
>> It seems like we now just miss the case of corefilter that _does_ request
>> that the file backed regions are dumped. In that case, disassembly
>> should work without the binary. Could you add that too, please? We
>> can e.g., pass a boolean parameter to test_disasm to specify whether
>> to expect that disassembly works without a program file.
>
> Hm, I'm afraid there's a bit of confusion here, at least from my part.
>
> I am already testing the case when we use a value that requests that
> file-backed regions are dumped. If you take a look at the
> "all_anon_corefiles" list, you will see that the each corefile generated
> there includes everything *except* for the specific type of mapping we
> want to ignore (thus the "non_*" names).
> And the result of this test is
> that GDB cannot disassemble a function without a binary, even if all the
> file-backed pages have been dumped.
Now I'm confused. If all the file-backed pages have been dumped,
then aren't the .text present in the core dump? If that doesn't work,
we've just caught a bug somewhere.
>
> Having said that, I made a test with git HEAD without my patch. I
> generated a corefile for the same test program, and then loaded only the
> corefile:
>
> $ ./gdb -q -ex 'core ./core.31118' -ex 'disas 0x4007cb'
> ...
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> #0 0x0000000000400905 in ?? ()
> No function contains specified address.
> (gdb)
>
> Which means that, even without my patch, GDB still cannot disassemble a
> function without the binary.
Oh, without symbols, you need to tell "disassemble" an address range
to disassemble, not just an address. Like, "disassemble 0x4007cb, +10".
Otherwise that fails even before a memory read was ever attempted, while
gdb was looking for the function's boundaries.
I tried poking at coredump_filter now and, and I'm actually seeing
the opposite. I can always disassemble `main'.
$ gdb segv -c core.22587
...
Core was generated by `./segv'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000004004a5 in main () at segv.c:5
5 *(volatile int *)0;
(gdb) x /i $pc
=> 0x4004a5 <main+9>: mov (%rax),%eax
$ gdb -c core.22587
...
(gdb) x /i $pc
=> 0x4004a5: mov (%rax),%eax
The reason that works is that `main' happens to end up in the
first page of the text segment, and that one ends up always
dumped, as the dynamic loader touches it...
I do see that kernel generated cores do get bigger if I set
file-backed bits in coredump_filter:
$ ls -s --hu core.*
2.3M core.22528 112K core.22587
Bah, can't immediately think of a portable way to test this now.
>
> FWIW, I did the same test, but this time using a corefile generated by
> the Linux kernel (and with all bits set on coredump_filter), and the
> results were the same.
Thanks,
Pedro Alves
More information about the Gdb-patches
mailing list