Re: [RFA] Darwin/x86 port (v4 - part 3/4: i386-darwin files)

[Tristan Gingold <gingold@adacore.com>]

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.