From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7784 invoked by alias); 12 Jan 2002 13:47:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7720 invoked from network); 12 Jan 2002 13:47:47 -0000 Received: from unknown (HELO mail.science.uva.nl) (146.50.4.51) by sources.redhat.com with SMTP; 12 Jan 2002 13:47:47 -0000 Received: from soliton.wins.uva.nl [146.50.20.20] by mail.science.uva.nl with ESMTP (sendmail 8.11.6/config 11.24). id g0CDkML23089; Sat, 12 Jan 2002 14:46:22 +0100 (MET) Received: from localhost by soliton.wins.uva.nl (sendmail 8.11.6/config 11.15). id g0CDkSd04574; Sat, 12 Jan 2002 14:46:28 +0100 (MET) X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands X-URL: http://www.science.uva.nl/ To: Nick Clifton Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: RFA: Multilib support in gdb.asm tests References: <3C3F05DE.8010007@cygnus.com> From: Mark Kettenis Date: Sat, 12 Jan 2002 05:47:00 -0000 In-Reply-To: Nick Clifton's message of 11 Jan 2002 17:23:09 +0000 Message-ID: X-Mailer: Gnus v5.5/Emacs 20.2 X-SW-Source: 2002-01/txt/msg00326.txt.bz2 Nick Clifton writes: > How about this alternative wording of the comment: > > # WARNING: Invoking the assembler directly is problematic. > # For targets which support multilibs a compile time switch is used > # to select the appropriate multilibs. This switch may not be same > # as the switch that the compiler will pass on to the assembler. For > # example if big-endian and little-endian multilibs are supported > # the compiler options will probably be -mbig-endian and -mlittle-endian > # but, for historical reasons, the assembler options are probably -EB > # and -EL. > # > # Since these tests are supposed to be able to be run for targets for > # which there is no compiler we cannot just invoke a compiler driver > # program (eg 'gcc') to handle this translation for us. For now we > # just hard code the endian translation and hope that there are no > # others that are needed. I'm a bit puzzled by this comment. These tests already invoke `gcc' for doing the final link. Isn't that a problem too? As an aside, using gcc for the final link is causing problems on FreeBSD too. Mark