public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: "Martin Liška" <mliska@suse.cz>
Cc: Fangrui Song <maskray@google.com>, binutils@sourceware.org
Subject: Re: [PATCH] readelf: support zstd compressed debug sections [PR 29640]
Date: Fri, 14 Oct 2022 21:58:41 +1030	[thread overview]
Message-ID: <Y0lH6Ym3G0FBsfxd@squeak.grove.modra.org> (raw)
In-Reply-To: <5eeed442-a153-5805-eae9-44b006506fd1@suse.cz>

So we have a zlib-gabi .debug_info section that increases in size with
zstd, so much so that it's better to leave the section uncompressed.
Things go horribly wrong due to leaving compress_status as
COMPRESS_SECTION_NONE.  The section is read again off disk using the
uncompressed size.  So you get the zlib section again with some
garbage at the end.

Also, if the section is to be left uncompressed, the input
SHF_COMPRESSED flag needs to be reset otherwise it is copied to
output.

I'm not ready to commit this, just thought I'd post the results of a
bit of debugging.

diff --git a/bfd/compress.c b/bfd/compress.c
index 364df14142b..5eef38bd50a 100644
--- a/bfd/compress.c
+++ b/bfd/compress.c
@@ -206,15 +206,15 @@ bfd_compress_section_contents (bfd *abfd, sec_ptr sec)
   if (compressed_size >= uncompressed_size)
     {
       memcpy (buffer, input_buffer, uncompressed_size);
-      sec->compress_status = COMPRESS_SECTION_NONE;
+      elf_section_flags (sec) &= ~SHF_COMPRESSED;
     }
   else
     {
       sec->size = uncompressed_size;
       bfd_update_compression_header (abfd, buffer, sec);
       sec->size = compressed_size;
-      sec->compress_status = COMPRESS_SECTION_DONE;
     }
+  sec->compress_status = COMPRESS_SECTION_DONE;
   sec->contents = buffer;
   free (input_buffer);
   return uncompressed_size;

-- 
Alan Modra
Australia Development Lab, IBM

  reply	other threads:[~2022-10-14 11:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-01  6:20 Fangrui Song
2022-10-06  2:20 ` Fangrui Song
2022-10-20  8:04   ` Martin Liška
2022-10-20  8:05   ` Martin Liška
2022-10-13 11:38 ` Martin Liška
2022-10-14  3:35   ` Fangrui Song
2022-10-14  7:47     ` Martin Liška
2022-10-14  8:26       ` Martin Liška
2022-10-14 11:28         ` Alan Modra [this message]
2022-10-14 12:09           ` Alan Modra
2022-10-16  4:42             ` Alan Modra
2022-10-16 20:46               ` Fangrui Song
2022-10-21  9:16                 ` Alan Modra
2022-10-17  7:52               ` Martin Liška

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y0lH6Ym3G0FBsfxd@squeak.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=maskray@google.com \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).