From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8213 invoked by alias); 7 Jan 2003 00:26:02 -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 7769 invoked from network); 7 Jan 2003 00:24:44 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 7 Jan 2003 00:24:44 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6D0533D92; Mon, 6 Jan 2003 19:24:35 -0500 (EST) Message-ID: <3E1A1E43.10201@redhat.com> Date: Tue, 07 Jan 2003 00:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets References: <1021223225021.ZM25698@localhost.localdomain> <20021223235639.GA6927@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00246.txt.bz2 > + register_addr_data = >> + register_gdbarch_data (init_register_addr_data, 0); >> + >> gdbarch_register_osabi (bfd_arch_mips, 0, GDB_OSABI_LINUX, >> mips_linux_init_abi); >> add_core_fns (®set_core_fns); > > > Blech. So, the way _I_ would have done this would have been to put > this in the tdep structure. In fact I have several patches which add > similar methods to the tdep structure, for signal handling. Of course, > this is not compatible with the way Andrew asked to leave the tdep > struct in mips-tdep.c. This is OK for now, but hopefully we can get > rid of it eventually. We could multi-arch register_addr (is that > appropriate? It's a native-only function, isn't it?) to do that. > Using the gdbarch data mechanism is a good idea - it keeps that architecture dependency local to that file. It definitly doesn't belong in the tdep structure since nothing, other than this file, needs it. Hmm, should the actual code live in mips-linux-nat.c though? enjoy, Andrew