All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Phil Blundell <pb@pbcl.net>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2 RFC] rpm: Add workaround for debugedit-segv
Date: Tue, 26 Mar 2013 07:20:23 -0500	[thread overview]
Message-ID: <51519287.7010404@windriver.com> (raw)
In-Reply-To: <1364294307.25692.146.camel@phil-desktop.brightsign>

On 3/26/13 5:38 AM, Phil Blundell wrote:
> On Mon, 2013-03-25 at 16:47 -0500, Mark Hatle wrote:
>> I've looked at the code some more.  It does checksum the header itself and then
>> if it's got contents, it also adds the contents to the checksum.. That is where
>> the failure appears to be happening:
>>
>>             if (u.shdr.sh_type != SHT_NOBITS)
>>               {
>>                 Elf_Data *d = elf_rawdata (dso->scn[i], NULL);
>>                 if (d == NULL)
>>                   goto bad;
>>                 process (d->d_buf, d->d_size);
>>               }
>>
>> So it's specifically checking for SHT_NOBITS, but it's matching so it falls
>> through and d->d_buf == 0, causing the failure.  I'll keep investigating, but
>> somehow that value (u.shdr.sh_type) is wrong [or at least unexpected!].
>
> Ah.  If a NOBITS section is getting reported as something else then it
> seems that this must clearly be a bug in libelf and ought to be fixed
> there rather than working around it in rpm.  What do you actually get as
> u.shdr.sh_type?

I posted an updated patch last night.  debugedit was re-translating (byte 
swapping) the header elements during the buildid calculations.  This was causing 
the value of sh_type to be in the ELF binaries native endian during the check. 
So big endian binaries failed to match the SHT_NOBITS, thus the problem being 
discovered on PPC and MIPS.

(Fix was to not translate the original values, but instead only translate a 
copy.  I verified the produced buildid was expected, as I now have a better 
understanding of how the buildid is generated.)

--Mark

> p.
>




  reply	other threads:[~2013-03-26 12:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-25 17:19 [PATCH 0/2 RFC] workaround for debugedit segv Mark Hatle
2013-03-25 17:19 ` [PATCH 1/2 RFC] rpm: Add workaround for debugedit-segv Mark Hatle
2013-03-25 17:02   ` Phil Blundell
2013-03-25 17:10     ` Mark Hatle
2013-03-25 17:45       ` Phil Blundell
2013-03-25 19:32         ` Mark Hatle
2013-03-25 21:47           ` Mark Hatle
2013-03-26 10:38             ` Phil Blundell
2013-03-26 12:20               ` Mark Hatle [this message]
2013-03-25 17:19 ` [PATCH 2/2 RFC] package.bbclass: Trigger a bb.error if split/strip fails Mark Hatle
2013-03-25 17:47 ` [PATCH 0/2 RFC] workaround for debugedit segv Richard Purdie

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=51519287.7010404@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=pb@pbcl.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.