From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19778 invoked by alias); 3 Feb 2003 20:40:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19770 invoked from network); 3 Feb 2003 20:40:23 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by 172.16.49.205 with SMTP; 3 Feb 2003 20:40:23 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h13KVF8A027972; Mon, 3 Feb 2003 15:31:16 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h13KVCui027968; Mon, 3 Feb 2003 15:31:12 -0500 To: David Carlton Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] ALL_OBJFILE_MSYMBOLS References: From: Jim Blandy Date: Mon, 03 Feb 2003 20:40:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00087.txt.bz2 Okay, I've committed this change. (My test run completed with no new failures.) David Carlton writes: > On 31 Jan 2003 15:01:24 -0500, Jim Blandy said: > > > I think I'd prefer the patch below. Could you try it out and see if > > it works as well? > > Yes, it also fixes the bug I'm seeing. > > > This was messier than I had expected. > > Yah. > > > (Which is a great example of one reason C macros suck and Lisp > > macros don't --- in case that's an emotionally charged issue for > > anyone else out there like it is for me. :) ) > > I thought for a while about good responses to this, but I think I'll > just leave it alone for now. :-) > > > But it would be better anyway for an empty minsym table to have a > > single, consistent representation. > > That was my first reaction, too. But while I was thinking about how > to do that, I noticed that ALL_MSYMBOLS already dealt with the > possibility of a NULL entry, so I just went with that out of laziness. > > Like you, trusting the count sounds like a good idea. And, even if > you go with a terminating entry, having it be a fake symbol instead > of, say, a NULL pointer is pretty weird, too. But making either of > those changes sounds like too much (fallible) work for too little > benefit. > > > So here's a patch which simply ensures that every objfile's minsym > > table has a terminating entry, and makes some appropriate accompanying > > changes. The tests are still running, but I haven't noticed any > > regressions yet. > > Seems sensible to me. I didn't do a full testsuite run, but I did > apply it to my branch and try to trigger the bug I'd been seeing > there, and your patch does protect against the bug. > > David Carlton > carlton@math.stanford.edu