Patch to support AMD64 Solaris 10

Joseph S. Myers
Mon Oct 25 22:03:00 GMT 2004

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 

> 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

More information about the Gdb-patches mailing list