From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6133419782778291053==" MIME-Version: 1.0 From: Mark Wielaard To: elfutils-devel@lists.fedorahosted.org Subject: Re: [PATCH 1/2] unstrip: Don't try to use unstripped .symtab with stripped .strtab Date: Mon, 24 Oct 2016 13:09:34 +0200 Message-ID: <1477307374.4244.3.camel@redhat.com> In-Reply-To: 1477243556-32858-1-git-send-email-cernekee@chromium.org --===============6133419782778291053== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sun, 2016-10-23 at 10:25 -0700, Kevin Cernekee wrote: > Prematurely matching up the stripped and unstripped .strtab sections > in the "Match each debuginfo" loop can lead to a case where sec->outscn > gets populated for the stripped .strtab, which we normally want to > ignore. This causes the .strtab override in the "Make sure each main > file section" loop to be skipped, so the code winds up using indices > from the unstripped .symtab to look up strings in the stripped .strtab. > This returns incorrect strings for a little while, and then fails > catastrophically when it tries to read past the end of the (smaller) > stripped file's .strtab section: > = > eu-unstrip: invalid string offset in symbol [1589] > = > Fix this by adding logic to the "Match each debuginfo" loop to > treat the unstripped .strtab, .shstrtab, and .symtab sections > essentially the same way. Looks good. Thanks for the analysis and the fix. Applied to git master. > The new logic will break if the .strtab section shows up earlier than > the .symtab section. We will assume this never happens in practice. grin. This screams for someone to show up with such a file tomorrow :) But in practice this indeed doesn't happen because all tools create the sections in order. If someone does create such a file with the sections reversed we'll have to add another pass over the section headers. > Signed-off-by: Kevin Cernekee Thanks, Mark --===============6133419782778291053==--