From patchwork Mon Jan 11 15:47:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Machado X-Patchwork-Id: 10330 Received: (qmail 104735 invoked by alias); 11 Jan 2016 15:47:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 104715 invoked by uid 89); 11 Jan 2016 15:47:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=*address, srcdir, Maciej, maciej X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Jan 2016 15:47:34 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1aIegt-0007IQ-Ia from Luis_Gustavo@mentor.com ; Mon, 11 Jan 2016 07:47:31 -0800 Received: from [172.30.8.111] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Mon, 11 Jan 2016 07:47:31 -0800 Reply-To: Luis Machado Subject: Re: [PATCH] Handle loading improper core files gracefully in the mips backend. References: <1452277948-25292-1-git-send-email-lgustavo@codesourcery.com> To: "Maciej W. Rozycki" CC: , From: Luis Machado Message-ID: <5693CE90.1060709@codesourcery.com> Date: Mon, 11 Jan 2016 13:47:28 -0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: X-IsSubscribed: yes On 01/09/2016 01:02 AM, Maciej W. Rozycki wrote: > On Fri, 8 Jan 2016, Luis Machado wrote: > >> Maciej, do you have more input on additional incompatibilities that we need >> to check for? > > Why do we get this far in the first place where e_machine != EM_MIPS? I > think rather than adding additional checks here (unless they're needed for > a valid MIPS ELF binary; but that would be a separate problem to fix) we > should reject such a core file outright. I thought about that, but no targets other than v850 use e_machine information during arch initialization, which is strange. It seems we just don't enforce compatibility, at least when loading core files. Does the attached patch match what you have in mind? I also adjusted the testcase to expect core file rejection and also got rid of duplicated test strings. Now a mips-targeted GDB says the following when trying to load a x86 core file: gdb.arch/i386-biarch-core.core": no core file handler recognizes format gdb/ChangeLog: 2016-01-11 Luis Machado bz 18964 * mips-tdep.c (mips_gdbarch_init): Sanity check ELF e_machine field and bail out if it is not MIPS-compatible. gdb/testsuite/ChangeLog: 2016-01-11 Luis Machado bz 18964 * gdb.arch/i376-biarch-core.exp: Handle the core file not being recognized. Use variables for repeating test names. --- gdb/mips-tdep.c | 6 ++++++ gdb/testsuite/gdb.arch/i386-biarch-core.exp | 18 +++++++++++++++--- 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c index ca17864..cdfd80e 100644 --- a/gdb/mips-tdep.c +++ b/gdb/mips-tdep.c @@ -8208,6 +8208,12 @@ mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) int dspacc; int dspctl; + /* Sanity check the e_machine field. */ + if (info.abfd + && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour + && elf_elfheader (info.abfd)->e_machine != EM_MIPS) + return NULL; + /* Fill in the OS dependent register numbers and names. */ if (info.osabi == GDB_OSABI_IRIX) { diff --git a/gdb/testsuite/gdb.arch/i386-biarch-core.exp b/gdb/testsuite/gdb.arch/i386-biarch-core.exp index 607b947..a4c0541 100644 --- a/gdb/testsuite/gdb.arch/i386-biarch-core.exp +++ b/gdb/testsuite/gdb.arch/i386-biarch-core.exp @@ -28,13 +28,14 @@ gdb_start gdb_reinitialize_dir $srcdir/$subdir set test "complete set gnutarget" +set text_test ".text is readable" gdb_test_multiple "complete set gnutarget " $test { -re "set gnutarget elf64-little\r\n(.*\r\n)?$gdb_prompt $" { pass $test } -re "\r\n$gdb_prompt $" { pass $test - untested ".text is readable" + untested $text_test return } } @@ -62,8 +63,19 @@ if {$corestat(size) != 102400} { # objcopy as it corrupts the core file beyond all recognition. # The output therefore does not matter much, just we should not get GDB # internal error. -gdb_test "core-file ${corefile}" ".*" "core-file" +set test "core-file" +gdb_test_multiple "core-file ${corefile}" $test { + -re ".* no core file handler recognizes format\r\n$gdb_prompt $" { + # Make sure we handle cases where the core file isn't even properly + # loaded due to architecture incompatibilities. + untested $text_test + return + } + -re "\r\n$gdb_prompt $" { + pass $test + } +} # Test if at least the core file segments memory has been loaded. # https://bugzilla.redhat.com/show_bug.cgi?id=457187 -gdb_test "x/bx $address" "\r\n\[ \t\]*$address:\[ \t\]*0xf4\[ \t\]*" ".text is readable" +gdb_test "x/bx $address" "\r\n\[ \t\]*$address:\[ \t\]*0xf4\[ \t\]*" $text_test -- 1.9.1