From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3126 invoked by alias); 12 Jan 2002 18:01:40 -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 3095 invoked from network); 12 Jan 2002 18:01:37 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 12 Jan 2002 18:01:37 -0000 Received: from telocity.telocity.com (taarna.sfbay.redhat.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with SMTP id KAA05333; Sat, 12 Jan 2002 10:01:24 -0800 (PST) Message-ID: <3C4078F2.52CF@redhat.com> Date: Sat, 12 Jan 2002 10:01:00 -0000 From: Michael Snyder X-Mailer: Mozilla 3.04 (Win95; I) MIME-Version: 1.0 To: Mark Kettenis CC: Nick Clifton , Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: RFA: Multilib support in gdb.asm tests References: <3C3F05DE.8010007@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00329.txt.bz2 Mark Kettenis wrote: > > 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. > It's causing problems on Linux too. I suspect this approach needs to be reconsidered.