From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54269 invoked by alias); 4 Feb 2016 21:01:19 -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 54258 invoked by uid 89); 4 Feb 2016 21:01:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=agnostic, silly, combines, buys 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; Thu, 04 Feb 2016 21:01:16 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email Security Gateway with ESMTPS id 05F059A0FA0BA; Thu, 4 Feb 2016 21:01:10 +0000 (GMT) Received: from [10.100.200.149] (10.100.200.149) by hhmail02.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.266.1; Thu, 4 Feb 2016 21:01:13 +0000 Date: Thu, 04 Feb 2016 21:01:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Luis Machado , , Jan Kratochvil Subject: Re: [PATCH] Handle loading improper core files gracefully in the mips backend. In-Reply-To: <56B0BBB4.6050105@redhat.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> <56B0A809.6070101@codesourcery.com> <56B0BAEA.7@redhat.com> <56B0BBB4.6050105@redhat.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-02/txt/msg00131.txt.bz2 On Tue, 2 Feb 2016, Pedro Alves wrote: > > Did you try to trigger the assertion by loading a 32-bit MIPS binary > > into gdb, and playing with "set mips abi n64/o64...", "set mipsfpu", > > etc? > > > > I think that adding a test to the testsuite that iterates through all > > the possible combinations just to make sure gdb doesn't crash > > would be great, and also show that the patch stands on its own > > as well, irrespective of the bfd arch compatibility issues. > > TBC, I meant, the original patch that checked unsuitable ABI/ISA > combinations. NB I can only see the use for these knobs to deal with two situations: 1. There's no executable and we want to connect to a live target for minimal binary-only/disasembly-level debugging. We need to set the endianness, ABI, ISA, etc. to match the target then (although arguably at least the endianness should be supplied by the debug stub somehow; we just don't have a way defined right now). 2. We have a buggy or outdated GDB executable which fails to determine the right settings automatically. As it looks for example as recently as last week I came across a problem where GDB failed to detect the presence of the FPU under Linux for some reason. I had to forcefully request `set mipsfpu double' to override the wrongly chosen setting of `none', at which point accesses to the FPU worked as expected, so it wasn't like the unit was inaccessible. Obviously I need to debug #2, but overall I agree we ought to bail out gracefully rather than crash if the manual settings lead to a nonsensical configuration. Therefore I went back to the original patch now. It obscures things a bit I'm afraid from my point of view as it combines a syntactical change (the addition of the `arch_is_incompatible' auxiliary variable) and a semantical change (the addition of the `mips_isa == ISA_MIPS16' check), so I'd like to see the two changes separated. TBH I'm not convinced whether the auxiliary variable buys us anything here -- it doesn't serve as documentation as we have an explanatory comment here already, which BTW needs to be updated accordingly if the condition is extended to cover an ISA incompatibility. As to which, and more importantly -- there is no actual architectural incompatibility between the n64 (or n32) ABI and the MIPS16 instruction set; there are 64-bit MIPS processors in existence which implement the MIPS16 ISA as well, e.g. the NEC VR4111, and the ISA itself includes 64-bit instructions on such a processor. So the MIPS16 ISA is really agnostic to the ABI, just as is the regular MIPS ISA or the microMIPS ISA. Therefore any such fix needs to go elsewhere I'm afraid -- we probably do something outright silly for the ISA_MIPS16 setting. Maciej