From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32088 invoked by alias); 22 Apr 2009 18:45:01 -0000 Received: (qmail 31960 invoked by uid 22791); 22 Apr 2009 18:44:59 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Apr 2009 18:44:51 +0000 Received: (qmail 6482 invoked from network); 22 Apr 2009 18:44:47 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Apr 2009 18:44:47 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PATCH/Obvious] Fix error in last ARI fix for gnu-nat.h Date: Wed, 22 Apr 2009 18:45:00 -0000 User-Agent: KMail/1.9.10 Cc: "Pierre Muller" References: <000601c9bf26$50f53740$f2dfa5c0$@u-strasbg.fr> <002f01c9c274$10a69fc0$31f3df40$@u-strasbg.fr> In-Reply-To: <002f01c9c274$10a69fc0$31f3df40$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904221944.40713.pedro@codesourcery.com> 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: 2009-04/txt/msg00603.txt.bz2 On Tuesday 21 April 2009 12:26:50, Pierre Muller wrote: > I missed to add a continuation line in the proc_debug macro in gnu-nat.h > > Committed as obvious fix. > > I discovered this while looking at the > THREAD_STATE_* macros (listed in ARI). > > These macros are all defined only once in > config/i386/nm-i386gnu.h > and used only in gnu-nat.c source > unconditionally. This probably means that gnu hurd can only > be compiled for i386 processor anyhow... Right, but the way the code is layed out, it should be easy to add support for other processors, in case the Hurd is ported (I'm not sure what archs the Hurd runs on). > Which in turn, means that we could probably move the stuff > from gnu-nat.c to i386gnu-nat.c I'm not exactly sure what you're proposing here. It looks like you'd have to move pieces of generic gnu/Hurd code over to i386gnu-nat.c as well. Keep in mind that macros afecting the native target only in nm.h files aren't a big a deal. GDB can't be compiled for more than one native target anyway. > I can send a patch for this, but > I will not be able to test compilation, > as this would require access to gnu HURD. I can do that for you, no problem. I've got a debian/Hurd vmware image here. If you want to set one up yourself, it's easy --- you'll find prebuilt debian/Hurd vmware images on the web ready to go. Being debian, it doesn't feel *that* much different. -- Pedro Alves