From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9787 invoked by alias); 17 Mar 2005 18:10:34 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 9135 invoked from network); 17 Mar 2005 18:10:20 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 17 Mar 2005 18:10:20 -0000 Received: (qmail 32463 invoked from network); 17 Mar 2005 18:10:19 -0000 Received: from localhost (HELO ?10.1.1.140?) (julian@127.0.0.1) by mail.codesourcery.com with SMTP; 17 Mar 2005 18:10:19 -0000 Message-ID: <4239C7FC.8030401@codesourcery.com> Date: Thu, 17 Mar 2005 20:58:00 -0000 From: Julian Brown User-Agent: Debian Thunderbird 1.0 (X11/20050116) MIME-Version: 1.0 To: Richard Earnshaw CC: Ian Lance Taylor , Daniel Jacobowitz , binutils@sources.redhat.com Subject: Re: [PATCH] Fix thumb calls via PLT on ARM/SymbianOS (rfc) References: <42383FF3.4080604@codesourcery.com> <1110982992.19581.35.camel@pc960.cambridge.arm.com> <20050316144218.GA27174@nevyn.them.org> <42384770.8030104@codesourcery.com> <1110990497.19581.51.camel@pc960.cambridge.arm.com> In-Reply-To: <1110990497.19581.51.camel@pc960.cambridge.arm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-03/txt/msg00487.txt.bz2 Richard Earnshaw wrote: > On Wed, 2005-03-16 at 16:10, Ian Lance Taylor wrote: > >>Julian Brown writes: >> >> >>>Would it be better to add a --target-arch (or something) flag to >>>binutils at this point? That would tidy up a previous patch of mine, >>>too. I don't know if any other targets have, or need, such an option. >> >>I think the linker should support a command line option to do what >>OUTPUT_ARCH does in a linker script. > > > I'm not convinced, but then I'm not entirely sure what OUTPUT_ARCH > does. > > It appears that OUTPUT_ARCH uses bfd variant names, but the problem is > that in the past this has worked by (ab)using bits in the ELF header > which simply aren't available in the EABI. There's also a potential > disaster in this area of the exploding cross-product: the core > architecture is just one dimension in the matrix. > > >>Perhaps the thing to do would be >>to redefine the -A/--architecture option, which is only used for the >>Intel i960. -A currently affects library search order, which we would >>not want for the new option. However, I doubt that anybody uses the >>i960 any more, and even if they do, they probably don't use the -A >>option. > > > I'd really like to be able to just pass -march through from the > compiler. Anything solution that needs any remapping beyond a common > prefix substitution in a gcc spec file is just a disaster waiting to > happen. I've been working on a new patch, but now I come to think about it I'm unsure what the conclusion of this discussion was, so I may be just heading towards a dead-end. I think my confusion arises from there being two different things being discussed here: the behaviour of the linker (which relocations do what), and the representation of the architecture in the input and output files. As far as I can tell, the ARM EABI build attributes seem to be primarily concerned with the latter, and not so useful for the former. (And besides which, they aren't implemented yet, and I'm probably not the best person to do that.) It seems to be quite easy to alter the behaviour of -A/--architecture to do the same as the linker script OUTPUT_ARCH, then use that information from the output bfd to control the linker's interpretation of R_ARM_THM_CALL. (It also suffices to control the behaviour of R_ARM_V4BX, by seeing if the current arch is armv4. Previous patch here: http://sourceware.org/ml/binutils/2005-01/msg00479.html ) But OUTPUT_ARCH also affects the output file, which isn't necessarily what we want if we're only trying to affect linker behaviour (and indeed, the build attributes are probably better for that). So the choices as I see it are as follows: (1) Add a seperate "-march=xyz -> --foobar=xyz" style passthrough. This unfortunately gives ld and bfd a new and different concept of what an architecture is. (2) Use existing OUTPUT_ARCH machinery with a redefined --architecture option, and: (a) Don't use any automatic architecture passthrough from gcc, or (b) Extend bfd machine table with all the architectures gcc knows about, to enable . (3) Forget this for now, and use my original SymbianOS-specific patch. I'm inclined towards 2a or 3. (e.g. for 2a, use explicit -Wl,--architecture,xyz when necessary). Comments? Julian