From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6099 invoked by alias); 6 Mar 2002 19:02:54 -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 5919 invoked from network); 6 Mar 2002 19:02:35 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 6 Mar 2002 19:02:35 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA26774; Wed, 6 Mar 2002 11:02:32 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g26J2CV23632; Wed, 6 Mar 2002 12:02:12 -0700 Date: Wed, 06 Mar 2002 11:02:00 -0000 From: Kevin Buettner Message-Id: <1020306190212.ZM23631@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [RFA] Re: x86-64-tdep.h cleanup" (Mar 6, 1:26pm) References: <3C84EAA8.2000900@suse.cz> <3C8647D7.40302@suse.cz> <1020306173521.ZM23202@localhost.localdomain> <3C865F64.1040302@cygnus.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Andrew Cagney , Kevin Buettner Subject: Re: [RFA] Re: x86-64-tdep.h cleanup Cc: Andreas Schwab , Michal Ludvig , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-03/txt/msg00078.txt.bz2 On Mar 6, 1:26pm, Andrew Cagney wrote: > >> Michal Ludvig writes: > >> > >> |> Andreas Schwab wrote: > >> |> > I think the registration of the Linux specific gdbarch functions should be > >> |> > moved to x86-64-linux-tdep.c. > >> |> > |> It seems reasonable. Perhaps I can do it like in the attachment? > >> > >> No, x86-64-tdep.c should not have _any_ reference to > >> x86-64-linux-tdep.c. The former must be usable without the latter. > > > > > > How is that possible though? I've studied this problem for other > > targets and have (up to now, anyway) concluded that the main tdep.c > > file is going to need to know about the (OS or ABI) variants in some > > fashion. > > I think AndreasS is correct. x86-64-tdep.c only contains ISA and ABI > stuff while x86-64-linux.c contains GNU/Linux specific OS functions. > > Two problems are tripping up the theory. First is that gdbarch doesn't > currently groak this arangement - x86-64-linux-tdep is derived (correct > O-O word?) from x86-64-tdep. I'm not sure I agree with this characterization. As I see it, the x86-64-linux-tdep.c functions could just as easily have gone in the main tdep.c file, but it is/was cleaner to put them in their own file. > The second problem is that gdbarch doesn't > handle the concept of OS variants within an ISA/ABI. Well, maybe not directly, but it is certainly possible use a gdbarch_tdep struct to describe certain features of the OS in question. I use this sort of mechanism on IA-64 to distinguish between AIX and Linux. The OS-specific IA-64 tdep files deal with the same kinds of issues that x86-64-linux-tdep.c is meant to handle. (See the first sixty lines or so of ia64_gdbarch_init().) > Up until now people have side stepped the issue by retaining macro > definitions in config/*/tm-linux.h. I'm personally ok with this - it > retains the status quo and at least manages to retain the separation. Yuck. I don't mind the status quo for targets that haven't completely converted over to being multiarched yet. I don't think that we should encourage a new target to do this though. Kevin