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:
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
On 3/25/13 2:32 PM, Mark Hatle wrote:
On 3/25/13 12:45 PM, Phil Blundell wrote:
On Mon, 2013-03-25 at 12:10 -0500, Mark Hatle wrote:
I'm going to look into identifying if the section is a NOBITS and skipping the
whole operation if it is.
That would mean that a change in the size of the .bss w
On 3/25/13 12:45 PM, Phil Blundell wrote:
On Mon, 2013-03-25 at 12:10 -0500, Mark Hatle wrote:
I'm going to look into identifying if the section is a NOBITS and skipping the
whole operation if it is.
That would mean that a change in the size of the .bss wouldn't have any
impact on the hash. M
On Mon, 2013-03-25 at 12:10 -0500, Mark Hatle wrote:
> I'm going to look into identifying if the section is a NOBITS and skipping
> the
> whole operation if it is.
That would mean that a change in the size of the .bss wouldn't have any
impact on the hash. Maybe that's fine for your application
On 3/25/13 12:02 PM, Phil Blundell wrote:
On Mon, 2013-03-25 at 12:19 -0500, Mark Hatle wrote:
+Sections 23 and 24 (.plt and .bss) which are NOBITS have a loaded data address
+of 0, but a size != 0.
That doesn't seem like totally unreasonable behaviour for a NOBITS
section. What were you expe
On Mon, 2013-03-25 at 12:19 -0500, Mark Hatle wrote:
> +Sections 23 and 24 (.plt and .bss) which are NOBITS have a loaded data
> address
> +of 0, but a size != 0.
That doesn't seem like totally unreasonable behaviour for a NOBITS
section. What were you expecting libelf to do in that case?
++
[ YOCTO #4089 ]
On PPC and MIPS, there appears to be a condition that causes
debugedit to segfault. The segfault is related to a call into
the md5hash algorithm, an address of '0', and a size > 0 is passed
causing the access of the address to segv.
This workaround may prove to be the final fix,
