llvm-objcopy: fix section size truncation/extension when dumping sections
authorDavid Blaikie <dblaikie@gmail.com>
Sun, 13 Jun 2021 01:54:08 +0000 (18:54 -0700)
committerDavid Blaikie <dblaikie@gmail.com>
Sun, 13 Jun 2021 02:00:10 +0000 (19:00 -0700)
commit02c718301b305dff87aa4b204b7b3e6fc647999d
treeb30a9bb69ff0a14439cb2d841e5dd84b23bcc092
parent9eb2f723c24523194b833779d20b027bf89a4f55
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
llvm/tools/llvm-objcopy/ELF/Object.cpp