From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9740 invoked by alias); 18 Nov 2008 20:38:25 -0000 Received: (qmail 9646 invoked by uid 22791); 18 Nov 2008 20:38:24 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Nov 2008 20:37:44 +0000 Received: from [68.108.142.23] (helo=macbook-2.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1L2XKQ-0006NX-9m; Tue, 18 Nov 2008 15:37:42 -0500 Message-ID: <49232795.90703@earthlink.net> Date: Wed, 19 Nov 2008 01:47:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Tristan Gingold CC: gdb-patches@sourceware.org Subject: Re: [RFA] Darwin/x86 port (v4 - part 3/4: i386-darwin files) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940000b32b5c7852a3ccaaddf1d385f4b80350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00479.txt.bz2 Tristan Gingold wrote: > i386-darwin-tdep.h: > > > #include 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. :-) 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. Stan