[all-commits] [llvm/llvm-project] 02c718: llvm-objcopy: fix section size truncation/extensio...

[David Blaikie via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 02c718301b305dff87aa4b204b7b3e6fc647999d
      https://github.com/llvm/llvm-project/commit/02c718301b305dff87aa4b204b7b3e6fc647999d
  Author: David Blaikie <dblaikie at gmail.com>
  Date:   2021-06-12 (Sat, 12 Jun 2021)

  Changed paths:
    M llvm/tools/llvm-objcopy/ELF/Object.cpp

  Log Message:
  -----------
  llvm-objcopy: fix section size truncation/extension when dumping sections

Since this only comes up with inputs containing sections at least 4GB
large (I guess I could use a bzero section or something, so the input
file doesn't have to be 4GB, but even then the output file would have to
be 4GB, right?) I've skipped testing this. If there's a nice way to test
this without needing 4GB inputs or output files.

The subtlety here is demonstrated by this code:

struct t { operator uint64_t(); };
static_assert(std::is_same_v<int, decltype(std::declval<bool>() ? 0 : std::declval<t>())>);
static_assert(std::is_same_v<uint64_t, decltype(std::declval<bool>() ? 0 : std::declval<uint64_t>())>);

Because of this difference, the original source code was getting an int
type (truncating the actual size) and then extending it again, resulting
in bogus values (I haven't thought through this hard enough to explain
why the resulting value was 0xffff... - sign extension, possible UB, but
in any case it's the wrong answer - in this particular case I was
looking at that resulted in a size so large that we couldn't open a file
large enough to write to and ended up with a rather vague:

error: 'file_name.o': Invalid argument