[PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.
Mark Wielaard
mark@klomp.org
Tue Jul 2 23:15:00 GMT 2019
Hi,
On Tue, 2019-07-02 at 11:40 -0700, Lei Zhang wrote:
> I tested and found some problems. My test procedure is to:
> - Build elfutils at commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0
> - Replace Chromium's buildtools/third_party/eu-strip/bin/eu-strip with
> the newly built strip binary.
> - Do an "official" Chromium build, with the following Chromium GN build config:
>
> is_debug = false
> is_official_build = true
> strip_absolute_paths_from_debug_symbols = true
> use_goma = true
>
> This generates a 5.4 GB binary named "chrome" and then splits it into
> "chrome.debug" and "chrome.stripped" using the strip command. Running
> "objdump -x chrome.debug", I see the following in the "Dynamic
> Section" output:
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .interp 0000001c 00000000000002e0 00000000000002e0 000002e0 2**0
> ALLOC, READONLY
> ...
> 40 .debug_loc 22f253c9 0000000000000000 0000000000000000 c8e11f1b 2**0
> CONTENTS, READONLY, DEBUGGING
> 41 .debug_str 3176443a 0000000000000000 0000000000000000 ebd372e4 2**0
> CONTENTS, READONLY, DEBUGGING
> 42 .debug_ranges 053cdc00 0000000000000000 0000000000000000 1d49b71e 2**0
> CONTENTS, READONLY, DEBUGGING
> 43 .debug_macinfo 000064fb 0000000000000000 0000000000000000 2286931e 2**0
> CONTENTS, READONLY, DEBUGGING
> 44 .debug_frame 011dfe98 0000000000000000 0000000000000000 2286f820 2**3
> CONTENTS, READONLY, DEBUGGING
> 45 .gdb_index 24d27f19 0000000000000000 0000000000000000 23a4f6b8 2**0
> CONTENTS, READONLY, DEBUGGING
>
> Here, section 42 has the wrong file offset. It should be 0x11d49b71e,
> since the file offset and size of section 41 is 0xebd372e4 +
> 0x3176443a. If I restore buildtools/third_party/eu-strip/bin/eu-strip
> back to the original, and rebuild, then that generates the right
> chrome.debug output.
Thanks so much for testing. And sorry it didn't work.
It clearly is a 32bit issue, because the difference between the
expected and actually gotten value is clearly bit 32 being cleared.
I must have missed another 32bit type type or cast, but cannot find it
just by inspecting/reading the code. And I am not seeing it with the
largefile testcase I added. But that might be because it doesn't have
that many sections to begin with (just two large enough to push it over
the 4GB limit).
I'll try to create a testcase to replicate the issue to see if I can
debug where the offset value gets truncated.
Or do you happen to have the 5.4 GB binary named "chrome" create before
splitting still around somewhere where I could download it?
Thanks,
Mark
More information about the Elfutils-devel
mailing list