On Sep 11, 2014, at 11:13 PM, Jordan Justen <[email protected]> wrote:
> 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.) > In general the compiler either emits code to do it, or does it or emits a memcpy. It would be good to get a better root cause. Thanks, Andrew Fish > -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 ------------------------------------------------------------------------------ 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
