[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

-- 
http://www.hailfinger.org/