On 6/11/21 5:00 PM, Tom Tromey wrote:
>>> But actually, I wonder whether that code even needs a language check.
>>> My thought is that an import of a DW_UT_compile / DW_TAG_compile_unit 
CU
>>> can always be skipped on the grounds that the CU is being scanned
>>> separately anyway.
> 
> Tom> It's about whether the language has global namespace or not.
> 
> Tom> In c++, it has, so, take an example CU A, and a CU B, each with two
> Tom> function entries.
> 
> Tom> Now if CU A doesn't import CU B, the global namespace has four entries.
> Tom> And if CU A does import CU B, the global namespace still has four
> Tom> entries.  So, it's safe to ignore the import because semantically it
> Tom> doesn't make a difference.
> 
> Tom> But with C, there's no global namespace so each CU declares its own
> Tom> namespace.
> 
> I don't think that's the case, though.  In C a function may have
> external or static linkage, and in effect the external linkage is a
> global namespace.
> 

OK, perhaps not the best example then.  Then substitute type for
function in the story above.  [ FWIW, I have these notions from reading
dwarf standard appendix E, where explicitly this distinction is made
between c and c++ and whether import is necessary or not. So perhaps
you'll get a better explanation there. ]

> Tom> Now if CU A doesn't import CU B, the namespace for CU A has two entries,
> Tom> and the namespace for CU B has two entries.
> Tom> And if CU A does import CU B, then the namespace for CU A has four
> Tom> entries, and the CU B has two entries.  It's not safe to ignore the
> Tom> import because semantically there is a difference.
> 
> What sort of test case would this affect?

I've written a dwarf assembly test-case.

Thanks,
- Tom