Re: [coreboot] lar or lzma problems on 64-bit (was Weirdness with lzma setting in v3)

[Carl-Daniel Hailfinger]

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