This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Per-type architecture (Re: [10/15] Basic value access routines)


On Mon, Jun 22, 2009 at 10:32:03PM +0200, Ulrich Weigand wrote:
> As to the first point, upon further investigation, it does seem
> feasible to ensure every type is related to an architecture, and
> this does in fact significantly simplify the rest of the patches.
> 
> Dan, one of the reasons you brought up to keep architecture-independent
> types -back when I first started attempting to eliminate then- was the
> target-descriptions infrastructure.  This currently builds up GDB type
> structures while parsing the XML file, long before we know the actual
> target gdbarch to use.
> 
> However, it seems to me it is relatively straightforward to delay
> creation of GDB types until we're in tdesc_register_type, where we
> know the target gdbarch.  This simply requires that while parsing
> the XML file, we store the type details into temporary data structures
> just like we do with all the other information read from XML.
> 
> The following patch does so, using a new "tdesc_type" structure to
> hold type information from XML files.  Does this look reasonable?

I think you're simplifying the wrong thing - it probably simplifies
your patches to remove the global architecture a lot, but I think it
makes the rest of GDB more complicated in exchange.  Why should types
have an associated architecture, in and of themselves?

The only reason I currently know of is the way GDB numbers bitfields.
So while I really do think this is an ugly change, I won't object; I'm
carrying a pretty hideous patch that builds types as big-endian during
parsing and then renumbers bitfield positions if we need a
little-endian copy of the type.

Maybe we can take a similar approach here.  Instead of inventing a new
ad-hoc representation of types, use types, but make a copy with the
right architecture when they're accessed.  WDYT?

If you like the idea, please let me know before trying it.  I'm
merging HEAD into a tree which contains the necessary type walking
routines this afternoon, so I can show you what I mean and save us
both some work.

(You'll probably notice there's nothing about bitfields in that file
now; this is a local patch that we've been meaning to do one last
thing to before submitting it...)

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]