From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25781 invoked by alias); 12 Jan 2016 15:43:50 -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 24362 invoked by uid 89); 12 Jan 2016 15:43:49 -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=Initially 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 15:43:45 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1aJ16j-0003tj-Ct from Luis_Gustavo@mentor.com ; Tue, 12 Jan 2016 07:43:41 -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; Tue, 12 Jan 2016 07:43:41 -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> <5694FEB8.10406@codesourcery.com> <56950952.2030504@redhat.com> To: Pedro Alves , "Maciej W. Rozycki" CC: , From: Luis Machado Message-ID: <56951F29.7070000@codesourcery.com> Date: Tue, 12 Jan 2016 15:43: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: <56950952.2030504@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00226.txt.bz2 On 01/12/2016 12:10 PM, Pedro Alves wrote: > On 01/12/2016 01:25 PM, Luis Machado wrote: >> 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. > > Hmmm. I see. I think we can't really change this, given that there > are formats that don't have an architecture. Like, e.g., srec: > > (gdb) file testsuite/gdb.base/intstr2.srec > Reading symbols from testsuite/gdb.base/intstr2.srec...(no debugging symbols found)...done. > > I take it that a --enable-targets=all wouldn't fail like this? > Yes, because, at least in my case, we default to the proper i386 architecture. > Also, sounds like you should be able to trigger these incompatibilities > and assertion by loading a 32-bit MIPS binary and playing with > "set mips abi n64/o64", etc? > Yes, most likely, but see below. > All in all, maybe your original patch that flagged incompatible > abi/isa combination is the way to go? > > I also wonder whether the bfd arch detection couldn't be always > compiled in, at least for elf. Why does bfd fail to detect that this > is an bfd_arch_i386 file in the first place? It seems bfd also falls back to the default, which is mips in this case. p bfd_default_vector[0] $3 = (const bfd_target *) 0x9beac0 I gave it a try with a legitimate x86 core file being loaded in a mips-targeted gdb and i see the same problem with the internal error. Initially, when loading the core, the bfd arch is unknown, and then we pick the default arch in bfd_find_target here: /* This is safe; the vector cannot be null. */ if (targname == NULL || strcmp (targname, "default") == 0) { if (bfd_default_vector[0] != NULL) target = bfd_default_vector[0]; else target = bfd_target_vector[0]; if (abfd) { abfd->xvec = target; abfd->target_defaulted = TRUE; } return target; } Sounds like we have a couple issues. The mips backend not handling weird abi/isa combinations and GDB not preventing clearly incompatible core files from proceeding further into processing in the target's backend?