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
- From: Andrew Cagney <cagney at gnu dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gdb-patches at gcc dot gnu dot org
- Date: Mon, 25 Oct 2004 15:38:10 -0400
- Subject: Re: Patch to support AMD64 Solaris 10
- References: <Pine.LNX.4.61.0410251739090.3442@digraph.polyomino.org.uk>
Joseph S. Myers wrote:
This patch adds initial support for Solaris 10 on AMD64. The test results
(debugging both 64-bit and 32-bit binaries) are fairly similar to those
for unmodified GDB (built as 32-bit and debugging 32-bit binaries), though
as the prerelease operating system isn't yet fully reliable running the
GDB testsuite it's difficult to get full testsuite results for comparison.
The configuration is based on the existing IA32 Solaris support.
Sigh, this is unfortunatly adding a further use of a deprecated
mechanism (DEPRECATED_TM_FILE) and a non strictly multi-arch port. I
assume it is largely for solib?
What about instead modifying things so that solib.c is always included
and have it locally handle the legacy #ifdef SOLIB_ADD et.al. case?
A limitation of this patch is that GDB needs to be built as a 64-bit
binary (configured with CC="gcc -m64": 32-bit compilation is the default
for this system) to work on AMD64 Solaris; GDB built as a 32-bit binary
doesn't work with this patch on AMD64 Solaris 10. The problem is that
there is a single target triplet and so a single GDB configuration, but
64-bit GDB should be using the functions in amd64-sol2-nat.c added by this
patch while 32-bit GDB (which in any case could only debug 32-bit
binaries, but the operating system does support plain x86 systems as well
as AMD64 ones, so such a GDB is desirable) should be using the functions
in i386v4-nat.c. Any comments on the best approach for having the single
configuration cleanly support being built as both 32-bit and 64-bit?
The 64-bit PPC GNU/Linux developers have the same problem.
It's really a top-level configure / config.guess issue so best rasied
there (gcc@?, config@?). By the time things get to GDB it's too late -
trying to switch to 'cc -m64' after the fact would leave us with BFD
built 'cc -m32' but with GDB built 'cc -m64'. Outch!
Andrew
PS: Suggest looking at inf-child and inf-ptrace. The use of nm-*.h and
macros to implement native configurations is also falling from favour.