[Lldb-commits] [lldb] [llvm] Add support for using foreign type units in .debug_names. (PR #87740)

[Greg Clayton via lldb-commits]

clayborg wrote:

> > But we won't want a CU index back if we have a `DW_IDX_type_unit` that is a local type unit. Makes no sense to return a CUOffset from such entries.
> 
> Can you elaborate on that? I believe it doesn't make sense to you, but I just don't see the logic behind it. In particular I don't understand why it makes sense to return the CU offset when the DW_IDX_compile_unit attribute is explicitly specified (cases 2 and 3), but not when the compile unit is referred to implicitly via the lack of the attribute on a single-cu index (case 1)

When we have an entry like:
```
DW_IDX_type_unit(0)
DW_IDX_die_offset(0x32)
```
And type unit at index 0 is a local type unit, then the entry describes a type unit DIE in the .debug_info of the current executable. The current API we have is in `DWARFAcceleratorTable.h` for `DWARFDebugNames::Entry` is:
```
    std::optional<uint64_t> getCUOffset() const override;
    std::optional<uint64_t> getLocalTUOffset() const override;
    std::optional<uint64_t> getForeignTUTypeSignature() const override;
```

So if we have an entry mentioned above where the type unit lives in the local .debug_info section, we should get an invalid value back from a call to `getCUOffset()` if this is a local type unit. And we should get a valid value back from `getLocalTUOffset()`. But it makes no sense to return the first compile unit for a call to `getCUOffset()` for an entry that represents a local type unit because it isn't related to the local type unit. 

Lets say we do allow an entry with a local type unit to return the first CU from the .debug_names only because there is only one CU in the .debug_names table. Soon `lld` will generate a single .debug_names table with multiple CUs. We will get no CU offset back for an entry that contains a local type unit + die offset (no CU specified) when using a combined .debug_names table because it can't rely on there only being one CU in the list, but we will get a valid value back for individual .debug_names tables, which makes the API usage inconsistent between individual tables and combined tables.

Any foreign type units that must be associated with a skeleton compile unit, should have both a `DW_IDX_type_unit` and a `DW_IDX_comp_unit` to make sure we can make this connection between a TU and originating CU.



https://github.com/llvm/llvm-project/pull/87740