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.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
