From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15135 invoked by alias); 25 Oct 2004 22:03: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 15048 invoked from network); 25 Oct 2004 22:02:57 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 25 Oct 2004 22:02:57 -0000 Received: (qmail 12944 invoked from network); 25 Oct 2004 22:02:56 -0000 Received: from localhost (HELO digraph.polyomino.org.uk) (joseph@127.0.0.1) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 25 Oct 2004 22:02:56 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.42) id 1CMCvW-0003Ei-Eu; Mon, 25 Oct 2004 22:02:54 +0000 Date: Mon, 25 Oct 2004 22:03:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Mark Kettenis cc: gdb-patches@sources.redhat.com Subject: Re: Patch to support AMD64 Solaris 10 In-Reply-To: <200410251955.i9PJtCIA031297@elgar.sibelius.xs4all.nl> Message-ID: References: <200410251955.i9PJtCIA031297@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-10/txt/msg00417.txt.bz2 On Mon, 25 Oct 2004, Mark Kettenis wrote: > The configuration is based on the existing IA32 Solaris support. > > Fair enough, although it's not necessarily the best example. It's essentially a subset of the required configuration (as the 64-bit debugger needs to support debugging 32-bit processes), so seemed the most relevant example to follow even if not the best example for an entirely new port. > This sounds pretty much like the situation for Solaris SPARC. I think > the way this is solved in sparc-sol2-tdep.c is pretty elegant, but I You mean sparc-sol2-nat.c? And splitting i386v4-nat.c (which itself defines the {supply,fill}_{g,fp}regset functions) into one part which defines them as i386v4_* and one with the wrapper functions under those names, or duplicating the definitions? I'm not sure quite what the rationale is here for working by defining magic function names in the first place; the internals manual is silent on the matter of these interfaces. (And as regards DEPRECATED_*, where the internals manual mentions them at all it is silent about the deprecation, its rationale and the proper form of replacement - especially if you want to work just like port X (i386-pc-solaris2.9 etc.) except for necessary changes and without the risk of breaking the port to earlier versions.) > Comparison with Solaris SPARC makes me believe that using > gregset_t/fpregset_t in amd64-sol2-nat.c isn't right and that you > should use prgregset_t/prfpregset_t instead. They seem to be defined to the same thing; and i386v4-nat.c (as used for earlier Solaris IA32 versions) is using the gregset_t and fpregset_t. > Again, for consistency with Solaris SPARC, could you name the makefile > fragments sol2-64.m[th] instead of sol64.m[th]? The IA32 Solaris fragments are named i386sol2.m[th], which might suggest i386sol2-64.m[th]. The IA32/AMD64 GNU/Linux fragments are named linux.m[ht] and linux64.m[ht]. Is there a general naming convention in use? > You're not listed in the GDB MAINTAINERS file, so we'll have to check > out the paperwork first before I can approve any of this. This work is under the blanket CodeSourcery company assignment. -- Joseph S. Myers joseph@codesourcery.com