This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readelf/obj] - Cleanup the code. NFCI.
ClosedPublic

Authored by grimar on Sep 22 2020, 7:07 AM.

Details

Summary

This:

  1. Replaces pointers with references in many places.
  2. Adds few TODOs about fixing possible unhandled errors (in ARMEHABIPrinter.h).
  3. Replaces autos with actual types.
  4. Removes excessive arguments.
  5. Adds const ELFFile<ELFT> &Obj; member to ELFDumper to simplify the code.

Diff Detail

Event Timeline

grimar created this revision.Sep 22 2020, 7:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2020, 7:07 AM
grimar requested review of this revision.Sep 22 2020, 7:07 AM
MaskRay accepted this revision.Sep 22 2020, 9:39 AM

LGTM.

This revision is now accepted and ready to land.Sep 22 2020, 9:39 AM
jhenderson accepted this revision.Sep 23 2020, 1:05 AM

Generally looks fine, barring nits. I wonder whether it might be easier for downstream providers such as my team to merge this patch in if it were in separate commits for each of the major changes, but I don't really mind.

llvm/tools/llvm-readobj/ARMEHABIPrinter.h
435–436

Here and elsewhere.

582

Maybe another auto that could be replaced whilst you're at it?

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

Delete duplicated line.

4966

I wonder whether it might be easier for downstream providers such as my team to merge this patch in if it were in separate commits for each of the major changes, but I don't really mind.

I wanted to start from something smaller, but faced that too many places are related. I hope doing this cleanup in one move will be less painfull way.

grimar marked 4 inline comments as done.Sep 23 2020, 2:45 AM
grimar added inline comments.
llvm/tools/llvm-readobj/ELFDumper.cpp
3941

An issue of rebasing I guess. Thsnks!

4966

getGNUPropertyList returns SmallVector<std::string, 4>. I think it is better to avoid an implicit conversion.
Switching to StringRef might also lead to a behavior change (I don't expect it, but in theory), because operator<< is implemented differently:

raw_ostream &operator<<(StringRef Str) {
  // Inline fast path, particularly for strings with a known length.
  size_t Size = Str.size();

  // Make sure we can use the fast path.
  if (Size > (size_t)(OutBufEnd - OutBufCur))
    return write(Str.data(), Size);

  if (Size) {
    memcpy(OutBufCur, Str.data(), Size);
    OutBufCur += Size;
  }
  return *this;
}
raw_ostream &operator<<(const std::string &Str) {
  // Avoid the fast path, it would only increase code size for a marginal win.
  return write(Str.data(), Str.length());
}

I'd like to keep this patch as NFC.

This revision was automatically updated to reflect the committed changes.
grimar marked 2 inline comments as done.
fhahn added a subscriber: fhahn.Sep 24 2020, 2:55 AM
fhahn added inline comments.
llvm/tools/llvm-readobj/ELFDumper.cpp
5298

Using a reference here is misleading, as Elf_Note will always be copied. With a recent version of Apple clang this change triggers a bunch of warnings throughout the file of the form:

llvm/tools/llvm-readobj/ELFDumper.cpp:5299:28: warning: loop variable 'Note' is always a copy because the range of type 'iterator_range<llvm::object::ELFFile<llvm::object::ELFType<llvm::support::big, true> >::Elf_Note_Iterator>' (aka 'iterator_range<Elf_Note_Iterator_Impl<ELFType<(llvm::support::endianness)0U, true> > >') does not return a reference [-Wrange-loop-analysis]
      for (const Elf_Note &Note : this->Obj.notes(P, Err))
grimar marked an inline comment as done.Sep 24 2020, 3:19 AM
grimar added inline comments.
llvm/tools/llvm-readobj/ELFDumper.cpp
5298