From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8310 invoked by alias); 31 Aug 2011 18:01:13 -0000 Received: (qmail 8290 invoked by uid 22791); 31 Aug 2011 18:01:11 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Aug 2011 18:00:57 +0000 Received: (qmail 28714 invoked from network); 31 Aug 2011 18:00:56 -0000 Received: from unknown (HELO tp.orcam.me.uk) (macro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Aug 2011 18:00:56 -0000 Date: Wed, 31 Aug 2011 18:01:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford cc: binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [PATCH] MIPS/BFD: Fix assertions with SGI IRIX files In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-SW-Source: 2011-08/txt/msg00672.txt.bz2 On Fri, 19 Aug 2011, Richard Sandiford wrote: > > If an SGI IRIX ELF variation binary (also produced by binutils for some > > target configurations) is loaded into GDB configured for the traditional > > MIPS ELF variation, then a load of assertion failures is spat. They > > actually come from BFD being confused. > > > > As no user input, however unreasonable, should ever trigger assertions > > and this is simply a case of an unsupported binary format, here's a fix to > > convert the offending code to do proper error reporting instead. > > > > Verified manually with GDB, the error messages are produced. I was > > unable to trigger this problem with the linker, even though this piece of > > code looks reachable within to me. > > How about just dropping the assertions? SHN_MIPS_TEXT and SHN_MIPS_DATA > are easy to handle, and it looks like the code will behave sensibly > regardless of SGI_COMPAT. Are you sure this code is safe under the matching conditions given the assertions to catch them? They were put there for a reason I presume, perhaps exactly because the originator was not sure about this safety. Do you happen to remember the story behind? I believe it's a moderately recent addition as I do remember the times the SGI emulation was the only one we handled (circa AD 1999). > I realise you might be thinking that the user would like to know that > they have the "wrong" emulation. No, actually not at all. There's no point in making noise if things work correctly; this just confuses people. OTOH I think it would definitely make sense to teach tools like `objdump', `readelf' and `file' even how to tell the MIPS ELF flavours apart and report that to the user appropriately, although I realise this may not necessarily be straightforward or reliable. Also I think emulation selection could be made a bit more flexible in GDB -- my observation has been that extra emulations are not easily accessible even if built into BFD -- the logic just picks the first one that does not reject the binary chosen outright and this does not really work well for making the choice between traditional and SGI flavour MIPS ELF format. That's a separate problem though and frankly a marginal one as far as I'm concerned. > But if this is the only detectable difference, it's better just to carry > on. If there are other detectable differences that cause real problems, > we should try to diagnose the problem there instead. Agreed. > A patch to remove the assertions is pre-approved if you agree that's OK. OK, but are you positive that'll be no regression? As would be silent mishandling compared to one accompanied with these assertions, however obscure they are. Maciej