This is the mail archive of the
mailing list for the GDB project.
Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Daniel Berlin <dan at dberlin dot org>
- Cc: Jim Blandy <jimb at cygnus dot com>, Petr Sorfa <petrs at caldera dot com>,Daniel Jacobowitz <drow at mvista dot com>, gdb at sources dot redhat dot com
- Date: Wed, 23 Jan 2002 19:36:50 -0500
- Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- References: <Pine.LNX.firstname.lastname@example.org>
> 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.