From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28101 invoked by alias); 15 Oct 2003 16:26:28 -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 28080 invoked from network); 15 Oct 2003 16:26:27 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 15 Oct 2003 16:26:27 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.10/8.12.10) with ESMTP id h9FGQLXh013800; Wed, 15 Oct 2003 11:26:21 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.10/8.12.9) with ESMTP id h9FGQLfa021298; Wed, 15 Oct 2003 11:26:21 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.10/8.12.9/Submit) id h9FGQKBZ021297; Wed, 15 Oct 2003 12:26:20 -0400 Date: Wed, 15 Oct 2003 16:26:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200310151626.h9FGQKBZ021297@duracef.shout.net> To: ezannoni@redhat.com, nickc@redhat.com Subject: Re: [PATCH/RFC] coffread.c: delete param Cc: gdb-patches@sources.redhat.com, rearnsha@arm.com X-SW-Source: 2003-10/txt/msg00492.txt.bz2 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. 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