Fix Issue 22251: Omit DW_AT_type for noreturn variables in DWARF #22302

Adityazzzzz · 2025-12-24T09:51:52Z

What this PR does / why we need it: This PR fixes a DWARF debug info corruption issue when compiling variables or parameters of type noreturn.

Previously, the compiler treated noreturn types (which have a type index of 0) like normal types. It generated a DWARF abbreviation containing DW_AT_type and wrote a 0 value for it. However, tools like objdump interpret a type index of 0 as invalid or missing context in this specific scenario, causing them to lose synchronization with the DWARF stream and report corruption errors like: objdump: Warning: Unable to find entry for abbreviation [number]

The Fix: I modified dwarf_outsym in backend/dwarfdbginf.d to handle noreturn types specially:

Definitions: Created a new abbreviation suffix (formal_var_abbrev_suffix_notype) that explicitly omits the DW_AT_type attribute.
Logic: Updated the abbreviation generation logic for Globals, Parameters, and Local Variables. If the type index is 0 (noreturn), it now uses the "Type-less" abbreviation.
Writing: Updated the value-writing loop to skip writing the 4-byte type index when tidx == 0, ensuring the binary data matches the new abbreviation structure.

Verification: Using the reproduction case from the issue:

module repro;
noreturn global_var;
void test(noreturn param) {
    noreturn local_var;
}

Before: objdump --dwarf=info reported: Warning: Unable to find entry for abbreviation... and displayed corrupted tags.
After: objdump output is clean. noreturn variables appear correctly without a DW_AT_type field:

<2><e0>: Abbrev Number: 6 (DW_TAG_formal_parameter)
    <e1>    DW_AT_name        : param
    <eb>    DW_AT_artificial  : 0
    ...

Ref: #22251

dlang-bot · 2025-12-24T09:51:57Z

Thanks for your pull request and interest in making D better, @Adityazzzzz! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
I have provided a detailed rationale explaining my changes
New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

In preparation for migrating from Bugzilla to GitHub Issues, the issue reference syntax has changed. Please add the word "Bugzilla" to issue references. For example, Fix Bugzilla Issue 12345 or Fix Bugzilla 12345.(Reminder: the edit needs to be done in the Git commit message, not the GitHub pull request.)