public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [PATCH] Fix section corruption bug
Date: Wed, 11 Mar 2015 13:46:12 +0100	[thread overview]
Message-ID: <1426077972.5150.57.camel@bordewijk.wildebeest.org> (raw)
In-Reply-To: 1402576252.3940.95.camel@bordewijk.wildebeest.org

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

On Thu, 2014-06-12 at 14:30 +0200, Mark Wielaard wrote:
> On Tue, 2014-06-10 at 15:31 +0200, Thilo Schulz wrote:
> > > I was wondering whether we want to check scn->rawdata.s directly, or if
> > > we could rely on ELF_F_FILEDATA being set for scn->flags?
> > 
> > Seems reasonable though I don't know the code as well as you do I guess.
> 
> I wish I understood the code very well :) But now that I wrote the
> testcase and you pointed out the second bug, I am not sure of the fix
> anymore. It does seem to fix the first issue, but then you immediately
> hit the second.
> 
> > As a further note: A similar bug, albeit for slightly different reasons, occurs 
> > when adding relocations. Adding a relocation with elf_newdata() then 
> > elf_update() 
> > results in the old data being "forgotten" if there was no elf_getdata() call 
> > before to load that data into memory. The cause is a bit different because in 
> > this case, there was not a call to elf_rawdata() before and this still 
> > happened. I imagine, this might also be a problem for string tables.
> 
> Indeed. The attached testcase shows both issues. Calling elf_getdata()
> and then elf_newdata() works as expected. But elf_newdata drops all
> existing data when elf_rawdata is called before and elf_newdata keeps
> the size, but not the actual content bytes of existing data of a section
> if elf_getdata isn't called before.
> 
> Still scratching my head a little how to resolve both issues properly.

Sorry this took 9 months... But I believe these issues have finally been
resolved in current git elfutils. At least my testcase now works as
expected. Hope it also now works for your code.

Cheers,

Mark

             reply	other threads:[~2015-03-11 12:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-11 12:46 Mark Wielaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-06-14  1:23 Thilo Schulz
2014-06-12 12:30 Mark Wielaard
2014-06-10 13:31 Thilo Schulz
2014-06-10  9:48 Mark Wielaard
2014-06-09 19:05 Thilo Schulz

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=1426077972.5150.57.camel@bordewijk.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.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).