This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj] Change errors to warnings for symbol section name dumping
ClosedPublic

Authored by jhenderson on Oct 31 2019, 9:56 AM.

Details

Summary

Also only print each such warning once.

LLVM-style output will now print "<?>" for sections it cannot identify, e.g. because the section index is invalid. GNU output continues to print the raw index. In both cases where the st_shndx value is SHN_XINDEX and the index cannot be looked up in the SHT_SYMTAB_SHNDX section (e.g. because it is missing), the symbol is printed like other symbols with st_shndx >= SHN_LORESERVE.

Depends on D69670.

Diff Detail

Event Timeline

jhenderson created this revision.Oct 31 2019, 9:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 31 2019, 9:56 AM
Herald added a subscriber: seiya. · View Herald Transcript
MaskRay added inline comments.Oct 31 2019, 11:52 PM
llvm/tools/llvm-readobj/ELFDumper.cpp
565

cantFail(WarningHandler(EI.message()), ...);

grimar added inline comments.Nov 1 2019, 2:12 AM
llvm/test/tools/llvm-readobj/elf-section-symbols.test
43

May be regroup to isolate test cases? (they are not very similar, it is easier to think about them as about different tests and hence
read them separatelly. It also might be helpful if we will want to add more cases here not to mix them all).

# RUN: yaml2obj %s -o %t1
# RUN: llvm-readobj %t1 --symbols 2> %t.llvm.err1 | FileCheck %s --check-prefix=LLVM1
# RUN: FileCheck %s --input-file %t.llvm.err1 --check-prefix=WARN1
# RUN: llvm-readelf %t1 --symbols 2> %t.gnu.err1 | FileCheck %s --check-prefix=GNU1
# RUN: FileCheck %s --input-file %t.gnu.err1 --check-prefix=WARN1

# LLVM1: ....

# GNU1:   ...

# WARN1: ...

<YAML1>

# RUN: yaml2obj %s --docnum=2 -o %t2
# RUN: llvm-readobj %t2 --symbols 2> %t.llvm.err2 | FileCheck %s --check-prefix=LLVM2
# RUN: FileCheck %s --input-file %t.llvm.err2 --check-prefix=WARN2
# RUN: llvm-readelf %t2 --symbols 2> %t.gnu.err2 | FileCheck %s --check-prefix=GNU2
# RUN: FileCheck %s --input-file %t.gnu.err2 --check-prefix=WARN2

# LLVM2: ....

# GNU2:   ...

# WARN2: ...

<YAML1>
llvm/test/tools/llvm-readobj/elf-symbol-shndx.test
142–187

The same suggestion about regrouping here.

llvm/tools/llvm-readobj/ELFDumper.cpp
562

Our warnings are always unique. Should it be just reportWarning (it is much more common name for reporting)?

840

I think you need to consumeError() here.

5498

Wrap it into curly bracers too?

jhenderson marked 2 inline comments as done.Nov 1 2019, 3:14 AM
jhenderson added inline comments.
llvm/tools/llvm-readobj/ELFDumper.cpp
562

At the moment, nothing really forces our warnings to be unique. The llvm-readobj.h reportWarning function does not do any uniquifying, so if the same warning could be reported from two different places, it isn't unique. I think one such example where it isn't is getSymbolForReloc. There are others too in the stack size, addrsig and note printing code. Probably we could change all of these to call the new function.

A concern with calling the new function reportWarning is that it could easily clash with the reportWarning in llvm-readobj.h, and people could end up calling the wrong one. I'm not sure of a good way to resolve this, as reportUniqueWarning could be easily missed in the future. What do you think?

840

Yup, sorry! This should probably actually print a warning...

grimar added inline comments.Nov 1 2019, 3:36 AM
llvm/tools/llvm-readobj/ELFDumper.cpp
562

At the moment, nothing really forces our warnings to be unique.

Yeah, I meant ones reported with the use of WarningHandler. I've not realized it is almost never used still.

I'm not sure of a good way to resolve this, as reportUniqueWarning could be easily missed in the future.

So currently we have a global reportWarning(Error Err, StringRef Input) and this new reportUniqueWarning(Error Err).

I am thinking about the following steps:

  1. We can switch all places that use reportWarning(Error Err, StringRef Input) to use reportUniqueWarning(Error Err) where possible/reasonable/easy (sometimes seems it is not that simple atm).

It looks like this might cover most of the places => will make normal for warnings to be unique.

  1. We can rename reportWarning(Error Err, StringRef Input) to reportNonUniqueWarning(Error Err, StringRef Input) to emphasize there is something unusual/wrong with it. It is actually is, right? We probably want to report only unique warnings everywhere or almost everywhere.
  1. And then we can rename reportUniqueWarning to just reportWarning, it will suggest it to be our normal warning reporting API.

How does it sound?

Anyways seems for now it is OK to keep the name of reportUniqueWarning as is, as the problem is a bit more complex as I supposed initially.

jhenderson updated this revision to Diff 227417.Nov 1 2019, 4:20 AM
jhenderson marked 6 inline comments as done.

Address review comments:

  • call WarningHandler inline
  • reflow tests
  • handle unhandled Error

Also added --implicit-check-not=warning to a couple of checks to show that the warnings are uniqued properly.

grimar accepted this revision.Nov 1 2019, 7:45 AM

LGTM.

This revision is now accepted and ready to land.Nov 1 2019, 7:45 AM

Forgot to submit this inline comment.

Also, I discovered I'd missed a couple of yaml2obj tests that were testing for errors instead of warnings. I've fixed these and will commit directly without updating the diff, as they are trivial changes.

llvm/tools/llvm-readobj/ELFDumper.cpp
562

That sounds like a reasonable strategy. At the moment, the majority of usages of reportWarning are in ELFDumper, and I suspect that they can all be migrated over (some are unique due to the code structure so don't necessarily need to be, but I think there is no harm in doing so). We might want to consider a strategy for making it always unique, but that would require larger code changes. In general, I think warnings should be unique. There may be cases where the warnings are warning about the same issue in different parts of an object, and should be reported separately, but really the problem there is the lack of sufficient context to the warning.

This revision was automatically updated to reflect the committed changes.