This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Darwin/x86 port (v4 - part 3/4: i386-darwin files)
On Nov 18, 2008, at 9:37 PM, Stan Shebs wrote:
Tristan Gingold wrote:
i386-darwin-tdep.h:
#include <mach/thread_status.h>
This code is a little mixed up, I've been studying the situation but
am not yet sure how to proceed.
The high-order bit is that we can't allow native-only headers to be
included into *-tdep.c files - they must be able to be compiled on
any host. One either precalculates offsets and such and uses, or
defines lookalike structs. The alternative is to move code into a
nat.c file. Given that Apple's GDB isn't correctly set up to be a
cross-debugger either, the easiest path is to migrate code into i386-
darwin-nat.c . When you can compile i386-darwin-tdep.c on a Sparc
Linux host, you're done. :-)
I have migrated all the register stuff to i386-darwin-nat.c which
makes i386-darwin-tdep.c much smaller.
I haven't checked it could be compiled on Sparc Linux (as I don't have
access to such a machine :-) but
looking at the file it should be.
The other thing that is problematic is the large-scale use of macros
like FIRST_GP_REGNUM and friends. This is an unfortunate
consequence of being diverged from FSF for so long - this method of
handling registers was left behind years ago, and has only survived
in Apple's GDB due to inertia. Even though the files are isolated
into being Darwin-specific, it still brings obsolete technique back
into the trunk, confusing developers and increasing support burden.
So since a bunch of code has to be moved anyway, I'd like you to
take the opportunity to look at regsets as used in i386-linux-nat.c
and i386-linux-tdep.c and see how much work it would be to switch
over. I think you'll find it a win, and that a lot of this code will
simply go away.
I have looked at i386-linux-nat.c and amd64-linux-nat.c and switched
over. This makes the code smaller
(and much different from Apple's GDB).
Thank you very much for pointing this issue. Very useful to improve
the code.
Tristan.