From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30791 invoked by alias); 23 Jan 2002 23:41:52 -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 30749 invoked from network); 23 Jan 2002 23:41:51 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 23 Jan 2002 23:41:51 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id CD2D45E9DE; Wed, 23 Jan 2002 18:43:21 -0500 (EST) To: Petr Sorfa Cc: Daniel Berlin , Daniel Jacobowitz , Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2? References: From: Jim Blandy Date: Wed, 23 Jan 2002 15:41:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-01/txt/msg00273.txt.bz2 Daniel B. submitted patches to allow GDB to handle arbitrary Dwarf 2 location expressions. However, the initial patch simply extended the functions that care about symbol locations (like read_var_value, for example) with another case that evaluated a Dwarf 2 location expression. However, I felt it was important to keep the core of GDB independent of any particular debug representation. Daniel B. was very accommodating, and revised the patch to introduce a new, "neutral" expression representation, and translate Dwarf 2 location expressions into that form. I think I had some concerns about the exact way it had been done, but I don't remember --- in general it was fine. I don't know what happened to the patch, but I don't think it ever got approved. But while I feel pretty good about the "keep GDB's core independent of the debug formats" rule, I felt pretty bad about introducing what amounted to an exact duplicate of the Dwarf 2 location list interpreter, with the constants renamed. Surely that wasn't the right thing. 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. (This would also allow us to move some odd HP-UX-specific stuff like LOC_THREAD_LOCAL_STATIC out of the GDB core and into an HP-specific module.)