Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.
On Tue, Jun 18, 2019 at 5:04 PM Mark Wielaard wrote: > My apologies if you tried to upstream this and I missed it. But I think > the patch below is a more complete fix. If you could test it in your > setup that would be great. Hi Mark, I'm not sure if we tried to upstream the patch. So no worries there. 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 001c 02e0 02e0 02e0 2**0 ALLOC, READONLY ... 40 .debug_loc22f253c9 c8e11f1b 2**0 CONTENTS, READONLY, DEBUGGING 41 .debug_str3176443a ebd372e4 2**0 CONTENTS, READONLY, DEBUGGING 42 .debug_ranges 053cdc00 1d49b71e 2**0 CONTENTS, READONLY, DEBUGGING 43 .debug_macinfo 64fb 2286931e 2**0 CONTENTS, READONLY, DEBUGGING 44 .debug_frame 011dfe98 2286f820 2**3 CONTENTS, READONLY, DEBUGGING 45 .gdb_index24d27f19 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.
Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.
On Tue, Jul 2, 2019 at 4:15 PM Mark Wielaard wrote: > I'll try to create a testcase to replicate the issue to see if I can > debug where the offset value gets truncated. Sounds good to me. > Or do you happen to have the 5.4 GB binary named "chrome" create before > splitting still around somewhere where I could download it? I still have the file here. I'll send you a link in a separate email.
Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.
On Wed, Jul 3, 2019 at 7:53 AM Mark Wielaard wrote: > Thanks for the file, it is indeed pretty big :) > But I am not able to replicate the issue with elfutils from git trunk. > commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0 > > And both the produced chrome_elfutil_test.stripped and > chrome_elfutil_test.debug files seem valid ELF files. I figured out the problem on my side. The strip binary dynamically linked to /usr/lib/x86_64-linux-gnu/libelf.so.1 and friends. Once I set LD_LIBRARY_PATH, I got the expected output. > But you might not be using the upstream build system, and you might use > different flags to call it. So, two questions. How did you build your > eu-strip binary? And how do you invoke it? I'm building at the same commit on 64-bit Linux: git clone git://sourceware.org/git/elfutils.git cd elfutils autoreconf -i -f ./configure --enable-maintainer-mode make make check cp ./src/strip /path/to/chrome/src/buildtools/third_party/eu-strip/bin/eu-strip Then I did the build on the Chromium side, which essentially runs: strip -o chrome.stripped -f chrome.debug chrome
Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.
On Wed, Jul 3, 2019 at 8:34 AM Mark Wielaard wrote: > Great. Thanks for testing on a real world binary. > There aren't actually that many out there this big! > Please do let me know if you still see issues (or discover others). You are welcome. Thank you for fixing this issue in elfutils. We will probably rebuild our copy of eu-strip from upstream at some point and stop carrying our own patch. Hopefully there won't be any issues.
