[coreboot] lar or lzma problems on 64-bit (was Weirdness with lzma setting in v3)
Carl-Daniel Hailfinger
c-d.hailfinger.devel.2006 at gmx.net
Tue Feb 12 00:40:19 CET 2008
On 11.02.2008 23:54, Myles Watson wrote:
> Lar looks pretty portable to 64-bit to me.
>
> I think it would be nice if it worked on both platforms. Maybe this will
> help someone familiar with the code:
>
> segment gets set to zero by lar_compress()
>
> Here's a silly patch that fixes it for me, and hopefully sheds light on the
> real problem. With this patch, bogus gets set to zero instead of segment.
>
> I duplicated it on FC 5 (gcc 4.1.1 binutils-2.16.91) and FC6 (gcc 4.1.2
> binutils-2.18.50).
>
> Maybe function pointers are overkill in terms of complexity for this case of
> no compression, lzma, or nrv2b.
>
> Index: svn/util/lar/stream.c
> ===================================================================
> --- util/lar/stream.c (revision 587)
> +++ util/lar/stream.c (working copy)
> @@ -73,6 +73,7 @@
> int output_elf_segments(struct lar *lar, char *name, char *filebuf,
> int filelen, enum compalgo algo)
> {
> + int bogus = 0;
> int ret;
> Elf32_Phdr *phdr;
> Elf32_Ehdr *ehdr;
> @@ -202,6 +203,7 @@
> }
> /* ok, copy it out */
> sprintf(ename, "%s/segment%d", name, segment++);
> + fprintf(stderr, "%s/bogus_segment%d\n", name, bogus++);
> complen = lar_compress(&header[phdr[i].p_offset], size, temp, &thisalgo);
> ret = lar_add_entry(lar, ename, temp, complen, size,
> phdr[i].p_paddr, entry, thisalgo);
>
Good to know. That means we are fighting with stack corruption. Try
ProPolice.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
More information about the coreboot
mailing list