From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) by mx.groups.io with SMTP id smtpd.web12.9982.1658857829313901547 for ; Tue, 26 Jul 2022 10:50:29 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=WkV/Ho/X; spf=pass (domain: apple.com, ip: 17.171.2.60, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 26QHZ1cJ011525; Tue, 26 Jul 2022 10:50:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=2W48W0PDkuR8FOscguMYyqJGt4ayOr6nph0fYh0d7Dc=; b=WkV/Ho/Xoi4PURaRROw7zwWP2P5YfzMnqP/3PZuFV6p+eBU5gCJg5HLw98cXzXrKWvzz mWeqDJtSnaJagTbXbLtZjvaWRkm3orp0o34rCt/OgXkPQaTk/E/BMYQ0REhwvSok10oA 7ef68CtboEq9+bRT6owoshX5ZY4LMSdakWYsnGZBioFhu+ViM+jpQESoyz8YQyfDYzRj 2oj3l7MBfKZg8+6eO+ycabG0qYUqkovqxJIIAtgZTnVU1zSYxLPm29B04df6XeVDJrkc IWYA/BlN6165eV7v+zNbCRZbyJlTXOHGVqttem9qm4Y4bkli/7E14fQP0Br21ZIuHuEJ +Q== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3hgfn3rrd4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jul 2022 10:50:28 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RFN00ERS2W3SV30@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 26 Jul 2022 10:50:27 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RFN00Z0029ACB00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 26 Jul 2022 10:50:27 -0700 (PDT) X-Va-A: X-Va-T-CD: 34d046f6e3813fd70005e81a97f985c3 X-Va-E-CD: fa9e1aa2e33b303a80c7290ebbbc84ef X-Va-R-CD: b22de2176895e5e0422f5f3b61053f8b X-Va-CD: 0 X-Va-ID: 6397e3e8-2ec3-4fe8-bd86-0d87596f2986 X-V-A: X-V-T-CD: 34d046f6e3813fd70005e81a97f985c3 X-V-E-CD: fa9e1aa2e33b303a80c7290ebbbc84ef X-V-R-CD: b22de2176895e5e0422f5f3b61053f8b X-V-CD: 0 X-V-ID: 4b4dffb5-b4f5-44bd-a600-fee48e09e61a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-07-26_05:2022-07-26,2022-07-26 signatures=0 Received: from smtpclient.apple (unknown [17.235.33.95]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RFN00V5N2W02Q00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 26 Jul 2022 10:50:25 -0700 (PDT) From: "Andrew Fish" Message-id: <47BEA05F-B1E1-4BCC-B281-E596AD9B5781@apple.com> MIME-version: 1.0 (Mac OS X Mail 16.0 \(3729.0.22.1.1\)) Subject: Re: [edk2-devel] Casting i128 into f64 in UEFI Rust pagefaults Date: Tue, 26 Jul 2022 10:50:14 -0700 In-reply-to: <17a84748-381f-e438-a338-c6ab0dbabdc6@gmail.com> Cc: edk2-devel-groups-io , Mike Kinney , "mikuback@linux.microsoft.com" , "Gaibusab, Jabeena B" , "Yao, Jiewen" To: Ayush Singh References: <15b0ac38-4b55-4b19-3f76-506c5b858949@gmail.com> <170523E2507C1293.4676@groups.io> <116DE63D-B96C-4D2F-9CF6-299F053329D7@apple.com> <57E4EE5B-4A4C-4592-A811-14DB025C58E1@apple.com> <17a84748-381f-e438-a338-c6ab0dbabdc6@gmail.com> X-Mailer: Apple Mail (2.3729.0.22.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-07-26_05:2022-07-26,2022-07-26 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_2E9E8549-28F0-46A3-8A40-D3450568D114" --Apple-Mail=_2E9E8549-28F0-46A3-8A40-D3450568D114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 25, 2022, at 10:43 PM, Ayush Singh wrot= e: >=20 > Hi Andrew. Thanks for all your work. The more I look at this, the more it= feels like it might be a problem on the LLVM side instead of Rust. I also = found some more tests (all related to numbers btw) which can cause differen= t types of exceptions, so I think I will try filing bugs upstream.=20 Ayush, In general If we want to move to Rust we are going to need a way to debug i= ssues like this down to the root cause. I think figuring out how to debug w= ill make it easier to move forward with the Rust port in general. It will t= ime well spent.=20 The best way to get LLVM fixed, if it is even broken, is to provide a simpl= e test case that reproduces the behavior. I don=E2=80=99t think at this poi= nt we know what is going on. It is very unlikely that some random LLVM deve= loper is going to invest the time in trying to setup some UEFI environment = to try and root cause this bug. I general find I have to create a simple at= desk example and then I get stuff fixed quickly. Basically a test case the= LLVM developer can compile at their desk and see the error in assembler, o= r at least run it at desk and have bogus output.=20 I=E2=80=99m not 100% sure what toolchain you are using. Can you `objdump -d= hello_world_std.efi`and get some symbols with the disassembly? For VC++ I = think it would be `DUMPBIN /DISASM`. What are you planning on using for source level debugging Rust? I wrote som= e gdb[1] and lldb[2] debugging commands in Python. I=E2=80=99m guessing loa= ding Rust symbols from PE/COFF images should be similar, as long as the deb= ugger knows about rust.=20 I=E2=80=99m happy to help you figure out stuff related to debugging Rust.= =20 [1] https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/efi_gdb= .py [2] https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/efi_lld= b.py Thanks, Andrew Fish > Yours Sincerely, >=20 > Ayush Singh >=20 >=20 >=20 > On 7/26/22 00:24, Andrew Fish wrote: >> I guess I could at least dump to the end (req)=E2=80=A6. Going backwards= is a bit painful in x86.=20 >>=20 >> (lldb) dis -s 0x0000000140001B60 -b -c 30 >> hello_world_std.efi[0x140001b60]: 48 8b 09 movq = (%rcx), %rcx >> hello_world_std.efi[0x140001b63]: 48 01 c1 addq = %rax, %rcx >> hello_world_std.efi[0x140001b66]: 4c 89 c2 movq = %r8, %rdx >> hello_world_std.efi[0x140001b69]: 48 11 c2 adcq = %rax, %rdx >> hello_world_std.efi[0x140001b6c]: 48 31 c1 xorq = %rax, %rcx >> hello_world_std.efi[0x140001b6f]: 48 31 c2 xorq = %rax, %rdx >> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80 movabsq= $-0x8000000000000000, %rsi ; imm =3D 0x8000000000000000=20 >> hello_world_std.efi[0x140001b7c]: 4c 21 c6 andq = %r8, %rsi >> hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00 callq = 0x1400070e0 >> hello_world_std.efi[0x140001b84]: 48 09 f0 orq = %rsi, %rax >> hello_world_std.efi[0x140001b87]: 48 83 c4 20 addq = $0x20, %rsp >> hello_world_std.efi[0x140001b8b]: 5e popq = %rsi >> hello_world_std.efi[0x140001b8c]: c3 retq = =20 >> hello_world_std.efi[0x140001b8d]: cc int3 = =20 >> hello_world_std.efi[0x140001b8e]: cc int3 = =20 >> hello_world_std.efi[0x140001b8f]: cc int3 = =20 >> hello_world_std.efi[0x140001b90]: e9 db 55 00 00 jmp = 0x140007170 >> hello_world_std.efi[0x140001b95]: cc int3 = =20 >> =E2=80=A6 >>=20 >> Then we can guess based on how functions get aligned to find the start= =E2=80=A6. >>=20 >> hello_world_std.efi[0x140001b50]: 56 p= ushq %rsi >> hello_world_std.efi[0x140001b51]: 48 83 ec 20 s= ubq $0x20, %rsp >> hello_world_std.efi[0x140001b55]: 4c 8b 41 08 m= ovq 0x8(%rcx), %r8 >> hello_world_std.efi[0x140001b59]: 4c 89 c0 m= ovq %r8, %rax >> hello_world_std.efi[0x140001b5c]: 48 c1 f8 3f s= arq $0x3f, %rax >> hello_world_std.efi[0x140001b60]: 48 8b 09 m= ovq (%rcx), %rcx >> hello_world_std.efi[0x140001b63]: 48 01 c1 a= ddq %rax, %rcx >> hello_world_std.efi[0x140001b66]: 4c 89 c2 m= ovq %r8, %rdx >> hello_world_std.efi[0x140001b69]: 48 11 c2 a= dcq %rax, %rdx >> hello_world_std.efi[0x140001b6c]: 48 31 c1 x= orq %rax, %rcx >> hello_world_std.efi[0x140001b6f]: 48 31 c2 x= orq %rax, %rdx >> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80 m= ovabsq $-0x8000000000000000, %rsi ; imm =3D 0x8000000000000000=20 >> hello_world_std.efi[0x140001b7c]: 4c 21 c6 a= ndq %r8, %rsi >> hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00 c= allq 0x1400070e0 >> hello_world_std.efi[0x140001b84]: 48 09 f0 o= rq %rsi, %rax >> hello_world_std.efi[0x140001b87]: 48 83 c4 20 a= ddq $0x20, %rsp >> hello_world_std.efi[0x140001b8b]: 5e p= opq %rsi >> hello_world_std.efi[0x140001b8c]: c3 r= etq =20 >>=20 >> So the faulting function is getting passed a bad pointer as its 1st arg.= =20 >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> On Jul 25, 2022, at 11:45 AM, Andrew Fish wrote: >>>=20 >>> Ops=E2=80=A6 Looks like your PE/COFF is linked at 0x0000000140000000, s= o 0x140001b60 is the interesting bit. >>>=20 >>> (lldb) dis -s 0x0000000140001B60 -b >>> hello_world_std.efi[0x140001b60]: 48 8b 09 movq = (%rcx), %rcx >>> hello_world_std.efi[0x140001b63]: 48 01 c1 addq = %rax, %rcx >>> hello_world_std.efi[0x140001b66]: 4c 89 c2 movq = %r8, %rdx >>> hello_world_std.efi[0x140001b69]: 48 11 c2 adcq = %rax, %rdx >>> hello_world_std.efi[0x140001b6c]: 48 31 c1 xorq = %rax, %rcx >>> hello_world_std.efi[0x140001b6f]: 48 31 c2 xorq = %rax, %rdx >>> hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80 movabs= q $-0x8000000000000000, %rsi ; imm =3D 0x8000000000000000=20 >>> hello_world_std.efi[0x140001b7c]: 4c 21 c6 andq = %r8, %rsi >>>=20 >>> RCX - FFFFFFFFFFFFFFFF >>>=20 >>> So yea that looks like the fault.=20 >>>=20 >>> I don=E2=80=99t see that pattern in your .s file=E2=80=A6.=20 >>>=20 >>> Can you figure out what function is @ 0x140001b60 in the PE/COFF image.= Do you have a map file from the linker? >>>=20 >>> Thanks, >>>=20 >>> Andrew Fish >>>=20 >>> PS Again sorry I don=E2=80=99t have anything installed to crack PDB fil= es.=20 >>>=20 >>> Thanks, >>>=20 >>> Andrew Fish >>>=20 >>>> On Jul 25, 2022, at 10:51 AM, Andrew Fish via groups.io wrote: >>>>=20 >>>> Ayush, >>>>=20 >>>> CR2 is the fault address so 0xFFFFFFFFFFFFFFFF. Given for EFI Virt =3D= =3D Physical the fault address looks like a bad pointer.=20 >>>>=20 >>>> Sorry I=E2=80=99ve not used VC++ in a long time so I don=E2=80=99t kno= w how to debug with VC++, but If I was using clang/lldb I=E2=80=99d look at= the source and assembly for the fault address.=20 >>>>=20 >>>> The image base is: 0x000000000603C000 >>>> The fault PC/RIP is: 000000000603DB60 >>>>=20 >>>> So the faulting code is at 0x1B60 in the image. Given the images are l= inked at zero you should be able to load the build product into the debugge= r and look at what code is at offset 0x1B60. The same should work for any t= ools that dump the binary.=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Andrew Fish >>>>=20 >>>>> On Jul 25, 2022, at 10:33 AM, Ayush Singh = wrote: >>>>>=20 >>>>> Hello everyone.While running Rust tests in UEFI environment, I have c= ome across a numeric test that causes a pagefault. A simple reproducible ex= ample for this is given below: >>>>>=20 >>>>> ```rust >>>>>=20 >>>>> fn main() { >>>>> use std::hint::black_box as b; >>>>>=20 >>>>> let z: i128 =3D b(1); >>>>> assert!((-z as f64) < 0.0); >>>>> } >>>>>=20 >>>>> ``` >>>>>=20 >>>>>=20 >>>>> The exception output is as follows: >>>>>=20 >>>>> ``` >>>>>=20 >>>>> !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 0000000= 0 !!!! >>>>> ExceptionData - 0000000000000000 I:0 R:0 U:0 W:0 <= w:0> P:0 PK:0 SS:0 SGX:0 >>>>> RIP - 000000000603DB60, CS - 0000000000000038, RFLAGS - 00000000000= 00246 >>>>> RAX - 0000000000000000, RCX - FFFFFFFFFFFFFFFF, RDX - FFFFFFFFFFFFFF= FF >>>>> RBX - 0000000000000000, RSP - 0000000007EDF1D0, RBP - 0000000007EDF4= C0 >>>>> RSI - 0000000007EDF360, RDI - 0000000007EDF3C0 >>>>> R8 - 0000000000000000, R9 - 0000000000000038, R10 - 00000000000000= 00 >>>>> R11 - 0000000000000000, R12 - 00000000060C6018, R13 - 0000000007EDF5= 20 >>>>> R14 - 0000000007EDF6A8, R15 - 0000000005FA9490 >>>>> DS - 0000000000000030, ES - 0000000000000030, FS - 00000000000000= 30 >>>>> GS - 0000000000000030, SS - 0000000000000030 >>>>> CR0 - 0000000080010033, CR2 - FFFFFFFFFFFFFFFF, CR3 - 0000000007C010= 00 >>>>> CR4 - 0000000000000668, CR8 - 0000000000000000 >>>>> DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 00000000000000= 00 >>>>> DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 00000000000004= 00 >>>>> GDTR - 00000000079DE000 0000000000000047, LDTR - 0000000000000000 >>>>> IDTR - 0000000007418018 0000000000000FFF, TR - 0000000000000000 >>>>> FXSAVE_STATE - 0000000007EDEE30 >>>>> !!!! Find image based on IP(0x603DB60) /var/home/ayush/Documents/Prog= ramming/Rust/uefi/hello_world_std/target/x86_64-unknown-uefi/debug/deps/hel= lo_world_std-338028f9369e2d42.pdb (ImageBase=3D000000000603C000, EntryPoint= =3D000000000603D8C0) !!!! >>>>>=20 >>>>> ``` >>>>>=20 >>>>>=20 >>>>> From my testing, the exception only occurs when a few conditions are = met. >>>>>=20 >>>>> 1. The binary is compiled in Debug mode. No error in Release mode. >>>>>=20 >>>>> 2. `i128` is in a black_box [1]. Does not occur if `black_box` is not= present. >>>>>=20 >>>>> 3. It has to be `i128`. `i64` or something else work fine. >>>>>=20 >>>>> 4. The cast has to be done on `-z`. Doing the same with `+z` is fine. >>>>>=20 >>>>>=20 >>>>> I have also been discussing this in the Rust zulipchat [2], so feel f= ree to chime in there. >>>>>=20 >>>>>=20 >>>>> Additionally, here are links for more information about this program: >>>>>=20 >>>>> 1. Assembly: https://rust-lang.zulipchat.com/user_uploads/4715/od51Y9= Dkfjahcg9HHcOud8Fm/hello_world_std-338028f9369e2d42.s >>>>>=20 >>>>> 2. EFI Binary: https://rust-lang.zulipchat.com/user_uploads/4715/Cknq= tXLR8SaJZmyOnXctQkpL/hello_world_std.efi >>>>>=20 >>>>> 3. PDB file: https://rust-lang.zulipchat.com/user_uploads/4715/zV4i6D= sjgQXotp_gS1naEsU0/hello_world_std-338028f9369e2d42.pdb >>>>>=20 >>>>>=20 >>>>> Yours Sincerely, >>>>>=20 >>>>> Ayush Singh >>>>>=20 >>>>>=20 >>>>> [1]: https://doc.rust-lang.org/std/hint/fn.black_box.html >>>>>=20 >>>>> [2]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler= .2Fhelp/topic/Casting.20i128.20to.20f64.20in.20black_box.20causes.20excepti= on.20in.20UEFI >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 --Apple-Mail=_2E9E8549-28F0-46A3-8A40-D3450568D114 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 25, 2022, at 10:43 PM, Ayush Singh <ayushdevel1325@gmail.com&g= t; wrote:

=20 =20

Hi Andrew. Thanks for all your work. The more I look at this, the more it feels like it might be a problem on the LLVM side instead of Rust. I also found some more tests (all related to numbers btw) which can cause different types of exceptions, so I think I will try filing bugs upstream.


Ayush,

<= div>
In general If we want to move to Rust we are going to need a way t= o debug issues like this down to the root cause. I think figuring out how t= o debug will make it easier to move forward with the Rust port in general. = It will time well spent. 

The best way = to get LLVM fixed, if it is even broken, is to provide a simple test case t= hat reproduces the behavior. I don=E2=80=99t think at this point we know wh= at is going on. It is very unlikely that some random LLVM developer is goin= g to invest the time in trying to setup some UEFI environment to try and ro= ot cause this bug. I general find I have to create a simple at desk example= and then I get stuff fixed quickly. Basically a test case the LLVM develop= er can compile at their desk and see the error in assembler, or at least ru= n it at desk and have bogus output. 

I=E2=80= =99m not 100% sure what toolchain you are using. Can you `objdump -d h= ello_world_std.efi`and get some symbols with the disassembly? For VC++ I th= ink it would be `DUMPBIN /DISASM`.

What are you pl= anning on using for source level debugging Rust? I wrote some gdb[1] and ll= db[2] debugging commands in Python. I=E2=80=99m guessing loading Rust symbo= ls from PE/COFF images should be similar, as long as the debugger knows abo= ut rust. 

I=E2=80=99m happy to help you figur= e out stuff related to debugging Rust. 


Thanks,

Andrew Fish

Yours Sincerely,

Ayush = Singh


On 7/26/22 00:24, Andrew Fish wrote:
I guess I could at least dump to the end (req)=E2=80=A6. Going backwa= rds is a bit painful in x86. 

(lldb) dis -s 0x0000000140001B60 -b -c 30<= /div>
hello_world_std.efi[0x140001b60]: 48 8b 09                = ;       movq   (%rcx), %rcx
hello_world_std.efi[0x140001b63]: 48 01 c1                = ;       addq   %rax, %rcx
hello_world_std.efi[0x140001b66]: 4c 89 c2                = ;       movq   %r8, %rdx
= hello_world_std.efi[0x140001b69]: 48 11 c2                = ;       adcq   %rax, %rdx
hello_world_std.efi[0x140001b6c]: 48 31 c1                = ;       xorq   %rax, %rcx
hello_world_std.efi[0x140001b6f]: 48 31 c2                = ;       xorq   %rax, %rdx
hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80  movabsq $-0x800000000000000= 0, %rsi ; imm =3D 0x8000000000000000 
hello_world_std.efi[0x140001b7c]: 4c 21 c6                = ;       andq   %r8, %rsi
= hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00              =   callq  0x1400070e0
hello_world_s= td.efi[0x140001b84]: 48 09 f0                = ;       orq    %rsi, %rax
hello_world_std.efi[0x140001b87]: 48 83 c4 20              &nb= sp;     addq   $0x20, %rsp
hel= lo_world_std.efi[0x140001b8b]: 5e                 &nbs= p;           popq   %rsi
hello_world_std.efi[0x140001b8c]: c3                 &nbs= p;           retq   
hello_world_std.efi[0x140001b8d]: cc                 &nbs= p;           int3   
hello_world_std.efi[0x140001b8e]: cc                 &nbs= p;           int3   
hello_world_std.efi[0x140001b8f]: cc                 &nbs= p;           int3   
hello_world_std.efi[0x140001b90]: e9 db 55 00 00              =   jmp    0x140007170
hello_wo= rld_std.efi[0x140001b95]: cc                 &nbs= p;           int3   
= =E2=80=A6
Th= en we can guess based on how functions get aligned to find the start=E2=80=A6.
hello_world_std.efi[0x140001b50]: 56                 =                   pushq  = %rsi
hello_world_std.efi[0x140001b51]: 48 83 ec 20             =             subq   $0x20, %rsp
hello_world_std.efi[0x140001b55]: 4c 8b 41 08             =             movq   0x8(%rcx), %r8
hello_world_std.efi[0x140= 001b59]: 4c 89 c0               &= nbsp;             movq   %r8, %rax
hello_world_std.efi[0x140001b5c]: 48 c1 f8 3f             =             sarq   $0x3f, %rax
hello_world_std.efi[0x140001b60]: 48 8b 09               &= nbsp;             movq   (%rcx), %rcx
hello_world_std.efi[0x140001b63]: 48 01 c1               &= nbsp;             addq   %rax, %rcx
hello_world_std.efi[0x140001b66]: 4c 89 c2               &= nbsp;             movq   %r8, %rdx
hello_world_std.efi[0x140001b69]: 48 11 c2               &= nbsp;             adcq   %rax, %rdx
hello_world_std.efi[0x140001b6c]: 48 31 c1               &= nbsp;             xorq   %rax, %rcx
hello_world_std.efi[0x140001b6f]: 48 31 c2               &= nbsp;             xorq   %rax, %rdx
hello_world_std.efi[0x140001b72]: 48 be 00 00 00 00 00 00 00 80        mo= vabsq $-0x8000000000000000, %rsi ; imm =3D 0x8000000000000000&nbs= p;
hello_world_std.efi[0x140001b7c]: 4c 21 c6               &= nbsp;             andq   %r8, %rsi
hello_world_std.efi[0x140001b7f]: e8 5c 55 00 00             &n= bsp;         callq  0x1400070e0
hello_world_std.efi[0x140001b84]: 48 09 f0               &= nbsp;             orq    %rsi, %rax=
hello_world_std.efi[0x140001b87]: 48 83 c4 20             =             addq   $0x20, %rsp
hello_world_std.efi[0x140001b8b]: 5e                 =                   popq   = %rsi
hello_world_std.efi[0x140001b8c]: c3                 =                   retq  &= nbsp;

So the faulting function is getting passed a bad pointer as its 1st arg. 
Th= anks,
An= drew Fish

On Jul 25, 2022, at 11:45 AM, Andrew Fish <afish@apple.com> wrote:

Ops=E2=80=A6 Looks l= ike your PE/COFF is linked at 0x0000000140000000, so 0x140001b60 is the interesting bit.

(lldb) dis -s 0x0000000140001B60 -b
hello_world_std.efi[0x140001b60]= : 48 8b 09             &n= bsp;         movq   (%rcx), %rcx
hello_world_std.efi[0x140001b63]= : 48 01 c1             &n= bsp;         addq   %rax, %rcx
hello_world_std.efi[0x140001b66]= : 4c 89 c2             &n= bsp;         movq   %r8, %rdx
hello_world_std.efi[0x140001b69]= : 48 11 c2             &n= bsp;         adcq   %rax, %rdx
hello_world_std.efi[0x140001b6c]= : 48 31 c1             &n= bsp;         xorq   %rax, %rcx
hello_world_std.efi[0x140001b6f]= : 48 31 c2             &n= bsp;         xorq   %rax, %rdx
hello_world_std.efi[0x140001b72]= : 48 be 00 00 00 00 00 00 00 80  movabsq $-0x8000000000000000, %rsi ; imm =3D 0x8000000000000000 
hello_world_std.efi[0x140001b7c]= : 4c 21 c6             &n= bsp;         andq   %r8, %rsi

 RCX - FFFFFFFFFFFFFFFF

So yea that looks like the fault. 

I don=E2=80=99t see that pattern= in your .s file=E2=80=A6. 

Can you figure out what function is @ 0x140001b60 in the PE/COFF image. Do you have a map file from the linker?

Thanks,

Andrew Fish

PS Again sorry I don=E2=80=99t h= ave anything installed to crack PDB files. 

Thanks,

Andrew Fish

On Jul 25, 2022, at 10:51 AM, Andrew Fish via groups.io <afish=3Dapple.com@groups.io>= wrote:

Ayush,

CR2 is the fault address so 0xFFFFFFFFFFFFFFFF. Given for EFI Virt =3D=3D Physical the fault address looks like a bad pointer. 

Sorry I=E2=80=99ve n= ot used VC++ in a long time so I don=E2=80=99t know = how to debug with VC++, but If I was using clang/lldb I=E2=80=99d look at the source and ass= embly for the fault address. 

The image base is: 0x000000000603C000
The fault PC/RIP is: 000000000603DB60

So the faulting code is at 0x1B60 in the image. Given the images are linked at zero you should be able to load the build product into the debugger and look at what code is at offset 0x1B60. The same should work for any tools that dump the binary. 

Thanks,

Andrew Fish

On Jul 25, 2022, at 10:33 AM, Ayush Singh <ayushdevel1325@gmail.com> wrote:

Hello everyone.While running Rust tests in UEFI environment, I have come across a numeric test that causes a pagefault. A simple reproducible example for this is given below:

```rust

fn main() {
  =   use std::hint::black_box as b;

  =   let z: i128 =3D b(1);
  =   assert!((-z as f64) < 0.0);
}

```

The exception output is as follows:
```
!!!! X64 Exception Type - 0E(#PF - Page-Fault)&nbs= p; CPU Apic ID - 00000000 !!!!
ExceptionDat= a - 0000000000000000  I:0 R:0 U:0 W:0 P:0 PK:0 = SS:0 SGX:0
RIP  - 000000000603DB60, CS  - 0000000000000038, RFLAGS - 0000000000000246
RAX  - 0000000000000000, RCX - FFFFFFFFFFFFFFFF, RDX - FFFFFFFFFFFFFFFF
RBX  - 0000000000000000, RSP - 0000000007EDF1D0, RBP - 0000000007EDF4C0
RSI  - 0000000007EDF360, RDI - 0000000007EDF3C0
R8 &nbs= p; - 0000000000000000, R9  - 0000000000000038, R10 - 0000000000000000
R11  - 0000000000000000, R12 - 00000000060C6018, R13 - 0000000007EDF520
R14  - 0000000007EDF6A8, R15 - 0000000005FA9490
DS &nbs= p; - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS &nbs= p; - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010033, CR2 - FFFFFFFFFFFFFFFF, CR3 - 0000000007C01000
CR4  - 0000000000000668, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 00000000079DE000 0000000000000047, LDTR - 0000000000000000
IDTR - 0000000007418018 0000000000000FFF, &= nbsp; TR - 0000000000000000
FXSAVE_STATE - 0000000007EDEE30
!!!! Find image based on IP(0x603DB60) /var/home/ayush/Documents/Programming/Rust/uefi/hello_world_std/target/x86_= 64-unknown-uefi/debug/deps/hello_world_std-338028f9369e2d42.pdb (ImageBase=3D000000000603C000, EntryPoint=3D000000000603D8C0) !!!!

```

From my testing, the exception only occurs when a few conditions are met.

1. The binary is compiled in Debug mode. No error in Release mode.

2. `i128` is in a black_box [1]. Does not occur if `black_box` is not present.

3. It has to be `i128`. `i64` or something else work fine.

4. The cast has to be done on `-z`. Doing the same with `+z` is fine.


I have also been discussing this in the Rust zulipchat [2], so feel free to chime in there.


Additionally= , here are links for more information about this program:

1. Assembly: https://rust-lang.zulipcha= t.com/user_uploads/4715/od51Y9Dkfjahcg9HHcOud8Fm/hello_world_std-338028f936= 9e2d42.s

2. EFI Binary: https://rust-lang.zulipcha= t.com/user_uploads/4715/CknqtXLR8SaJZmyOnXctQkpL/hello_world_std.efi
3. PDB file: https://rust-lang.zulipcha= t.com/user_uploads/4715/zV4i6DsjgQXotp_gS1naEsU0/hello_world_std-338028f936= 9e2d42.pdb


Yours Sincerely,

Ayush Singh


[1]: https://doc.rust-lang.org/= std/hint/fn.black_box.html

[2]: https://rust-lang.zulipcha= t.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Casting.20i128.20to.20f= 64.20in.20black_box.20causes.20exception.20in.20UEFI




=20



--Apple-Mail=_2E9E8549-28F0-46A3-8A40-D3450568D114--