From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27707 invoked by alias); 9 Dec 2010 18:02:40 -0000 Received: (qmail 27697 invoked by uid 22791); 9 Dec 2010 18:02:39 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_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; Thu, 09 Dec 2010 18:02:31 +0000 Received: (qmail 18294 invoked from network); 9 Dec 2010 18:02:29 -0000 Received: from unknown (HELO tp.orcam.me.uk) (macro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Dec 2010 18:02:29 -0000 Date: Thu, 09 Dec 2010 18:02:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford cc: Catherine Moore , binutils@sourceware.org Subject: Re: [PATCH 4.0/4 v3] MIPS/GAS: Propagate symbol attributes In-Reply-To: Message-ID: References: <87y69gm0ex.fsf@firetop.home> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00350.txt.bz2 On Thu, 9 Dec 2010, Richard Sandiford wrote: > > So it's not about whether we should treat these symbols as MIPS16 code > > references or not, but to match the reality and not mislead the user into > > thinking standard MIPS code is being concerned. > > You haven't answered my question, or at least not in a way that > makes me understand it. The testcase in your original message > was a very artificial one, artificial enough that the correct > disassembly is open to debate. Do you have a real-world example > of people writing code like this? OK, fair enough -- I did all kinds of weird assembly programming stuff in my life (mainly back in my MS-DOS days in early 1990s), so this kind of coding is nothing unusual to me, but no, I don't have a current real-world example that would absolutely require this kind of an arrangement to work. And I can understand your reluctance to make changes to generic parts of GAS for the lone purpose of getting things 100% right where that would hardly ever matter for anyone. Given code actually produced is already correct, I insist on including the test case itself though. I'll see if I can make the disassembly right by interspersing the instructions with some otherwise unused labels. Would it be a solution that would satisfy you? Otherwise chances are the microMIPS change by its nature will fix the problem automatically -- I'll check that too before fiddling with the test case itself. The thing is for the purpose of correct microMIPS disassembly Chao-ying was kind enough to provide a piece of code to scan the symbol table and see if a location is within the span of any function symbol with the microMIPS annotation present and switch to the microMIPS mode if so. In the course of the recent rewrite I extended that approach to MIPS16 symbols as well. I hope you agree that is reasonable too. Maciej