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 <af...@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....@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 <ayushdevel1...@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 >>> >>> >>> >> >> > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#91821): https://edk2.groups.io/g/devel/message/91821 Mute This Topic: https://groups.io/mt/92610101/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-