[all-commits] [llvm/llvm-project] e0fd87: llvm-dwarfdump: Return non-zero on error

[David Blaikie via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: e0fd87cc64d5102f20219b6bad0e337dc4e6b2d2
      https://github.com/llvm/llvm-project/commit/e0fd87cc64d5102f20219b6bad0e337dc4e6b2d2
  Author: David Blaikie <dblaikie at gmail.com>
  Date:   2020-04-09 (Thu, 09 Apr 2020)

  Changed paths:
    M llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
    M llvm/test/DebugInfo/X86/dwarfdump-debug-loclists-error-cases2.s
    M llvm/test/DebugInfo/X86/dwarfdump-rnglists-dwarf64.s
    M llvm/test/DebugInfo/X86/dwarfdump-rnglists.s
    M llvm/test/DebugInfo/X86/dwarfdump-str-offsets-invalid.s
    M llvm/test/DebugInfo/dwarfdump-decompression-corrupt.test
    M llvm/test/DebugInfo/dwarfdump-decompression-error.test
    M llvm/test/tools/llvm-dwarfdump/X86/debug_aranges-error.s
    M llvm/test/tools/llvm-dwarfdump/X86/lookup.s
    M llvm/test/tools/llvm-dwarfdump/elf-broken-reloc-target.yaml
    M llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp

  Log Message:
  -----------
  llvm-dwarfdump: Return non-zero on error

Makes it easier to test "this doesn't produce an error" (& indeed makes
that the implied default so we don't accidentally write tests that have
silent/sneaky errors as well as the positive behavior we're testing for)

Though the support for applying relocations is patchy enough that a
bunch of tests treat lack of relocation application as more of a warning
than an error - so rather than me trying to figure out how to add
support for a bunch of relocation types, let's degrade that to a warning
to match the usage (& indeed, it's sort of more of a tool warning anyway
- it's not that the DWARF is wrong, just that the tool can't fully cope
with it - and it's not like the tool won't dump the DWARF, it just won't
follow/render certain relocations - I guess in the most general case it
might try to render an unrelocated value & instead render something
bogus... but mostly seems to be about interesting relocations used in
eh_frame (& honestly it might be nice if we were lazier about doing this
relocation resolution anyway - if you're not dumping eh_frame, should we
really be erroring about the relocations in it?))