From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94755 invoked by alias); 12 Jan 2016 18:30:22 -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 94742 invoked by uid 89); 12 Jan 2016 18:30:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=BFD, our X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Jan 2016 18:30:19 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Websense Email Security Gateway with ESMTPS id AAE3DE811CB2E; Tue, 12 Jan 2016 18:30:13 +0000 (GMT) Received: from [10.100.200.34] (10.100.200.34) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.235.1; Tue, 12 Jan 2016 18:30:16 +0000 Date: Tue, 12 Jan 2016 18:30:00 -0000 From: "Maciej W. Rozycki" To: Luis Machado CC: Pedro Alves , , Subject: Re: [PATCH] Handle loading improper core files gracefully in the mips backend. In-Reply-To: <56951F29.7070000@codesourcery.com> Message-ID: 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> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-01/txt/msg00230.txt.bz2 On Tue, 12 Jan 2016, Luis Machado wrote: > > > 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. Or we could be talking to a live target with no executable selected at all. This is also why there are settings like `set mips abi ...' available -- to let the user select the executable model for a target there's no other source of information about. > > 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. > 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. As to ABI, ISA, etc. settings -- these are internal to the MIPS backend, so its the backend's job to sanitise them. Maciej