From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25378 invoked by alias); 10 Nov 2010 17:58:14 -0000 Received: (qmail 25366 invoked by uid 22791); 10 Nov 2010 17:58:13 -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; Wed, 10 Nov 2010 17:58:06 +0000 Received: (qmail 19800 invoked from network); 10 Nov 2010 17:58:04 -0000 Received: from unknown (HELO tp.orcam.me.uk) (macro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Nov 2010 17:58:04 -0000 Date: Wed, 10 Nov 2010 17:58:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford cc: binutils@sourceware.org Subject: Re: [PATCH][PR ld/10144] MIPS/BFD: Don't make debug section relocs dynamic In-Reply-To: Message-ID: References: <87wrqj30mu.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-11/txt/msg00187.txt.bz2 On Wed, 10 Nov 2010, Richard Sandiford wrote: > > OK, will try to fix that this weekend. I still think dc.a is the > > right thing for the test, but see below. > > So, I looked at it this weekend, and I longer think dc.a is the right > thing for the test. It seemed so well suited, but as you point out, > it's based on the ISA address size rather than the ABI or file > format address size, which probably makes it of limited use. Oh well. I agreed with you .dc.a is the right approach and have only been concerned about the correctness of the implementation for MIPS targets or elsewhere. Given your consideration I have just now looked into it as well and it looks to me our MIPS target should simply override TC_ADDRESS_BYTES with its own function that will return 8 for the n64 ABI and the EABI and 4 with all the other ABIs (I reckon o64 assumes 32-bit addresses too, correct?), or the currently selected ISA-implied address size if no ABI has been selected, such as with the ECOFF targets -- we have that logic implemented elsewhere already, so the return value of function should reduce to an expression along the lines of (4 << HAVE_64BIT_ADDRESSES). The existence of the macro itself suggests this is something that was intended for some platforms to do with the original implementation even though no target makes such an override at the moment. Or do you have a documentation reference for .dc.a that claims it should behave otherwise? Where have these .dc.* pseudo-ops come from anyway? We seem to have collected plenty of various directives providing overlapping functionality with confusingly subtle semantics differences, sigh... And while at it I have noticed the #ifdef TC_ADDRESS_BYTES clauses throughout gas/read.c are rather pointless as the file defines the macro if not already present. Was there a specific reason to have them? If not, then I'll make a patch to remove them. There's also related dead code in gas/config/tc-cr16.c -- not sure what to do about it. > Please go ahead with your original is_elf64 patch, and sorry for the noise. I'd rather fixed .dc.a, sorry. As this is not something critical for 2.21, let me defer it until I'm done with the next (I dare not say "last") iteration of the microMIPS change. Maciej