On Thu, Sep 11, 2014 at 10:18 PM, Gao, Liming <[email protected]> wrote:
> Sergey:
>
>   LzmaDec.c is LZMA code. Have you other solution without modify LZMA code?

Liming, I notice LZMA SDK has not updated since 2011. Our LZMA SDK
base (4.65) is from 2009.

So we don't seem too concerned about merging new SDK versions in, and
if we did, it does not seem like there are going to be new versions
available.

So, maybe it is okay to diverge from the original SDK code a little?

I think we try to avoiding implicit structure copying in EDK II, so
those changes seem to align with that. (Although, I do wonder why it
fails for CLANG, so maybe that should be investigated.)

-Jordan

> From: Sergey Isakov [mailto:[email protected]]
> Sent: Thursday, September 11, 2014 8:33 PM
> To: [email protected]
> Subject: Re: [edk2] LzmaCustomDecompressLib is not working
>
>
>
> CodeModule: IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib
>
>
>
> I resolved the issue. The problem is in structure coping that must be
> replaced by CopyMem
>
> ---
>
> diff -Nurpb -x .svn C/LzmaDec.c C-new/LzmaDec.c
>
> --- C/LzmaDec.c         2014-04-04 14:19:18.000000000 +0400
>
> +++ C-new/LzmaDec.c          2014-09-11 16:16:16.000000000 +0400
>
>
>
> @@ -848,7 +850,7 @@ SRes LzmaDec_DecodeToDic(CLzmaDec *p, Si
>
>              return SZ_ERROR_DATA;
>
>            }
>
>          }
>
> -        p->buf = p->tempBuf;
>
> +        p->buf = &(p->tempBuf[0]);
>
>          if (LzmaDec_DecodeReal2(p, dicLimit, p->buf) != 0)
>
>            return SZ_ERROR_DATA;
>
>          lookAhead -= (rem - (unsigned)(p->buf - p->tempBuf));
>
> @@ -966,7 +968,8 @@ SRes LzmaDec_AllocateProbs(CLzmaDec *p,
>
>    CLzmaProps propNew;
>
>    RINOK(LzmaProps_Decode(&propNew, props, propsSize));
>
>    RINOK(LzmaDec_AllocateProbs2(p, &propNew, alloc));
>
> -  p->prop = propNew;
>
> +  CopyMem(&(p->prop), &propNew, sizeof(CLzmaProps));
>
>    return SZ_OK;
>
>  }
>
>
>
> @@ -988,7 +991,8 @@ SRes LzmaDec_Allocate(CLzmaDec *p, const
>
>      }
>
>    }
>
>    p->dicBufSize = dicBufSize;
>
> -  p->prop = propNew;
>
> +  CopyMem(&(p->prop), &propNew, sizeof(CLzmaProps));
>
>    return SZ_OK;
>
>  }
>
>
>
> ---
>
> Contributed-under: TianoCore Contribution Agreement 1.0
>
> Signed-off-by: Sergey Isakov <[email protected]>
>
>
>
>
>
> On 10.09.2014, at 18:01, Sergey Isakov wrote:
>
>
>
> Hi all,
>
> I encounter a problem that LzmaCustomDecompressLib is not working if
> compiled by Clang into IA32. But it works fine with GCC49.
>
> The sources are very complex and I see no significant constructions that may
> be differ from gcc to clang.
>
> Can anybody point me what to look?
>
> The version is 4.65 while original sources already at 9.2 version. Can we
> switch to recent version?
>
>
>
> Symptoms:
>
> -------
>
>   PrintString ("BFV decompress: DestinationSize = %x, ScratchSize = %x\n",
> (UINTN) DestinationSize, (UINTN) ScratchSize);
>
>   Status =  LzmaUefiDecompress (
>
>     (VOID *)(UINTN)(EFILDR_HEADER_ADDRESS + EFILDRImage->Offset),
>
>     EFILDRImage->Length,
>
>     (VOID *)(UINTN)EFI_DECOMPRESSED_BUFFER_ADDRESS,
>
>     (VOID *)(UINTN)((EFI_DECOMPRESSED_BUFFER_ADDRESS + DestinationSize +
> 0x1000) & 0xfffff000)
>
>     );
>
>
>
>
>
> -------
>
> It prints "BFV decompress: DestinationSize = 2A0000, ScratchSize = 10000"
> and then crash QEMU.
>
> Same, compiled by gcc is working.
>
>
>
> Sergey
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to