Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.

[Mark Wielaard <mark at klomp dot org>]

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