https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #12) > > Ack, I've managed to reproduce this using a dwarf assembly test-case (PR > > gdb/25796 - "Symbol with inherited DW_AT_const_value not found" @ > > https://sourceware.org/bugzilla/show_bug.cgi?id=25796), and submitted a gdb > > patch for this. > > Note compared to your gdb bug the case above does not have a > reference to 'i' from the "real" DW_TAG_compile_unit. Ah, sorry, I've misread that, thanks for pointing that out. For that case, I think gdb behaves as expected. That is, my mental model is: - a PU represents a dwarf repository - a CU represents a symtab (as well as a dwarf repository) - an import imports dwarf from one dwarf repository into another - an inter-cu ref does not represent an implicit import So, if we have only i declared in a PU, and the PU is not imported, there's no symtab with an 'i', and gdb can't find it. If you want a symtab with an 'i', you have to add a DW_TAG_variable DIE to a CU, with DW_AT_abstract_origin referencing the DIE in the PU (as my dwarf assembly test-case does). > A an extreme dwarf > testcase would probably contain a partial unit with the optimized > out variable and a main unit with just a 'main' and no reference to > the partial unit at all. > In my interpretation as decribed above, that boils down to the same: no symbol 'i' declared in any symtab. > > Note that the problem is specific to gdb's partial symbol tables feature, so > > that problem doesn't occur when using -readnow. > > > > I understand that if I would again add imports this would likely be > > > resolved > > > but at the expense of re-creating the original issue (but just with two > > > instances rather than three)? > > > > Agreed. > > OK. So I understand the DWARF standard doesn't really say how consumers > should work but how do partial vs. full units differ as to "name lookup"? > I've originally placed imports of original units where I instantiated > something from that original unit so to make things "visible" at that > point (as in, all global statics are visible by name lookup). But of > course consumers do not really follow name lookup rules since I > can perfectly well lookup 'i' from 'foo' for > > void foo() {} > int i; > > where it is obviously not visible (but consumers do need to do > something resembling name lookup when interpreting user expressions > written in the source language). I hope I managed to explained above how I see the difference. --- It's perhaps good to follow-up at this point to the discussion related to DW_AT_declaration (see PR94450 comment 5). As mentioned in comment 8, I've created a minimal dwarf assembler variant corresponding to the C test-case (with only var aaa), and I could reproduce the problem. Then by tagging the abstract DIE with DW_AT_declaration, I managed to fix the problem of "info variables" listing the variable twice. But well, the fact that we keep decl in symtabs for gdb comes with a number of known issues (which are tracked here: https://sourceware.org/bugzilla/show_bug.cgi?id=25755). In particular, there's PR24985 - "Cannot print value of global variable because decl in one CU shadows def in other CU", and I was thinking we might run into that for VLAs when we start using DW_AT_declaration. So, I was hoping to avoid those issue by using PUs, but it seems also that comes with its own set of issues in gdb :)
