From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2536 invoked by alias); 15 Oct 2003 16:37:54 -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 2528 invoked from network); 15 Oct 2003 16:37:53 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Oct 2003 16:37:53 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9FGbqM00541 for ; Wed, 15 Oct 2003 12:37:52 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9FGbqr04853 for ; Wed, 15 Oct 2003 12:37:52 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9FGbpwC027564; Wed, 15 Oct 2003 12:37:51 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 86C302C441; Wed, 15 Oct 2003 12:49:13 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16269.31369.339106.180129@localhost.redhat.com> Date: Wed, 15 Oct 2003 16:37:00 -0000 To: Michael Elizabeth Chastain Cc: ezannoni@redhat.com, nickc@redhat.com, gdb-patches@sources.redhat.com, rearnsha@arm.com Subject: Re: [PATCH/RFC] coffread.c: delete param In-Reply-To: <200310151626.h9FGQKBZ021297@duracef.shout.net> References: <200310151626.h9FGQKBZ021297@duracef.shout.net> X-SW-Source: 2003-10/txt/msg00493.txt.bz2 Michael Elizabeth Chastain writes: > Nickc writes: > > Given Andrew's comment in the code, I would be rather wary of this > > patch. Presumably there is some good reason for passing the > > cs->c_sclass field in the (void *) pointer argument slot, or otherwise > > Andrew would not have gone to all that trouble of casting it. > > I figured out some of the history: > > Back in gdb 4.17, arm_pc_is_thumb in arm-tdep.c used this c_sclass > information to determine whether a symbol is a Thumb or Arm function. > gdb 4.18 rewrote arm_pc_is_thumb with a new mechanism based on > COFF_MAKE_MSYMBOL_SPECIAL, which sets a flag bit instead of storing the > sclass and reading it later. That enables other readers besides the > coff reader to mark functions as special (ELF_MAKE_MSYMBOL_SPECIAL > in particular). > > The change from 4.17 to 4.18 added the new COFF_MAKE_MSYMBOL_SPECIAL, > and changed arm-tdep.c to use the new COFF_MAKE_MSYMBOL_SPECIAL, > but did not delete the old dangling c_sclass code. > > Someone with access to the old Cygnus CVS repository might be able > to say more about the exact change some time between 4.17 and 4.18. Did you see my posting with the exact diffs (from 1998) I posted yesterday? http://sources.redhat.com/ml/gdb-patches/2003-10/msg00470.html That explains in detail what happened, which is pretty much how you describe it here. elena > > Andrew C came along a few years later and added a cast just to make > the compiler happy -- just an innocent janitor. > > It's very unlikely that Elena's change will change the behavior of gdb. > This c_sclass info has been dead since 4.18, replaced by > COFF_MAKE_MSYMBOL_SPECIAL. > > It would be nice if someone could build and test arm-coff to verify > this line of reasoning. But, it's also nice to know the history, > which explains why c_sclass is stored, but never read. > > > Does it improve things ? :-) If so, what ? > > It's part of a cleanup for the msymbol.info field. > > There are three different places in gdb which use msymbol.info. > This is one of them. The improvement is that getting rid > of dead code makes it simpler to talk about the other two places. > > Michael C