From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54539 invoked by alias); 23 Mar 2015 23:06:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 54526 invoked by uid 89); 23 Mar 2015 23:06:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 23 Mar 2015 23:06:42 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2NN6eJq005567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 23 Mar 2015 19:06:41 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2NN6dDo009285; Mon, 23 Mar 2015 19:06:39 -0400 Message-ID: <55109C7E.2040504@redhat.com> Date: Mon, 23 Mar 2015 23:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sergio Durigan Junior CC: GDB Patches Subject: Re: [PATCH 2/2] Documentation and testcase References: <1426807358-18295-1-git-send-email-sergiodj@redhat.com> <1426807358-18295-3-git-send-email-sergiodj@redhat.com> <550C7905.9090501@redhat.com> <87mw37wfd6.fsf@redhat.com> <550C9A7C.90705@redhat.com> <87wq283gmx.fsf@redhat.com> <5510773D.4010107@redhat.com> <87wq274e1w.fsf@redhat.com> In-Reply-To: <87wq274e1w.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00762.txt.bz2 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 : 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