[PATCH] Support compressed debug sections larger than 4 GiB

[Nelson Chu]

Hi Guys,

Sorry for bothering.  I build failed recently by getting following errors,

  CC       compress.lo
/Users/nelsonc/work/binutils-gdb/bfd/compress.c:524:45: error: use of
undeclared identifier 'ULONG_MAX'
  524 |       uLongf dst_len = (uncompressed_size > ULONG_MAX ? ULONG_MAX
      |                                             ^
/Users/nelsonc/work/binutils-gdb/bfd/compress.c:524:57: error: use of
undeclared identifier 'ULONG_MAX'
  524 |       uLongf dst_len = (uncompressed_size > ULONG_MAX ? ULONG_MAX
      |                                                         ^
/Users/nelsonc/work/binutils-gdb/bfd/compress.c:526:42: error: use of
undeclared identifier 'ULONG_MAX'
  526 |       uLong src_len = (compressed_size > ULONG_MAX ? ULONG_MAX
      |                                          ^
/Users/nelsonc/work/binutils-gdb/bfd/compress.c:526:54: error: use of
undeclared identifier 'ULONG_MAX'
  526 |       uLong src_len = (compressed_size > ULONG_MAX ? ULONG_MAX
      |                                                      ^
4 errors generated.
make[4]: *** [compress.lo] Error 1

Unless I added "#inlcude <limit.h>".  Not sure if I miss anything.  I
cannot find the message of commit 738767bc, decompress_contents: fuss over
32-bit long, so I just replied here.

Thanks
Nelson

On Sat, May 31, 2025 at 3:52 PM Alan Modra <amodra@gmail.com> wrote:

> On Sat, May 31, 2025 at 10:52:30AM +0900, Rui Ueyama wrote:
> > z_stream's avail_in and avail_out are defined as "unsigned int", so it
> > cannot decode an entire compressed stream in one pass if the stream is
> > larger than 4 GiB. The simplest solution to this problem is to use zlib's
> > convenient uncompress() function, which handles the details for us.
> >
> > Signed-off-by: Rui Ueyama <rui314@gmail.com>
> > ---
> >  bfd/compress.c | 48 ++++--------------------------------------------
> >  1 file changed, 4 insertions(+), 44 deletions(-)
>
> This looked nice until I ran the testsuite and saw
> FAIL: objdump -W
> FAIL: objdump -Z -s
>
> My guess would be you're ignoring this comment:
>   /* It is possible the section consists of several compressed
>      buffers concatenated together, so we uncompress in a loop.  */
>
> Note: your email program corrupted the patch, wrapping lines and
> changing white space.
>
> --
> Alan Modra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250603/b7e9cdb8/attachment.htm>