This patch changes the return type of dumping functions to Error. This
is useful when the DWARF parser encounters an error, clients can consume
this error and dump the section as a raw content section.
Details
- Reviewers
jhenderson grimar MaskRay
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I like that it makes this makes all the dumpDebug* functions consistent. However, are there going to actually be changes to all of these functions to make the new error handling path useful?
This change is intended to make elf2yaml and macho2yaml share the same logic when dumping DWARF sections. If the parser fails, we are able to dump them as raw content sections.
I think not all of the error handling path are useful. For example, the .debug_str section's parser never fails.
Does this mean we could return void for some functions instead of changing their signatures like you are doing? It seems like that would be the right way round for functions that can never fail.
I think it's acceptable to make the return type to be void. But the dumpDebugSection() function in D85506 should be changed to
static Error dumpDebugSection(StringRef SecName, DWARFContext &DCtx, DWARFYAML::Data &DWARF) { if (SecName == "__debug_abbrev") { dumpDebugAbbrev(DCtx, DWARF); return Error::sucess(); } if (SecName == "__debug_aranges") return dumpDebugARanges(DCtx, DWARF); if (SecName == "__debug_info") { dumpDebugInfo(DCtx, DWARF); return Error::sucess(); } if (SecName == "__debug_line") { dumpDebugLines(DCtx, DWARF); return Error::success(); } if (SecName == "__debug_ranges") return dumpDebugRanges(DCtx, DWARF); if (SecName == "__debug_str") { dumpDebugStrings(DCtx, DWARF); return Error::success(); } return createStringError(errc::not_supported, "dumping " + SecName + " section is not supported"); }
Right, that would be my personal preference. Limiting the scope of where errors need handling by not emitting them earlier than necessary seems beneficial to me. @grimar, any thoughts?
I think your opinion makes more sense. Actually, some of the DWARF dumpers are fallible. We can keep the return type to be void by now and refactor them step by step. Then, this change can be abandoned?
Sorry, I've missed the question for me yesterday. This resolution looks fine to me either.