From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3346 invoked by alias); 24 Jan 2002 01:10:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3271 invoked from network); 24 Jan 2002 01:09:55 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 24 Jan 2002 01:09:55 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g0O196n20826; Wed, 23 Jan 2002 20:09:07 -0500 Date: Wed, 23 Jan 2002 17:10:00 -0000 From: Daniel Berlin To: Andrew Cagney cc: Jim Blandy , Petr Sorfa , Daniel Jacobowitz , Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2? In-Reply-To: <3C4F5722.5040508@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-01/txt/msg00278.txt.bz2 On Wed, 23 Jan 2002, Andrew Cagney wrote: > > Another approach occurred to me just now that I wish I had thought of > >> when Daniel B.'s patch first appeared. If the core of GDB could > >> define a structure of functions (resembling `struct cp_abi_ops', > >> `struct target_ops', etc.) that allowed a debug reader to provide its > >> own set of functions for finding variables, describing their locations > >> in English, and everything else we do with `enum address_class' now, > >> then that would make it easy and clean to use straight Dwarf 2 > >> location expressions, without any translation into an allegedly > >> "neutral" representation, and without contaminating the core of GDB. > > > > > > I think i mentioned this a few times as the cleanest way to also be able > > to get rid of psymtabs for dwarf2, and use .debug_aranges/pubnames/etc. > > It would let you make stabs use psymtabs internally, and make dwarf2 less > > memory intensive and faster to load. > > > > http://sources.redhat.com/ml/gdb-patches/2001-03/msg00568.html No, that's doing it in variables, which is also the wrong place. It's a property of the debug format, not of the variable. Location expressions can also apply to types, etc, You shouldn't have to call "compute location dynamically" on a variable, ever. There should be one way to get a location for a variable, it should just tell you the right answer, given the necessary info. In reality, we should be asking the debug reader (or something above it that interfaces into the debug reader) where the heck it is. Adding a compute_dynamic_location would make dynamic locations a special case. In reality, if you want to do it on variables (which, as i've explained, is also the wrong place to keep this info), have a location function pointer, which gets set by the debug reader or whatever, to a function that can tell you where it is. Right now we just keep adding possible location types, to try to match them up with what debug info can provide us, and shoehorn debug readers to fit into them. This is silly. We should have a debug info manager or something (this is not a job for the symtab, the symtab is used to tell you scopes/types/properties of symbols, not debug info), that given a symbol and the frame you want to evaluate it in, the address. The debug info manager should also handle other things that we currently build structures for and let the symtab code manage, like psymtabs, reading things in, etc. The symbol table could effectively be viewed as a cache of some set of debug info. If it's not in the symbol table currently, we should ask the debug info manager, which would read in/do whatever is necessary to find the symbol. The same way a virtual memory subsystem just asks for the page at a certain address, and lets the underlying backing method handle getting it for you. Right now we are effectively trying to transfer knowledge that the debug info reader has to other parts of gdb when we read the debug info in, so that later it can try to figure out what the debug info reader really meant. GDB shouldn't give a darn about how the debug info stores, or specifies evaluation of, locations of things. We never care about the actual type of location, except to know how to evaluate it. We map 128 things into 4, then try to determine which of the 128 we really meant by looking at it from different angles, lighting conditions, and the phase of the moon. debug info readers know everything about how locations should be read and evaluated for their debug format. That's their job. It would actually remove and simplify a significant amount of code to just ask them directly (or, through some slightly higher level interface, like a debug info manager), and we'd get all the benefits of that debug format, too. --Dan