This is an archive of the discontinued LLVM Phabricator instance.

Track which modules have debug info variable errors.
ClosedPublic

Authored by clayborg on Sep 22 2022, 5:57 PM.

Details

Summary

Now that we display an error when users try to get variables, but something in the debug info is preventing variables from showing up, track this with a new bool in each module's statistic information named "debugInfoHadVariableErrors".

This patch modifies the code to track when we have variable errors in a module and adds accessors to get/set this value. This value is used in the module statistics and we added a test to verify this value gets set correctly.

Diff Detail

Event Timeline

clayborg created this revision.Sep 22 2022, 5:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2022, 5:57 PM
clayborg requested review of this revision.Sep 22 2022, 5:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2022, 5:57 PM
yinghuitan accepted this revision.Sep 27 2022, 11:55 AM
This revision is now accepted and ready to land.Sep 27 2022, 11:55 AM

Instead of storing a bool, would it make sense to store the error instead and then have the statistics call isFail on it to determine whether there was an issue?

Instead of storing a bool, would it make sense to store the error instead and then have the statistics call isFail on it to determine whether there was an issue?

We would need to store a list of unique error strings if we want to go that route since we might stop N times in M compile units and currently the errors are on the compile unit boundary. We wouldn't want just one string and if we stopped 12 times in a the same function we don't want 12 copies of the same string in the stats. So if we could use a

std::set<std::string> m_var_errors;

I'd be happy to go this route if anyone feels this would be useful. I just want to know when there are errors, but I also would love to have the exact errors to help us track down.

Please chime in everyone!

This revision was automatically updated to reflect the committed changes.

I can do a follow up patch that enumerates the errors in the statistics if needed.