DWARFException: Unsupported unitType 3, DW_UT_partial

[infinitesteps]

Describe the bug Loading external debug file for ./usr/bin/ls from Debian Bookworm (x86_64) results in:

INFO  DWARF External Debug File: found: file:///tmp/debug/dfff3239aa7c3b16a71e6b2e3b6e4009dab998.debug (ExternalDebugFileSectionProvider)  
WARN  ELF Dynamic table appears to have been stripped from binary (ElfHeader)  
ERROR Error during DWARFAnalyzer import:  (DWARFAnalyzer) ghidra.app.util.bin.format.dwarf.DWARFException: Unsupported unitType 3, DW_UT_partial
	at ghidra.app.util.bin.format.dwarf.DWARFUnitHeader.read(DWARFUnitHeader.java:76)
	at ghidra.app.util.bin.format.dwarf.DWARFProgram.bootstrapCompilationUnits(DWARFProgram.java:319)
	at ghidra.app.util.bin.format.dwarf.DWARFProgram.init(DWARFProgram.java:290)
	at ghidra.app.plugin.core.analysis.DWARFAnalyzer.added(DWARFAnalyzer.java:101)
	at ghidra.app.plugin.core.analysis.AnalysisScheduler.runAnalyzer(AnalysisScheduler.java:186)
	at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:37)
	at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:24)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:660)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:760)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:639)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:604)
	at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:55)
	at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:33)
	at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:103)
	at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:351)
	at java.base/java.lang.Thread.run(Thread.java:833)

To Reproduce Steps to reproduce the behavior:

1. Import ls (don't analyze)
2. From "Edit" menu set the DWARF debug directory to location for .debug file
3. Run auto analysis
4. See error

Attachments If applicable, please attach any files that caused problems or log files generated by the software.

• bug.zip

Environment (please complete the following information):

• OS: macOS 12.6.5
• Java Version: 18.0.1.1
• Ghidra Version: 11.1.2
• Ghidra Origin: Official GitHub distro

[dev747368]

We don't support this set of DWARF features yet.

This binary not only has an external debug file (dfff3239aa7c3b16a71e6b2e3b6e4009dab998.debug), but it has another debug file for that debug file (yo dawg, I heard you like debug files...), specified in the .gnu_debugaltlink (/usr/lib/debug/.dwz/x86_64-linux-gnu/coreutils.debug).

For now we'll probably wait to see if this configuration is common enough to warrant the effort.

[infinitesteps]

May I recommend failing a bit more gracefully. It'd be nice if it at least snagged the symbols before it aborts.

[dev747368]

I agree the error displayed could be better. I'll add that as an issue to be fixed.

Re: at least snag the symbols... the level of effort for this is probably similar to supporting the entire feature set.

[infinitesteps]

Re: at least snag the symbols... the level of effort for this is probably similar to supporting the entire feature set.

In my experience the symbols are in the .symtab and not in the DWARF sections so it can be parsed without messing with any DWARF parsing.

[Zer0Risk]

I have the exact same problem, i was trying to do this for the debian openssh-server with the openssh-server-dbgsym debug symbols. Is there a workaround ?

Any help would be appreciated.

[dev747368]

I have the exact same problem, i was trying to do this for the debian openssh-server with the openssh-server-dbgsym debug symbols. Is there a workaround ?

No, the issue has not been addressed yet.