From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8403 invoked by alias); 22 Aug 2003 18:16:25 -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 8395 invoked from network); 22 Aug 2003 18:16:24 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 22 Aug 2003 18:16:24 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A557D2B7F; Fri, 22 Aug 2003 14:16:23 -0400 (EDT) Message-ID: <3F465DF7.3080702@redhat.com> Date: Fri, 22 Aug 2003 18:16:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com, jimb@redhat.com, vinschen@redhat.com Subject: Re: [RFC] Supporting alternative ABIs References: <200308221541.h7MFfmQC013143@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00261.txt.bz2 > What a coincidence! I have been looking at the code which > does this on other platforms. There is code to handle > alternate function calling conventions in arm-tdep.c, m68hc11-tdep.c, > mips-tdep.c, and sh-tdep.c. In the case of ARM (Arm vs Thumb), sh (sh vs sh64) and MIPS (MIPS vs MIPS16) the tdep file has effectively encountered two different architecture variants (ISA) folded into a single architecture. For what corinna is looking at, the ABI and not the ISA is being changed. Roughly speeking there is the relationships: ISA N->M ABI e.g., for MIPS, MIPS16 has only one ABI (two?) while MIPS32 and MIPS64 to a certain extend share the -o32 -64 -o64 and -n64 ABIs. The current architecture is flat. Refecting the original design it contains everything. With everything multi-arch (not yet strictly true unfortunatly) a more oo model can probably be developed. All the inferior functioin call stuff moved to a separate object - more like the frame code. Andrew