From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26520 invoked by alias); 19 Oct 2009 20:34:45 -0000 Received: (qmail 26511 invoked by uid 22791); 19 Oct 2009 20:34:44 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.208.78.105) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 20:34:39 +0000 Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n9JKY3Kd060834; Mon, 19 Oct 2009 13:34:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n9JKY3Mx060833; Mon, 19 Oct 2009 13:34:03 -0700 (PDT) (envelope-from sgk) Date: Mon, 19 Oct 2009 20:34:00 -0000 From: Steve Kargl To: Joel Brobecker Cc: S?rgio Durigan J?nior , gdb-patches@sourceware.org Subject: Re: [PATCH] Fix building gdb-7.0 on x86_64-*-freebsd Message-ID: <20091019203403.GA50042@troutmask.apl.washington.edu> References: <20091012215518.GA45050@troutmask.apl.washington.edu> <20091016232238.GV5288@adacore.com> <20091017001631.GA60006@troutmask.apl.washington.edu> <200910170205.58841.sergiodj@linux.vnet.ibm.com> <20091019195307.GC5282@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091019195307.GC5282@adacore.com> User-Agent: Mutt/1.4.2.3i 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-10/txt/msg00455.txt.bz2 On Mon, Oct 19, 2009 at 09:53:07PM +0200, Joel Brobecker wrote: > Hi Sergio, > > > Thank you for this patch. I believe you could add a comment explaining what > > this number means (just like you did above). What do you think? > > Just my two cents, as usual :-). > > I just applied the following patch (head only) > > 2009-10-19 Joel Brobecker > > * amd64fbsd-nat.c (amd64fbsd_supply_pcb): Add comment. > > Writing the comment made me think that we may have chosen the wrong > version number, depending on the angle we look at things from: If we > want to always be able to build, then we should have chosen version > 74, since there are a few days where version 74 is missing the field > and yet the GDB code still tries to access it for that versio number. > However, if we're trying to have our code always use these fields > whenver possible, then 75 is the right choice. Although we'll fail > to build for any sources that's in between the moment the fields were > removed and the moment the version was bumped to 75 (a time period > of about a few days), we'll be able use these fields for the rest > of version 74 of the sources. > > Based on the number of days this window is open, I would say that this > situation is highly unlikely, and so we don't really need to worry about > it. > You may be correct that a different version should have been used. OTOH, gdb-6.8 was released on 2008-02-29 and the problematic code is present in 6.8. I haven't seen anyone complain on the FreeBSD mailing lists that they can't build 6.8. In looking at FreeBSD's Port Collection, I find /usr/ports/devel/gdb6. This still uses the gdb 6.6 tarball. In looking at the port, I find troutmask:sgk[228] cd /usr/ports/devel/gdb6 troutmask:sgk[229] more files/patch-gdb-amd64fbsd-nat.c --- gdb/amd64fbsd-nat.c.orig 2005-12-17 17:33:59.000000000 -0500 +++ gdb/amd64fbsd-nat.c 2009-09-10 02:29:33.000000000 -0400 @@ -125,10 +125,12 @@ regcache_raw_supply (regcache, 13, &pcb->pcb_r13); regcache_raw_supply (regcache, 14, &pcb->pcb_r14); regcache_raw_supply (regcache, 15, &pcb->pcb_r15); +#if defined(__FreeBSD_version) && __FreeBSD_version < 800000 regcache_raw_supply (regcache, AMD64_DS_REGNUM, &pcb->pcb_ds); regcache_raw_supply (regcache, AMD64_ES_REGNUM, &pcb->pcb_es); regcache_raw_supply (regcache, AMD64_FS_REGNUM, &pcb->pcb_fs); regcache_raw_supply (regcache, AMD64_GS_REGNUM, &pcb->pcb_gs); +#endif return 1; } Apparently, whoever is responsible for this port never forwarded their patch upstream to the gdb developers. Oh well. -- Steve