Deprecate the Debug Info API

[emesare]

The debug info API was created to allow formats such as DWARF and PDB to add information to a given Binary View, such as function symbols and types. Much of the design was centered around a new set of objects seperate from the "live" objects that exist within the context of a Binary View, this allows bulk ingestion of functions and other things that would have (at the time) possibly resulted in unneeded analysis.

While this API does work currently, it is unnecessary after the addition of module level workflows. The removal of the debug info API is a step towards simplifying the API surface area, meaning that enhancements to the module level pipeline will be available to these providers (i.e. DWARF, PDB and IDB).

Another benefit to moving the providers over to module level workflow's is the flexibility offered. No longer would you have to model your debug info into the debug info api, you will be given the Binary View as it is, allowing you to do things previously unavailable such as creation of sections and segments.

For other examples of things the Debug info API does not model:

• Add support to debug info for comments #4474
• DebugInfo needs support for bare Symbols #3906

Before we deprecate the Debug Info API we must move the IDB, DWARF and PDB plugins away from the debug info api and use the workflow API.

Another discussion to be had is the application of a provenance system, however that is really a separate discussion that does not need to be tied to this IMO.

[emesare]

Another benefit is the creation of tags for warnings and other things that would have previously been a log warn. I think we should audit the usage of log warns in the debug info providers specifically to see if we could move them to using tags instead as that provides a much nicer experience for users looking to identify possible problems with our ingestion of DWARF and PDB.

[emesare]

For the person who removes the debug info API in the core, there is a usage of it in pointer sweep that I think is historical, will need to verify the ramifications of removing that before we can continue.

[ElykDeer]

I think you might be right, for the wrong reasons.

this allows bulk ingestion of functions and other things that would have (at the time) possibly resulted in unneeded analysis

This is not the point of DebugInfo; otherwise it would've been done as an analysis pass when it was originally implemented; the promise at the time was that DebugInfo would be integrated into the core analysis. As far as I'm currently aware, we still do all the core analysis "that could have been short-cut" and usually the debug info wins based on confidence. What was intended was for, before doing an analysis activity, query to see if the debug info already has that ground truth and then skip that processing entirely.

My biggest concern is that this would force our debug info providers to write workflows that should replace several current analysis activities that are not currently overridable.

One current example, courtesy of @negasora:

loading local vars for registers does not work right now since we can't inform mlil about that when debug info is applied

At that point in MLIL's analysis/generation, analysis should just be able to fetch that information from debug info rather than trying to deduce it itself from LLIL.

See further discussion about this from May 1, 2025 tech debt meeting, may be better to resolve with: #6742