[PATCH 2/2] Remove dwarf2_cu::language
Tom de Vries
Thu Jun 10 22:35:04 GMT 2021
On 6/9/21 10:26 PM, Tom Tromey wrote:
> Simon> It's not totally clear to me why it's better to go this route, eliminate
> Simon> dwarf2_cu::language and keep dwarf2_per_cu_data::lang. Because I find
> Simon> it a bit hard to follow that a dwarf2_per_cu_data is initialized by a
> Simon> dwarf2_cu being constructed.
> I didn't give it much thought TBH - I was using dwarf2_per_cu_data::lang
> in my series, and I assumed that this was there for some other important
> reason. However, I see that this member was added in commit 589902954d
> ("[gdb] Skip imports of c++ CUs"), and from what I can tell, it should
> be fine to switch that code to using dwarf2_cu::language instead.
> Simon> So here, instead of referring to per_cu->lang, we could perhaps look up
> Simon> to see if a dwarf2_cu exists for `per_cu`, and lookup the language
> Simon> there? The downside would be if a dwarf2_cu has existed but was then
> Simon> freed, then we won't see the language. Whereas by storing the language
> Simon> in dwarf2_per_cu_data::lang, it will persist even if the dwarf2_cu gets
> Simon> freed.
> Yeah, I arrived at this same conclusion...
> 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.
It's about whether the language has global namespace or not.
In c++, it has, so, take an example CU A, and a CU B, each with two
Now if CU A doesn't import CU B, the global namespace has four entries.
And if CU A does import CU B, the global namespace still has four
entries. So, it's safe to ignore the import because semantically it
doesn't make a difference.
But with C, there's no global namespace so each CU declares its own
Now if CU A doesn't import CU B, the namespace for CU A has two entries,
and the namespace for CU B has two entries.
And if CU A does import CU B, then the namespace for CU A has four
entries, and the CU B has two entries. It's not safe to ignore the
import because semantically there is a difference.
More information about the Gdb-patches