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
