public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Alexey Tourbin <alexey.tourbin@gmail.com>
To: elfutils-devel@sourceware.org
Subject: [PATCH] dwz.c: special-case SHT_NOBITS sections
Date: Tue, 06 Feb 2018 11:51:00 -0000	[thread overview]
Message-ID: <20180206115046.GA3233@celery.localdomain> (raw)

When eu-strip is used to create separate .debug files, and is invoked
with the --strip-debug option instead of --strip-all, the .symtab
section is kept in a.out, but eu-strip also creates an empty .symtab
section in a.out.debug with type NOBITS, but with the original size.

 Section Headers:
   [Nr] Name     Type    Address          Off    Size   ES Flg Lk Inf Al
-  [33] .symtab  SYMTAB  0000000000000000 002b10 0006a8 18     34  55  8
-  [34] .strtab  STRTAB  0000000000000000 0031b8 0001d1 00      0   0  1
+  [33] .symtab  NOBITS  0000000000000000 002110 0006a8 18     34  55  8
+  [34] .strtab  NOBITS  0000000000000000 002110 0001d1 00      0   0  1

This makes dwz fail with the following message:
dwz: Section offsets in a.out.debug not monotonically increasing

This is because dwz does not take into account the possibility of
SHT_NOBITS sections, and always increments sh_offset by sh_size.

So one way to fix this would be to disable writing of empty sections
in eu-strip.  However, this seems to be the expected behavior, which
also matches the behavior of the strip program from binutils (regarding
its "--only-keep-debug" option, the manpage reads: "the section headers
of the stripped sections are preserved, including their sizes, but the
contents of the section are discarded.")

Thus the next best thing is to actually teach dwz about NOBITS sections
(this is a subtle reference to the fact that dwz doesn't have a mailing
list or a dedicated sourceware.org/bugzilla component, so dealing with
dwz might be a bit harder in this respect.)

After the patch was first drafted, I came across a similar patch
by Richard Guenther <rguenther@suse>.  He goes much further in that
he tries to handle truly unordered sections by qsorting them first.
Richard explains such binaries can be created by the kernel linker
script.  As I only need to use dwz with userland programs - moreover,
I want to ensure that those programs meet certain criteria - I decided
to proceed with this much simpler patch of my own that does not permit
truly unordered sections.  More specifically, I only need to apply
dwz to separate .debug files, and I expect it to keep their sections in
the same order as in the original executable or shared object.  There
are other differences: in Richard's patch, NOBITS sections are simply
ignored, and their offsets are not updated, - in other words, they are
left technically unordered in the output.

Here's a simple test case reproducible on Fedora 27 x86-64.  The patch
covers a larger set of cases by also handling allocatable NOBITS
sections as well as non-allocatable.

echo 'int main(){}' >test.c
gcc -g -O2 test.c
eu-strip --strip-debug -f a.out.debug
dwz a.out.debug
---
 dwz.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/dwz.c b/dwz.c
index b3b779d..01bc553 100644
--- a/dwz.c
+++ b/dwz.c
@@ -10141,7 +10141,8 @@ write_dso (DSO *dso, const char *file, struct stat *st)
 	  for (j = 1; j < dso->ehdr.e_shnum; ++j)
 	    if (dso->shdr[j].sh_offset < min_shoff && !last_shoff)
 	      continue;
-	    else if ((dso->shdr[j].sh_flags & SHF_ALLOC) != 0)
+	    else if ((dso->shdr[j].sh_flags & SHF_ALLOC) != 0
+		     && dso->shdr[j].sh_type != SHT_NOBITS)
 	      {
 		error (0, 0, "Allocatable section in %s after non-allocatable "
 			     "ones", dso->filename);
@@ -10157,7 +10158,9 @@ write_dso (DSO *dso, const char *file, struct stat *st)
 	      {
 		if (k == -1)
 		  k = j;
-		last_shoff = dso->shdr[j].sh_offset + dso->shdr[j].sh_size;
+		last_shoff = dso->shdr[j].sh_offset;
+		if (dso->shdr[j].sh_type != SHT_NOBITS)
+		  last_shoff += dso->shdr[j].sh_size;
 	      }
 	  last_shoff = min_shoff;
 	  for (j = k; j <= dso->ehdr.e_shnum; ++j)
@@ -10181,7 +10184,9 @@ write_dso (DSO *dso, const char *file, struct stat *st)
 		dso->shdr[j].sh_offset
 		  = (last_shoff + dso->shdr[j].sh_addralign - 1)
 		    & ~(dso->shdr[j].sh_addralign - (GElf_Off) 1);
-	      last_shoff = dso->shdr[j].sh_offset + dso->shdr[j].sh_size;
+	      last_shoff = dso->shdr[j].sh_offset;
+	      if (dso->shdr[j].sh_type != SHT_NOBITS)
+		last_shoff += dso->shdr[j].sh_size;
 	      if (addsec != -1 && j == addsec)
 		last_shoff += addsize;
 	    }
-- 
2.10.4

             reply	other threads:[~2018-02-06 11:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-06 11:51 Alexey Tourbin [this message]
2018-02-06 12:57 ` Mark Wielaard

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=20180206115046.GA3233@celery.localdomain \
    --to=alexey.tourbin@gmail.com \
    --cc=elfutils-devel@sourceware.org \
    /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).