From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: gdb-patches@sources.redhat.com Cc: Daniel Berlin Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions Date: Mon, 21 May 2001 14:46:00 -0000 Message-id: References: X-SW-Source: 2001-05/msg00402.html Daniel Berlin writes: > This patch adds a place in the symbol structure to store the dwarf2 > location (an upcoming dwarf2read huge rewrite patch uses it), an > evaluation maachine to findvar.c, and has read_var_value use the dwarf2 > location if it's available. I think this is the wrong approach to the right idea. I think it would be a great idea to give GDB more powerful ways to describe the locations of variables, structure fields, and so on. This would be a clean alternative to including special-purpose, ABI-specific logic in GDB. For example, one of the nice properties of the way GDB's `struct type' represents a structure type in the present code is that it's mostly ABI-independent. Since the debug info spells out the exact position of each structure member, GDB doesn't have to know the ABI's structure layout rules, alignment requirements, and so on. However, if we want to support virtual base classes, it's not clear how to extend that structure appropriately. In the V2 C++ ABI, each object contained pointers to its virtual bases. In the V3 C++ ABI, an object's virtual table provides offsets to its virtual bases. At the moment, our `solution' is to provide ABI-specific code to find your virtual bases. If GDB supported a fully general location expression language, like Dwarf 2 location expressions, then `struct type' could simply provide a location expression to find each member or base class of the object. In most cases, these location expressions would be trivial, but we could easily encode both the V2 and V3 C++ ABI behaviors in this manner. It would then become the compiler's responsibility to describe the ABI it was using. We could take a similar approach to finding virtual functions. That said, I think the core of GDB should be independent of the debugging information format. If GDB does adopt a fully general location expression language, then it should have a self-contained description, which can be designed to suit GDB's needs. Then we can translate Dwarf2 expressions into that form.