From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-15249-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 24133 invoked by alias); 21 Aug 2003 23:30:37 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 24110 invoked from network); 21 Aug 2003 23:30:35 -0000
Received: from unknown (HELO concert.shout.net) (204.253.184.25)
  by sources.redhat.com with SMTP; 21 Aug 2003 23:30:35 -0000
Received: from duracef.shout.net (duracef.shout.net [204.253.184.12])
	by concert.shout.net (8.12.9/8.12.9) with ESMTP id h7LNUTWn027650;
	Thu, 21 Aug 2003 18:30:29 -0500
Received: from duracef.shout.net (localhost [127.0.0.1])
	by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h7LNUTHK001162;
	Thu, 21 Aug 2003 18:30:29 -0500
Received: (from mec@localhost)
	by duracef.shout.net (8.12.9/8.12.9/Submit) id h7LNUSua001161;
	Thu, 21 Aug 2003 19:30:28 -0400
Date: Thu, 21 Aug 2003 23:30:00 -0000
From: Michael Elizabeth Chastain <mec@shout.net>
Message-Id: <200308212330.h7LNUSua001161@duracef.shout.net>
To: ac131313@redhat.com
Subject: Re: msym->info is wack
Cc: gdb@sources.redhat.com
X-SW-Source: 2003-08/txt/msg00248.txt.bz2

Hi Andrew,

mec> === ARM-TDEP.C, M68HC11-TDEP.C, MIPS-TDEP.C, SH-TDEP.C
mec> 
mec> These *-tdep.c files use msym->info as a place to store flag bits.
mec> So, first, they are converting 'void *' to 'long' and back again.

ac> Begs the question, is the field needed -> can bfd provide the info directly?

I don't know.

My point of view is "incremental improvement from status quo".  From
that point of view, changing "set flag bit in void *" to "set flag bit
in minsym->tdep_flags" is an improvement.  It makes it easier, not
harder, to change the tdep code later, if desired.

ac> If Arm sets that top bit, dbxread.c would discover a very large size.
ac> 
ac> Guess that never happens.

True.  The code in dbxread.c is conditional on
SOFUN_ADDRESS_MAYBE_MISSING.  That macro is defined in:

  config/i386/tm-i386sol2.h
  config/i386/tm-linux.h
  powerpc/tm-linux.h
  powerpc/tm-ppc-eabi.h
  sparc/tm-sun4sol2.h

And the flag bits are in:

  arm-tdep.c
  m68hc11-tdep.c
  mips-tdep.c
  sh-tdep.c

So there is no actual overlap at this time.  But it's really disgusting!

Michael C