On 10/07/2014 10:29 AM, Jakub Jelinek wrote:
> But isn't there a risk that you will have PLACEHOLDER_EXPRs (likely for Ada
> only) in some trees not constructed by the langhook?
> I mean, DW_OP_push_object_address isn't meaningful in all DWARF contexts,
> in some it is forbidden, in others there is really no object to push, and as
> implemented, you emit DW_OP_push_object_address (which emits the address of
> a context related particular object) for any kind of PLACEHOLDER_EXPR with
> RECORD_TYPE.

Even with GNAT, this is not _supposed_ to happen. However during the 
development (for instance with LTO) I noticed cases where 
PLACEHOLDER_EXPR nodes were incorrectly used. Thanks to current work on 
the early debug info pass, such cases are doomed to disappear, but I 
completely agree with your point, so thank you for raising it. :-)

> Thus, I'd feel safer, even if you decide to use a PLACEHOLDER_EXPR, that
> the translation of that to DW_OP_push_object_address would be done only
> if the PLACEHOLDER_EXPR is equal to some global variable, normally NULL,
> and only changed temporarily while emitting loc for the array descriptor.

This is what the updated (and attached) patch does. Note that upcoming 
patches will enhance loc_list_from_tree (adding another parameter to 
loc_list_from_tree) and make it recurse to generate sub-expressions as 
DWARF procedures. Because of this kind recursion, I added a composite 
argument instead of relying on a global variable (so that "nested" 
contexts can exist at the same time).

> But then IMHO a DEBUG_EXPR_DECL is better.
> [...]
> Also, please verify that with your patch the generated debug info for some
> Fortran arrays is the same.

It's fortunate that you asked this since I wrongly assumed there was the 
corresponding testing in the GDB testsuite. As a matter of fact, support 
for Fortran's variable length arrays in GDB is still a work in progress 
so tests are not commited yet. So I used the Fortran example I could 
find there <http://intel-gdb.github.io/> instead and discovered that my 
patch did break debugging information for Fortran array types.

Fixing it while keeping a PLACEHOLDER_EXPR-based implementation seems a 
too heavy task for my little experience in the Fortran front-end and 
after having a closer look I agree with you: it seems less adapted to 
how things are currently done, there. So I finally leveraged this new 
composite argument to re-introduce the base_decl mechanism. 
DEBUG_EXPR_DECL is back in the Fortran front-end. ;-) Now, the same 
example keeps the same debugging information.

The latest patches bootstrapped well and passed successfully the GCC 
testsuite on x86_64-pc-linux-gnu.

-- 
Pierre-Marie de Rodat