This is an archive of the discontinued LLVM Phabricator instance.

[dwarf2yaml] Change the return type of dumping functions to Error.
AbandonedPublic

Authored by Higuoxing on Aug 7 2020, 12:48 AM.

Details

Summary

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.

Diff Detail

Event Timeline

Higuoxing created this revision.Aug 7 2020, 12:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 7 2020, 12:48 AM
Higuoxing requested review of this revision.Aug 7 2020, 12:48 AM
grimar accepted this revision.Aug 7 2020, 1:33 AM

LGTM

This revision is now accepted and ready to land.Aug 7 2020, 1:33 AM

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?

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.

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 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");
}

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?

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?

This comment was removed by Higuoxing.

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?

Yes, I think so.

Higuoxing closed this revision.Aug 10 2020, 6:59 PM
Higuoxing reopened this revision.
This revision is now accepted and ready to land.Aug 10 2020, 6:59 PM
Higuoxing abandoned this revision.Aug 10 2020, 6:59 PM

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?

Yes, I think so.

Sorry, I've missed the question for me yesterday. This resolution looks fine to me either.