From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by mx.groups.io with SMTP id smtpd.web11.11049.1658863439189172619 for ; Tue, 26 Jul 2022 12:23:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=AmCnMEi5; spf=pass (domain: gmail.com, ip: 209.85.216.43, mailfrom: ayushdevel1325@gmail.com) Received: by mail-pj1-f43.google.com with SMTP id 15-20020a17090a098f00b001f305b453feso423150pjo.1 for ; Tue, 26 Jul 2022 12:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=WzxFk2eWJJeXBARMzq7RgNoQ5HC9dLU0Umk2Kpisqi8=; b=AmCnMEi5dBvMrM5eyCifdPaGymB1ItEg0YDyxW6RUnVI7urBHD7eaIBRGjQjco1XH8 N97fO39RfbAww0Mbq3xX4KYbX6WF0Ggpq5EFMfDad83z6rReGTX+UZV+mSnLgjU6aE/S JVDVBoRBU7alrZ8Yd6pxoPJKd5HEAXYKt5DxryVVj9JvWGW5fxj7R3wI/GNXHRhO1MYo rxHYUiQVCvgOlyZHSmYQRqDd9O8R8JwlB7ZIoVJySg0+4/GMKp5ySMzpsTSqJ8QZ4Qpy LM/tmtkUDp/++0nuM5CyPBsK5mJbThMPi3IKP8x6T2bqdfXP44VJWgxgCQCpLWuqxZ+V Fy8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=WzxFk2eWJJeXBARMzq7RgNoQ5HC9dLU0Umk2Kpisqi8=; b=N+4FjGvz3DqA6ii35GjZACF+/GKo7mrptB2KW+ey9Ot+MAS3XNsCjAl9rJDgIxJ1Qb 6K46DADn5vkK60ZOOjp5XihKRyCr+QzH/p9r8YepsDVBSOtvB4i2LKZkjwF73mcERBTF HduKToUxU9v8/MO6E8Y9G1e8o2GHt9at6tXiEj080kfV+zzn/Gvl6PrCphFAUZTjhkhb gn1V6yrdkTXLIvtPukHdQSu5pPM2J2iDCSVbFbOeJf5EtQnT3riWMQPXzIVmhS1Hb1pc gMeV1PvCblU0MPVTDKnkdmU7pNhl+Iof3NLqEKgZWVt71TZ4DR2nQGnWfJJ99tneDfoV Z6Fg== X-Gm-Message-State: AJIora+IFtpNP+fzCKgTu5NzK96hjOkSizcCsN3wUS5RXSsEeRdvSTIh Me3NBrLqltQmWZVF+dc7Jng= X-Google-Smtp-Source: AGRyM1t9AMyrV+sCb0iDUsaX73hTF/kvhm6OQYH7W+OjUSoPHFv/qvWICjBwRnrfJKuhTEJrJ282Uw== X-Received: by 2002:a17:90b:17ca:b0:1f2:df3d:593c with SMTP id me10-20020a17090b17ca00b001f2df3d593cmr637675pjb.205.1658863438301; Tue, 26 Jul 2022 12:23:58 -0700 (PDT) Return-Path: Received: from ?IPV6:2401:4900:1f3f:cdbd:e8b5:9df6:161d:20f0? ([2401:4900:1f3f:cdbd:e8b5:9df6:161d:20f0]) by smtp.gmail.com with ESMTPSA id l4-20020a170903244400b0016c454598b5sm12207974pls.167.2022.07.26.12.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Jul 2022 12:23:57 -0700 (PDT) Message-ID: <17a9da3a-8982-419c-10c5-4a1d9a7f8557@gmail.com> Date: Wed, 27 Jul 2022 00:54:37 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [edk2-devel] Casting i128 into f64 in UEFI Rust pagefaults To: Pedro Falcato , edk2-devel-groups-io Cc: Andrew Fish , Mike Kinney , "mikuback@linux.microsoft.com" , "Gaibusab, Jabeena B" , "Yao, Jiewen" 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> From: "Ayush Singh" In-Reply-To: Content-Type: multipart/alternative; boundary="------------u1FN9kmv9DxVq02BZKcrOq2Y" Content-Language: en-US --------------u1FN9kmv9DxVq02BZKcrOq2Y Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit When I mentioned upstream, I was talking about Rust repository, since as you said, I am not sure if this is LLVM problem yet. There is already a similar bug filed in rust repo about u128 division causing exception [1], and there is a possible fix [2] (which does not work for the page fault). I have also found 1 more edge case in numbers to cause `General Exception`, which just like the other two seems to be related to rust intrinsic or LLVM, but since I am not sure, and simply haven't done any testing on, I cannot really say. Anyway, filing them in Rust repository is helpful since the bug might affect other `msvc-like` tier-2 and tier-3 targets. There is also renewed interest in making UEFI targets Tier-2 from Tier-3 (sponsored by Red Hat), so it's possible that someone else might pick it up before I am done with the std errors I am trying to fix. Ayush Singh [1]: https://github.com/rust-lang/rust/issues/86494 [2]: https://github.com/rust-lang/compiler-builtins/pull/475 On 7/27/22 00:42, Pedro Falcato wrote: > Fyi, please don't file bugs upstream just now. You're not sure if > they're LLVM problems (and they're likely not, else they would affect > everyone else, not just UEFI code). Try to get a simpler, reliable > repro (and do share with us!) before saying it's an LLVM bug. > In my experience, most "what the hell" "compiler bugs" ended up being > things I accidentally set up wrong, or didn't set up at all, and broke > things in a subtle way. > > On Tue, Jul 26, 2022 at 6:43 AM Ayush Singh > wrote: > > 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. > > Yours Sincerely, > > Ayush Singh > > > On 7/26/22 00:24, Andrew Fish wrote: >> I guess I could at least dump to the end (req)…. Going backwards >> is a bit painful in x86. >> >> (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 = 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_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 >> >> hello_world_std.efi[0x140001b8d]: cc                             >> int3 >> >> hello_world_std.efi[0x140001b8e]: cc                             >> int3 >> >> hello_world_std.efi[0x140001b8f]: cc                             >> int3 >> >> hello_world_std.efi[0x140001b90]: e9 db 55 00 00                 >> jmp    0x140007170 >> >> hello_world_std.efi[0x140001b95]: cc                             >> int3 >> >> … >> >> Then we can guess based on how functions get aligned to find the >> start…. >> >> 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[0x140001b59]: 4c 89 c0                       >>       movq   %r8, %rax >> >> hello_world_std.efi[0x140001b5c]: 48 c1 f8 3f                    >>       sarq $0x3f, %rax >> >> 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 = 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_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 >> >> >> So the faulting function is getting passed a bad pointer as its >> 1st arg. >> >> Thanks, >> >> Andrew Fish >> >>> On Jul 25, 2022, at 11:45 AM, Andrew Fish >>> wrote: >>> >>> Ops… Looks like 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                       >>> 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 = 0x8000000000000000 >>> hello_world_std.efi[0x140001b7c]: 4c 21 c6                       >>> andq   %r8, %rsi >>> >>>  RCX - FFFFFFFFFFFFFFFF >>> >>> So yea that looks like the fault. >>> >>> I don’t see that pattern in your .s file…. >>> >>> 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’t have anything installed to crack PDB files. >>> >>> Thanks, >>> >>> Andrew Fish >>> >>>> On Jul 25, 2022, at 10:51 AM, Andrew Fish via groups.io >>>> >>>> wrote: >>>> >>>> Ayush, >>>> >>>> CR2 is the fault address so 0xFFFFFFFFFFFFFFFF. Given for EFI >>>> Virt == Physical the fault address looks like a bad pointer. >>>> >>>> Sorry I’ve not used VC++ in a long time so I don’t know how to >>>> debug with VC++, but If I was using clang/lldb I’d look at the >>>> source and assembly 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 >>>>> >>>>> 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 = b(1); >>>>> assert!((-z as f64) < 0.0); >>>>> } >>>>> >>>>> ``` >>>>> >>>>> >>>>> The exception output is as follows: >>>>> >>>>> ``` >>>>> >>>>> !!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - >>>>> 00000000 !!!! >>>>> ExceptionData - 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 - 0000000000000000, R9  - 0000000000000038, R10 - >>>>> 0000000000000000 >>>>> R11 - 0000000000000000, R12 - 00000000060C6018, R13 - >>>>> 0000000007EDF520 >>>>> R14 - 0000000007EDF6A8, R15 - 0000000005FA9490 >>>>> DS - 0000000000000030, ES  - 0000000000000030, FS  - >>>>> 0000000000000030 >>>>> GS - 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,   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=000000000603C000, EntryPoint=000000000603D8C0) !!!! >>>>> >>>>> ``` >>>>> >>>>> >>>>> 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.zulipchat.com/user_uploads/4715/od51Y9Dkfjahcg9HHcOud8Fm/hello_world_std-338028f9369e2d42.s >>>>> >>>>> 2. EFI >>>>> Binary:https://rust-lang.zulipchat.com/user_uploads/4715/CknqtXLR8SaJZmyOnXctQkpL/hello_world_std.efi >>>>> >>>>> 3. PDB >>>>> file:https://rust-lang.zulipchat.com/user_uploads/4715/zV4i6DsjgQXotp_gS1naEsU0/hello_world_std-338028f9369e2d42.pdb >>>>> >>>>> >>>>> Yours Sincerely, >>>>> >>>>> Ayush Singh >>>>> >>>>> >>>>> [1]:https://doc.rust-lang.org/std/hint/fn.black_box.html >>>>> >>>>> [2]:https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Casting.20i128.20to.20f64.20in.20black_box.20causes.20exception.20in.20UEFI >>>>> >>>>> >>>>> >>>> >>> >> > > > > > -- > Pedro Falcato --------------u1FN9kmv9DxVq02BZKcrOq2Y Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

When I mentioned upstream, I was talking about Rust repository, since as you said, I am not sure if this is LLVM problem yet. There is already a similar bug filed in rust repo about u128 division causing exception [1], and there is a possible fix [2] (which does not work for the page fault). I have also found 1 more edge case in numbers to cause `General Exception`, which just like the other two seems to be related to rust intrinsic or LLVM, but since I am not sure, and simply haven't done any testing on, I cannot really say.


Anyway, filing them in Rust repository is helpful since the bug might affect other `msvc-like` tier-2 and tier-3 targets. There is also renewed interest in making UEFI targets Tier-2 from Tier-3 (sponsored by Red Hat), so it's possible that someone else might pick it up before I am done with the std errors I am trying to fix.


Ayush Singh


[1]: https://github.com/rust-lang/rust/issues/86494

[2]: https://github.com/rust-lang/compiler-builtins/pull/475


On 7/27/22 00:42, Pedro Falcato wrote:
Fyi, please don't file bugs upstream just now. You're not sure if they're LLVM problems (and they're likely not, else they would affect everyone else, not just UEFI code). Try to get a simpler, reliable repro (and do share with us!) before saying it's an LLVM bug.
In my experience, most "what the hell" "compiler bugs" ended up being things I accidentally set up wrong, or didn't set up at all, and broke things in a subtle way.

On Tue, Jul 26, 2022 at 6:43 AM Ayush Singh <ayushdevel1325@gmail.com> wrote:

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.

Yours Sincerely,

Ayush Singh


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

(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 = 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_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   

hello_world_std.efi[0x140001b8d]: cc                             int3   

hello_world_std.efi[0x140001b8e]: cc                             int3   

hello_world_std.efi[0x140001b8f]: cc                             int3   

hello_world_std.efi[0x140001b90]: e9 db 55 00 00                 jmp    0x140007170

hello_world_std.efi[0x140001b95]: cc                             int3   

…

Then we can guess based on how functions get aligned to find the start….

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[0x140001b59]: 4c 89 c0                             movq   %r8, %rax

hello_world_std.efi[0x140001b5c]: 48 c1 f8 3f                          sarq   $0x3f, %rax

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 = 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_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   


So the faulting function is getting passed a bad pointer as its 1st arg. 

Thanks,

Andrew Fish

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

Ops… Looks like 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                       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 = 0x8000000000000000 
hello_world_std.efi[0x140001b7c]: 4c 21 c6                       andq   %r8, %rsi

 RCX - FFFFFFFFFFFFFFFF

So yea that looks like the fault. 

I don’t see that pattern in your .s file…. 

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’t have anything installed to crack PDB files. 

Thanks,

Andrew Fish

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

Ayush,

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

Sorry I’ve not used VC++ in a long time so I don’t know how to debug with VC++, but If I was using clang/lldb I’d look at the source and assembly 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 = b(1);
    assert!((-z as f64) < 0.0);
}

```


The exception output is as follows:

```

!!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
ExceptionData - 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   - 0000000000000000, R9  - 0000000000000038, R10 - 0000000000000000
R11  - 0000000000000000, R12 - 00000000060C6018, R13 - 0000000007EDF520
R14  - 0000000007EDF6A8, R15 - 0000000005FA9490
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 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,   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=000000000603C000, EntryPoint=000000000603D8C0) !!!!

```


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.zulipchat.com/user_uploads/4715/od51Y9Dkfjahcg9HHcOud8Fm/hello_world_std-338028f9369e2d42.s

2. EFI Binary: https://rust-lang.zulipchat.com/user_uploads/4715/CknqtXLR8SaJZmyOnXctQkpL/hello_world_std.efi

3. PDB file: https://rust-lang.zulipchat.com/user_uploads/4715/zV4i6DsjgQXotp_gS1naEsU0/hello_world_std-338028f9369e2d42.pdb


Yours Sincerely,

Ayush Singh


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

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








--
Pedro Falcato
--------------u1FN9kmv9DxVq02BZKcrOq2Y--