Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@gnu.org>
To: joseph@codesourcery.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: Patch to support AMD64 Solaris 10
Date: Tue, 26 Oct 2004 20:50:00 -0000	[thread overview]
Message-ID: <200410262049.i9QKnrN4034613@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <Pine.LNX.4.61.0410261939530.15184@digraph.polyomino.org.uk> (joseph@codesourcery.com)

   Date: Tue, 26 Oct 2004 19:43:59 +0000 (UTC)
   From: "Joseph S. Myers" <joseph@codesourcery.com>

   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


  reply	other threads:[~2004-10-26 20:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-25 17:48 Joseph S. Myers
2004-10-25 19:39 ` Andrew Cagney
2004-10-25 19:55 ` Mark Kettenis
2004-10-25 22:03   ` Joseph S. Myers
2004-10-26 19:44   ` Joseph S. Myers
2004-10-26 20:50     ` Mark Kettenis [this message]
2004-10-30 19:57       ` Mark Kettenis
2004-10-30 20:01         ` Joseph S. Myers
2004-11-01 16:43 ` Andrew Cagney
2004-11-01 20:08   ` Joseph S. Myers
2004-11-01 20:34     ` Mark Kettenis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200410262049.i9QKnrN4034613@elgar.sibelius.xs4all.nl \
    --to=kettenis@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox