This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] Documentation and testcase

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.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]