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.
>
next prev parent 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.