This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj/libObject] - Introduce a custom warning handler for `ELFFile<ELFT>` methods.
ClosedPublic

Authored by grimar on Jul 31 2019, 7:32 AM.

Details

Summary

Currently, we have a code duplication in llvm-readobj which was introduced in D63266.
The duplication was introduced to allow llvm-readobj to dump the partially
broken object. Methods in ELFFile<ELFT> perform a strict validation of the inputs,
what is itself good, but not for dumper tools, that might want to dump the information,
even if some pieces are broken/unexpected.

This patch introduces a warning handler which can be passed to ELFFile<ELFT> methods
and can allow skipping the non-critical errors when needed/possible.

For demonstration, I removed the duplication from llvm-readobj and implemented a warning using
the new custom warning handler. It also deduplicates the strings printed, making the output less verbose.

Diff Detail

Event Timeline

grimar created this revision.Jul 31 2019, 7:32 AM

Thanks for this! I think it's a good approach, and reminds me of the approach I took in the DWARFDebugLine parser code.

include/llvm/Object/ELF.h
101

what -> which

104

a error -> an error

test/tools/llvm-readobj/elf-invalid-shstrndx.test
11 ↗(On Diff #212579)

It makes me sad that we've lost the file name here. Can we do anything about it, by using an error function that prepends the file name?

tools/llvm-readobj/ELFDumper.cpp
353

as a warnings -> as warnings

399

Should Warnings be private? Also set -> unordered_set.

grimar marked an inline comment as done.Jul 31 2019, 11:31 PM
grimar added inline comments.
test/tools/llvm-readobj/elf-invalid-shstrndx.test
11 ↗(On Diff #212579)

Yes, I also came to conclusion before going to sleep yesterday, that keeping the file name is very important here.
I think if we dump an archive then absence of the file name in the error message might "deduplicate" them when dumping file A
and prevent showing the same errors for the file B. I though that we either can reset the deduplication string set before starting dumping the new file or ensure we included the file name. And the last one seems to be more handy way.

I think I could just include the file name in the new warnings handler. I'll try.

grimar marked 6 inline comments as done.Aug 1 2019, 12:25 AM
grimar added inline comments.
test/tools/llvm-readobj/elf-invalid-shstrndx.test
11 ↗(On Diff #212579)

I think I could just include the file name in the new warnings handler. I'll try.

Ah, I was thinking/talking about the "warning" case in the test case below. Here something different is needed. Anyways I'll take a look.

grimar updated this revision to Diff 212750.Aug 1 2019, 1:43 AM
grimar marked an inline comment as done.
  • Addressed review comments.
  • Included a file name to the errors and warnings produced.
grimar added inline comments.Aug 1 2019, 1:44 AM
tools/llvm-readobj/ELFDumper.cpp
399

I made it private. Making set to be unordered_set was a good idea,
but I can't do that now, when I have a set of pairs.
(It just doesn't compile, the problem is that (taken from stackoverflow):
"std::unordered_set is using std::hash template to compute hashes for its entries and there is no std::hash specialization for pairs.")
So I had to use set, it does not seem to be critical here.

grimar updated this revision to Diff 212757.Aug 1 2019, 2:13 AM
  • Fix a missing test.
  • A cosmetic change.

Is there a test showing that we a) emit a warning only once per input, and b) multiple times, for multiple inputs (both archive members and when listing multiple objects on the command-line)?

tools/llvm-readobj/ELFDumper.cpp
399

You could always implement std::hash for pairs, but I agree that it's not important.

tools/llvm-readobj/llvm-readobj.h
42

depricated -> deprecated

Do you plan to remove this function soon? I don't see why you shouldn't (apart from time to write it...!)

What about the ErrorOr version? Should that be updated too?

grimar marked an inline comment as done.EditedAug 6 2019, 3:19 AM

Is there a test showing that we a) emit a warning only once per input, and b) multiple times, for multiple inputs (both archive members and when listing multiple objects on the command-line)?

We have a), it is elf-wrong-shstrtab-type.test, but I do not think we have b) (mostly because I thought it could be a separate patch testing the warnings reported + changing all warnings we have at once),
but I can add a simple initial test for b) here, NP.

tools/llvm-readobj/llvm-readobj.h
42

Do you plan to remove this function soon? I don't see why you shouldn't (apart from time to write it...!)

I'd be happy, so yes, I'd do that.

What about the ErrorOr version? Should that be updated too?

May be. (I just did not look deep yet about which functions should be eliminated and which cant't be).
I'll probably add a comment.

grimar updated this revision to Diff 213854.Aug 7 2019, 5:01 AM
grimar marked 3 inline comments as done.
  • Addressed review comments, simplified a bit.
tools/llvm-readobj/ELFDumper.cpp
399

I found there was no reason to store the file name here, because a new dumper object actually is
created for each input object. So I made it to be unordered_set just like you suggested initially.

tools/llvm-readobj/llvm-readobj.h
42

What about the ErrorOr version? Should that be updated too?

May be. (I just did not look deep yet about which functions should be eliminated and which cant't be).
I'll probably add a comment.

So I think it should be updated, but not in this patch. I can't just add a comment about deprication,
because we do not have a version with StringRef Input yet. (And it is not needed for this patch).

jhenderson added inline comments.Aug 7 2019, 5:39 AM
test/tools/llvm-readobj/elf-wrong-shstrtab-type.test
4

I'd rephrase:

Check we report only one warning for the issue for each input object.

18

a one -> one

27–29

Do we really need these lines for this and the following test cases? We already show that we can dump the section as well as warn above.

52

in -> on

grimar marked an inline comment as done.Aug 7 2019, 5:48 AM
grimar added inline comments.
test/tools/llvm-readobj/elf-wrong-shstrtab-type.test
27–29

I tried to show how we dump archives with warnings. A test case below only check the messages reported,
but here I left the full output. I think this might be worth testing. It checks that the custom warning handler
reports messages in time, for example.

I am OK to remove it if you feel it is excessive here though.

jhenderson added inline comments.Aug 7 2019, 6:24 AM
test/tools/llvm-readobj/elf-wrong-shstrtab-type.test
27–29

I think it's excessive here. The timing is shown above.

grimar updated this revision to Diff 213881.Aug 7 2019, 7:45 AM
grimar marked 3 inline comments as done.
  • Addressed review comments.
This revision is now accepted and ready to land.Aug 7 2019, 8:11 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 8 2019, 12:18 AM