From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82881 invoked by alias); 23 Mar 2015 21:08:47 -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 82872 invoked by uid 89); 23 Mar 2015 21:08:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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 21:08:45 +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 (Postfix) with ESMTPS id 2869DB5E62 for ; Mon, 23 Mar 2015 21:08:44 +0000 (UTC) Received: from localhost (unused-10-15-17-126.yyz.redhat.com [10.15.17.126]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2NL8hPH022321 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Mar 2015 17:08:43 -0400 From: Sergio Durigan Junior To: Pedro Alves 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> X-URL: http://blog.sergiodj.net Date: Mon, 23 Mar 2015 21:08:00 -0000 In-Reply-To: <5510773D.4010107@redhat.com> (Pedro Alves's message of "Mon, 23 Mar 2015 20:27:41 +0000") Message-ID: <87wq274e1w.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00758.txt.bz2 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. 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. 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. >> + >> +proc test_disasm { core address } { >> + global testfile >> + >> + # Restarting GDB without loading the binary >> + gdb_exit >> + gdb_start >> + >> + set core_loaded [gdb_core_cmd "$core" "load core"] >> + if { $core_loaded == -1 } { >> + fail "loading $core" >> + return >> + } >> + >> + gdb_test "disassemble $address" "No function contains specified address." \ >> + "disassemble function with corefile and without a binary" >> + >> + clean_restart $testfile >> + >> + set core_loaded [gdb_core_cmd "$core" "load core"] >> + if { $core_loaded == -1 } { >> + fail "loading $core" >> + return >> + } >> + >> + gdb_test "disassemble $address" "Dump of assembler code for function.*" \ >> + "disassemble function with corefile and with a binary" > > Looks like there are duplicate test messages here, in the > cases clean_restart, gdb_core_cmd, etc. fail. You can fix that > with e.g.: > > with_test_prefix "no binary" { > # Restart GDB without loading the binary. > gdb_exit > gdb_start > > set core_loaded [gdb_core_cmd "$core" "load core"] > if { $core_loaded == -1 } { > fail "load $core" > return > } > > gdb_test "disassemble $address" "No function contains specified address." \ > "disassemble function" > } > > with_test_prefix "with binary" { > clean_restart $testfile > > set core_loaded [gdb_core_cmd "$core" "load core"] > if { $core_loaded == -1 } { > fail "load $core" > return > } > > gdb_test "disassemble $address" "No function contains specified address." \ > "disassemble function" > } Thanks, fixed. >> +# Getting the inferior's PID > > "Get". Period at end. Fixed. >> +set infpid "" >> +gdb_test_multiple "info inferiors" "getting inferior pid" { >> + -re "process \($decimal\).*\r\n$gdb_prompt $" { >> + set infpid $expect_out(1,string) >> + } >> +} >> + >> +# Get the main function's address > > Period. Fixed. > (I saw a few other similar gerund uses in the file which > read a bit odd to me, but I didn't point them all out.) I removed all of them, and also added missing periods all over. Thanks. > This is OK with the missing test added. I'll wait until you clarify that comment above :-). I won't resubmit the patch now because it only contains fixes to comments. > Thanks for the patience and for working on this. Thank you! -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/