From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============3243029370846491466=="
MIME-Version: 1.0
From: Thilo Schulz <thilo@tjps.eu>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH] Fix section corruption bug
Date: Sat, 14 Jun 2014 03:23:29 +0200
Message-ID: <201406140323.29523.thilo@tjps.eu>
In-Reply-To: 1402576252.3940.95.camel@bordewijk.wildebeest.org

--===============3243029370846491466==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Thursday 12 June 2014 14:30:52 Mark Wielaard wrote:
> Thanks. It think that shows the second bug you describe.

First bug. My testcase first uses elf_strptr() to get the strings for the =

symbols, and that func internally calls elf_rawdata() thus triggering the f=
irst =

bug described.

> Still scratching my head a little how to resolve both issues properly.

Hmm.. I didn't do any debugging on the second bug reported, but it seems to=
 me =

that once a section was marked dirty, outputting to a new elf causes it to =

only consider data explicitly added to the lib internal memory representati=
on =

of the elf.
It _did_ write out the data I added via elf_newdata(), and entered the =

appropriate offsets into the header file, but completely omitted copying of=
 the =

original data.

These issues can all be worked around with by explicitly calling =

elf_getdata().

Still, I'm a bit baffled that a bug like this could exist for so long in ..=
 well =

I guess these are kind of core developer utils, right?
Or maybe I'm doing some really sick stuff noone else dreamt up yet ;)

-- =

Best regards,
Thilo Schulz

--===============3243029370846491466==--