From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127988 invoked by alias); 2 Feb 2016 12:58:57 -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 127974 invoked by uid 89); 2 Feb 2016 12:58:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=improper, Hx-languages-length:2883, absence, proceeding 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, 02 Feb 2016 12:58:56 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1aQaXk-0004Fb-Vk from Luis_Gustavo@mentor.com ; Tue, 02 Feb 2016 04:58:53 -0800 Received: from [172.30.9.241] (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, 2 Feb 2016 04:58:52 -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> <56951F29.7070000@codesourcery.com> To: "Maciej W. Rozycki" CC: Pedro Alves , , From: Luis Machado Message-ID: <56B0A809.6070101@codesourcery.com> Date: Tue, 02 Feb 2016 12:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00049.txt.bz2 On 01/12/2016 04:30 PM, Maciej W. Rozycki wrote: > On Tue, 12 Jan 2016, Luis Machado wrote: >>> 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? > > The mapping between `e_machine' and `bfd_architecture' is only provided > by individual BFD ELF target backends, via the ELF_MACHINE_CODE and > ELF_ARCH macros. > >> 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 > > Regardless, I'd expect a suitable generic ELF BFD target to be selected, > which is what AFAICT `bfd_check_format' does. It is called by our > `core_open' function and has a `core_file_p' handler, which makes suitable > checks including `e_machine' in particular, except for generic ELF BFD > targets, which are special-cased (and always come last). So in the > absence of specific ELF target support in BFD I'd expect a compatible > generic ELF target to be chosen rather than the default BFD target, which > might be incompatible. > Ah, indeed this is the case. We switch to a generic ELF target during bfd_check_format. So that is working as it should. >> 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? > > I have given it some thought and came to a conclusion that we should at > least try being consistent. Which means I think we should not try to > handle files within the MIPS backend which would not be passed in the > first place in an `--enable-targets=all' configuration. Rather than > checking `e_machine' explicitly I'd be leaning towards using BFD to detect > such a situation though, perhaps by using a condition like > > if (info.abfd != NULL > && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour > && bfd_get_arch (info.abfd) != bfd_arch_mips) > return NULL; > > (maybe with an additional error message) though ultimately I think it > would make sense to define different BFD architecture codes for file > formats which by definition carry no architecture information and for ones > that do but are not supported. Then for the formers we could continue > selecting the target using the current algorithm and for the latters we'd > just reject them as incompatible with the given backend -- all somewhere > in generic code so that individual target backends do not have to repeat > it all. Though the above doesn't solve the bigger picture, it gets rid of the internal error when loading the incompatible core file. Should we go ahead and have this additional check committed? Luis