From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8150 invoked by alias); 1 Feb 2002 17:27:19 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8092 invoked from network); 1 Feb 2002 17:27:15 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 1 Feb 2002 17:27:15 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id EEADD3E07; Fri, 1 Feb 2002 12:26:58 -0500 (EST) Message-ID: <3C5ACFE2.6030409@cygnus.com> Date: Fri, 01 Feb 2002 09:27:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Richard.Earnshaw@arm.com Cc: gdb@sources.redhat.com Subject: Re: Non-multiarched macros References: <200202011703.RAA16938@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00035.txt.bz2 >> ELF_MAKE_MSYMBOL_SPECIAL -- elfread.c >> >> REGISTER_BYTES_OK >> >> > COFF_MAKE_MSYMBOL_SPECIAL -- coffread.c >> >> REGISTER_BYTES_OK > > > These two are my biggest concern. They are likely to pull object-format > specific information into the tdep file. Is that safe? Can I be sure > that the all the object formats will be available there, regardless of > configuration. Dan answered the technical question. Anyway, it is probably a design flaw (?) and multi-arch conversions ignore flaws in the design. You can grit your teath and do the conversion anyway :-) The rationale is two fold. If people tried to fix every design flaw they found during the conversion process then the conversion process would never be finished. Once everything is converted, it is going to be far easier for someone to go through all targets and test/fix the design problems. enjoy, Andrew