This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Patch to support AMD64 Solaris 10
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