From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53858 invoked by alias); 12 Jan 2016 13:25:21 -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 53778 invoked by uid 89); 12 Jan 2016 13:25:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=*info, sk:section, Hx-languages-length:2409, bits_per_word 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; Tue, 12 Jan 2016 13:25:19 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1aIywl-0007M0-Jk from Luis_Gustavo@mentor.com ; Tue, 12 Jan 2016 05:25:15 -0800 Received: from [172.30.8.111] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Tue, 12 Jan 2016 05:25:15 -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> <5693CE90.1060709@codesourcery.com> <5694F5BC.3050904@redhat.com> To: Pedro Alves , "Maciej W. Rozycki" CC: , From: Luis Machado Message-ID: <5694FEB8.10406@codesourcery.com> Date: Tue, 12 Jan 2016 13:25:00 -0000 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: <5694F5BC.3050904@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00221.txt.bz2 On 01/12/2016 10:46 AM, Pedro Alves wrote: > On 01/11/2016 03:47 PM, Luis Machado wrote: >> 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; > > This callback is registered for bfd_arch_mips: > > gdbarch_register (bfd_arch_mips, mips_gdbarch_init, mips_dump_tdep); > > Does bfd think this a bfd_arch_mips binary? How so? In the second time we call gdbarch_info_fill, when opening the core file alone, we have this: p *info $8 = {bfd_arch_info = 0x0, byte_order = BFD_ENDIAN_UNKNOWN, byte_order_for_code = BFD_ENDIAN_UNKNOWN, abfd = 0xe1ce80, tdep_info = 0x0, osabi = GDB_OSABI_UNINITIALIZED, target_desc = 0x0} p *info->abfd->arch_info $10 = {bits_per_word = 32, bits_per_address = 32, bits_per_byte = 8, arch = bfd_arch_unknown, mach = 0, arch_name = 0x9b799f "unknown", printable_name = 0x9b799f "unknown", section_align_power = 2, the_default = 1, compatible = 0x78a592 , scan = 0x78a60a , fill = 0x78acc6 , next = 0x0} p *default_bfd_arch $12 = {bits_per_word = 32, bits_per_address = 32, bits_per_byte = 8, arch = bfd_arch_mips, mach = 0, arch_name = 0x9d98e0 "mips", printable_name = 0x9d98e0 "mips", section_align_power = 3, the_default = 1, compatible = 0x832b40 , scan = 0x78a60a , fill = 0x78acc6 , next = 0x9d9b00 } The data above leads gdbarch_info_fill to assign default_bfd_arch to info->bfd_arch_info here: /* From the default. */ if (info->bfd_arch_info == NULL) info->bfd_arch_info = default_bfd_arch; So the core file essentially turns into a mips-compatible core file. This also happens with a powerpc-targeted gdb and likely any other architecture. For powerpc we get lucky and end up "passing" this test because it has no fatal failing conditions. It ends up displaying frame -1 for me, like so: PC not available^M #-1 in ?? ()