From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5162 invoked by alias); 26 Oct 2004 20:50:08 -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 5080 invoked from network); 26 Oct 2004 20:50:06 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 26 Oct 2004 20:50:06 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i9QKo24k021290; Tue, 26 Oct 2004 22:50:03 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i9QKo2Aj034619; Tue, 26 Oct 2004 22:50:02 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i9QKnrN4034613; Tue, 26 Oct 2004 22:49:53 +0200 (CEST) Date: Tue, 26 Oct 2004 20:50:00 -0000 Message-Id: <200410262049.i9QKnrN4034613@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: joseph@codesourcery.com CC: gdb-patches@sources.redhat.com In-reply-to: (joseph@codesourcery.com) Subject: Re: Patch to support AMD64 Solaris 10 References: <200410251955.i9PJtCIA031297@elgar.sibelius.xs4all.nl> X-SW-Source: 2004-10/txt/msg00448.txt.bz2 Date: Tue, 26 Oct 2004 19:43:59 +0000 (UTC) From: "Joseph S. Myers" On Mon, 25 Oct 2004, Mark Kettenis wrote: > Thanks for your contribution. The code looks pretty good to me, but > here are a few comments. This revised patch tries to take account of those comments. Sorry Joseph, I didn't find the time yet to answer your previous mail yet. I wish I had, because some of the changes you made aren't exactly going into the direction I'd want them to. > The configuration is based on the existing IA32 Solaris support. > > Fair enough, although it's not necessarily the best example. The configuration remains based on that one. > 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 > may be biased ;-). The defined(__arch64__) should be dropped though, > since there is no need to support Linux and IA-32/AMD64. For > consistency with SPARC I'd suggest nameing the file i386-sol2-nat.c. It is now following sparc-sol2-nat.c - for that purpose I split i386v4-nat.c into two files, one defining the functions under different names so they can be used in this way and one defining the existing functions as wrappers for those names. The splitting of the file doesn't make me happy. It'd be better if the Solaris code didn't attempt to use i386v4-nat.c at all, but that means some other changes are needed. Big difference between SPARC and AMD64 on one side and i386 on the other side is that the layout of the prfpregset is defined in the -tdep.c file instead of the -nat.c file. That's what I need to do for i386 too. Please give me a few days to set that right first. Why did you use #ifdef __x86_64__ in i386-sol2-nat.c. It's not unlikely that compilers will get that wrong. Please do this in a similar way to SPARC Solaris and use #if defined (PR_MODEL_NATIVE) && (PR_MODEL_NATIVE == PR_MODEL_LP64) (unless that doesn't work of course). > 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. I haven't made any changes in this area; i386v4-nat.c / i386v4-regset.c, now used from this file, use gregset_t/fpregset_t themselves. The Solaris-specific files should defenitely use prgregset_t/prfpgregset_t. It's the officially published API. > Again, for consistency with Solaris SPARC, could you name the makefile > fragments sol2-64.m[th] instead of sol64.m[th]? Now named i386sol2-65.m[th] given the existing naming of the IA32 Solaris fragments. The names of the IA32 Solaris fragments is historic. We've been moving to stripping the architecture from the name for quite some time now; it's already encoded in the name of the directory. So please use the names I suggested. Mark