From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7872 invoked by alias); 4 Jun 2009 00:58:55 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 7846 invoked by uid 22791); 4 Jun 2009 00:58:54 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_05,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Roland McGrath To: Tom Tromey Cc: Project Archer Subject: DW_TAG_imported_unit support Message-Id: <20090604005844.2313DFC3C3@magilla.sf.frob.com> Date: Thu, 04 Jun 2009 00:58:00 -0000 X-SW-Source: 2009-q2/txt/msg00139.txt.bz2 When my DWARF size reduction plan comes along on the producer side, there will be some new format elements and/or extensions that GDB will want to grok so it can use the packaged debuginfo directly in its most compact form. This remains nebulous since we're still a few months away from having any tool to produce any new-style data. But I want to let you plan to be ready for what I think we'll have. I have various ideas for low-level variations/extensions of the format that would be used for the most thoroughly compact way to package debuginfo. Actuals details of those remain quite vague and yet to be fleshed out. Fortunately they are sufficiently coherent in my own mind that I can be pretty sure all that will be the less onerous bits to address in GDB/BFD's DWARF reader code. The key piece of the plan that is not an extension, but a proper part of DWARF 3--just one that we have never used or supported before. That is DW_TAG_imported_unit (section 3.1.2 of DWARF 3). This is a magical "middle-level" DWARF feature that is supposed to tell the reader to graft a physically separate DWARF tree in as a subtree at another given point in the reader's "logical" view of the overall DIE tree rooted in a CU. In this way, common subtrees can be moved off and then shared by many different containing DIEs (often in multiple different CUs). I call it "middle-level" because the tag itself is encoded in the normal format--a DW_TAG_imported_unit node with a single DW_AT_import attribute--but what is specifies is not a "consumer"-level semantic node that the exists in the conceptual DIE tree emitted by the compiler, rather it's a "transparent" DWARF format detail that the consumer should pretend doesn't exist for purposes of its semantic DIE-traversal algorithms. So it needs to be understood by every place that does a DIE tree walk (or just flat enumeration of a given DIE's children). (Ideally this would be consolidated in one "logical tree walker" place, but I imagine the existing code might not all be quite so nicely-structured.) Handling it in a walk is pretty straightforward: you follow the DW_AT_import (which should always be DW_FORM_ref_addr) to another DIE, which is either DW_TAG_compile_unit or DW_TAG_partial_unit. All the children of that DIE appear in the logical tree in place of the DW_TAG_imported_unit child. The other main wrinkle of DW_TAG_imported_unit is the "which CU" issue. The referent DIE is a CU, but logically all the DIEs (its children) you look at belong to the referring CU. For the low-level format pointers, the referent CU is what matters: which line table DW_AT_decl_file refers to, etc. For the stuff about using "the CU" as context for how you understand DIEs at a semantic level, it's the logically-containing (referring) CU that matters: finding the relevant "top of tree" to search what's in scope, etc. So, I didn't really mean to try to cover the whole technical subject. I'm sure there are many more corners we will stumble across, and as I said this work anticipates producer/transformer tools that aren't there yet to drive the need. But now I've put this task on your radar. Thanks, Roland