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
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 h
> On Jul 25, 2022, at 10:43 PM, 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
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.
Your
I guess I could at least dump to the end (req)…. Going backwards is a bit
painful in x86.
(lldb) dis -s 0x000140001B60 -b -c 30
hello_world_std.efi[0x140001b60]: 48 8b 09 movq (%rcx),
%rcx
hello_world_std.efi[0x140001b63]: 48 01 c1 addq %rax,
Ops… Looks like your PE/COFF is linked at 0x00014000, so 0x140001b60 is
the interesting bit.
(lldb) dis -s 0x000140001B60 -b
hello_world_std.efi[0x140001b60]: 48 8b 09 movq (%rcx),
%rcx
hello_world_std.efi[0x140001b63]: 48 01 c1 addq %r
Ayush,
CR2 is the fault address so 0x. 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
add
