From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=jordan.l.justen@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 582AA21A07A80 for ; Sun, 18 Nov 2018 17:13:22 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2018 17:13:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,250,1539673200"; d="scan'208";a="87455548" Received: from dtan-mobl.amr.corp.intel.com (HELO localhost) ([10.254.55.211]) by fmsmga008.fm.intel.com with ESMTP; 18 Nov 2018 17:13:21 -0800 MIME-Version: 1.0 To: Andrew Fish , Liu Yu Message-ID: <154259000092.7306.2206833534307673295@jljusten-skl> From: Jordan Justen In-Reply-To: <81FDCF97-4145-4A7D-93B9-70A4D8B505FF@apple.com> Cc: "ruiyu.ni@intel.com" , "edk2-devel@lists.01.org" , Michael D Kinney References: <154253322290.3729.10762860453718631884@jljusten-skl> <81FDCF97-4145-4A7D-93B9-70A4D8B505FF@apple.com> User-Agent: alot/0.7 Date: Sun, 18 Nov 2018 17:13:21 -0800 Subject: Re: EmulatorPkg Unix Host Segmentation fault. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 01:13:22 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2018-11-18 14:37:09, Andrew Fish wrote: > = > = > > On Nov 18, 2018, at 4:07 AM, Liu Yu wrote: > > = > > sorry your path can't fix this issue. if this path just turn off = > > optimization option within sec.c not global project. > > = > > I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x) = > > and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 ) > > = > > I have traced this issue on my hand. > > = > > you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792: > > = > > = > > 790 if (StackOffsetPositive) { > > 791 SecCoreData =3D (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID = > > *)SecCoreData + StackOffset); > > 792 Private =3D (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private + = > > StackOffset); > > 793 } else { > > 794 .......... > > 795 .......... > > 796 } > > = > > 790 --792 disassembly code > > = > > 0x10200f2ca : test %r14b,%r14b > > 0x10200f2cd : je 0x10200f2df = > > > > 0x10200f2cf : mov 0x38(%rsp),%rax > > 0x10200f2d4 : lea 0x0(%rbp,%rax,1),%r14 > > 0x10200f2d9 : lea (%rbx,%rax,1),%rbp > > = > > we can see Private value have been stored in %rbp (rbp register be = > > used as general register ) so when call = > > TemporaryRamSupportPpi->TemporaryRamMigration() > > = > = > The calling conventions define RBP as non-volatile must be preserved > by callee. Using RBP as the frame pointer is optional. This is kind of a mess. I think the definition of EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably should not have been spec'd as 'change stack and return'. Instead, it should have been given a new function pointer to switch-stack and call into. By returning with a switched stack, we don't really know what the returning code could do with regard to the stack. For example, it could have saved the stack value on the stack and then pop it into a register and somehow switch the stack back to the old stack. It seems unlikely, but I don't think anything prevents it. Additionally, there is the issue of rbp/ebp being used as a frame pointer. This can lead to some variables being used from the temp ram location after we return from TemporaryRamMigration. (Assuming rbp/ebp is not adjusted to point to the new stack.) So, is it safe to adjust rbp? Unknown. It may not be if rbp is not used as a frame pointer. Is it safe to *not* adjust rbp and potentially allow the old temp ram stack to be used? Unknown. Now, if TemporaryRamMigration received a new function to call into, we can safely assume that the new stack transition would proceed as expected without having to worry if a compiler is using rbp/ebp as a framepointer or not. Another advantage could have been that something like the BasePkg SwitchStack function could have been used, hopefully preventing people from trying to write error prone assembly code for TemporaryRamMigration. -Jordan > Is it possible the assembly coder is assuming RBP is a frame > pointer? That would imply for gcc/clang the correct answer would be > to have compiler flags force frame pointer usage? > = > Assuming -O 0 does something seems like we are matching an > implementation at a given point in time. I'd rather force the frame > pointer usage (that is optional in the ABI) if that fixes the RBP > usage assumption. I guess the other option would be to have > different assembler if the compiler is using frame pointers or not. > and I don't think we have that concept. > = > Given this is the common frame pointer pattern: > = > pushq %rbp > movq %rsp, %rbp > ... > popq %rbp > retq > = > It follows the calling convention rules even if the frame pointer is > not in general use. Thus it only seems like you would hit issues > when you move the stack around. > = > Thanks, > = > Andrew Fish > = > PS Xcode clang always emits the frame pointer. = > = > > this function would modify rbp value because it treat rbp as "stack bas= e = > > address ". > > = > > 816 MigrateMemoryPages (Private, TRUE); > > = > > // Private pointer point to other address, so this function would get a = > > NULL pointer that result in segment fault > > = > > I think we can turn off optimization options like this. > > = > > 1. modify EmulatorPkg.dsc > > = > > MdeModulePkg/Core/Pei/PeiMain.inf { > > > > GCC:*_*_*_CC_FLAGS =3D -O0 > > } > > = > > Reference GCC Manual description: > > = > > -O also turns on -fomit-frame-pointer on machines where doing so does = > > not interfere with debugging. > > = > > = > > = > > =E5=9C=A8 2018/11/18 =E4=B8=8B=E5=8D=885:27, Jordan Justen =E5=86=99=E9= =81=93: > >> On 2018-11-17 20:51:11, Liu Yu wrote: > >>> OS: Ubuntu > >>> = > >>> Toolchain:GCC48 > >> I don't have gcc-4.8, so I couldn't reproduce the issue, but I wonder > >> if this branch can fix the issue for you? > >> = > >> https://github.com/jljusten/edk2/tree/emulator-temp-ram > >> = > >> You can fetch this branch locally to a branch named `test` with a > >> command like this: > >> = > >> $ git fetch --no-tags https://github.com/jljusten/edk2.git emulator-te= mp-ram:test > >> = > >> Then checkout the `test` branch to try it. > >> = > >> First, there is some patches to cleanup Sec, but then I added a patch: > >> = > >> 53a432e149 "EmulatorPkg/Sec: Disable optimizations for TemporaryRamMig= ration function" > >> = > >> Which I hope might help in your case. > >> = > >> -Jordan > >> = > >>> Issue Description : > >>> = > >>> Program received signal SIGSEGV, Segmentation fault. > >>> at /home/pedroa/workspace/orign/edkcrb/MdeModulePkg/Core/Pei/Memor= y/MemoryServices.c:129 > >>> 129 Private->MemoryPages.Size =3D (UINTN) (Private->HobList.Hand= offInformationTable->EfiMemoryTop - > >>> = > >>> = > >>> if the GCC optimization option is used not -O0 so the "rbp" register = will be used as "general register" > >>> = > >>> in the SecTemporaryRamSupport function as below, this function will m= odify the rbp (as general register not stack base address pointer)value tha= t result in program crash. > >>> = > >>> ASM_PFX(SecTemporaryRamSupport): > >>> // Adjust callers %rbp to account for stack move > >>> subq %rdx, %rbp // Calc offset of %rbp in Temp Memory > >>> addq %r8, %rbp // add in permanent base to offset > >>> = > >>> _______________________________________________ > >>> edk2-devel mailing list > >>> edk2-devel@lists.01.org > >>> https://lists.01.org/mailman/listinfo/edk2-devel > = > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel