Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 30 Sept 2021 at 12:34, abhijeet inamdar
wrote:
> Actually the ELF generates the .bin file which is being used to run on the
> target (hardware). It's address starts from zero when I see the starting
> frames of it. As follows:
>
> IN:
> 0x0002: c0de stm r0!, {r1, r2, r3, r4, r6, r7}
> 0x0004: 0003 movs r3, r0
> 0x0006: movs r0, r0
> 0x0008: 0001 movs r1, r0
> 0x000a: movs r0, r0
> 0x000c: 0002 movs r2, r0
> 0x000e: movs r0, r0
> 0x0010: 0168 lsls r0, r5, #5
> 0x0012: movs r0, r0
> 0x0014: 5838 ldr r0, [r7, r0]
This clearly isn't code; it's some kind of data. It's not
a vector table, because it starts
0xc0de
0x0003
0x0001
0x0002
0x0168
and those aren't plausible looking addresses.
The guest CPU loads the reset SP and PC. The reset PC
is 0x0003, so we start at address 0x0002 in Thumb
mode. The data at that address is not a sensible instruction
(it's that "stm r0!..."), but we execute it. r0 is 0, so this
is going to store new random data all over the existing
data that we were incorrectly executing. The inevitable
result is that we take an exception, and this time the
vector table is full of zeros, so now we try to execute
from 0x0 in non-Thumb mode, which means we take another exception,
which is Lockup.
The solution remains the same: you need to load a guest
image which puts a valid vector table in guest memory
at the address where the CPU expects it (which looks like
0x0 in this case). Until you do this, your guest code
will crash in mysterious-looking ways because you are
not running what you think you are running.
-- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
The above is when I load the .bin instead of ELF in the machine.
On Thu, Sep 30, 2021 at 1:33 PM abhijeet inamdar <
abhijeetinamdar3...@gmail.com> wrote:
> Actually the ELF generates the .bin file which is being used to run on the
> target (hardware). It's address starts from zero when I see the starting
> frames of it. As follows:
>
>
> IN:
> 0x0002: c0de stm r0!, {r1, r2, r3, r4, r6, r7}
> 0x0004: 0003 movs r3, r0
> 0x0006: movs r0, r0
> 0x0008: 0001 movs r1, r0
> 0x000a: movs r0, r0
> 0x000c: 0002 movs r2, r0
> 0x000e: movs r0, r0
> 0x0010: 0168 lsls r0, r5, #5
> 0x0012: movs r0, r0
> 0x0014: 5838 ldr r0, [r7, r0]
> 0x0016: movs r0, r0
> 0x0018: movs r0, r0
> 0x001a: movs r0, r0
> 0x001c: ac8e add r4, sp, #0x238
> 0x001e: 48d4 ldr r0, [pc, #0x350]
> 0x0020: 39bb subs r1, #0xbb
> 0x0022: 421b tst r3, r3
> 0x0024: 3db7 subs r5, #0xb7
> 0x0026: 5d30 ldrb r0, [r6, r4]
> 0x0028: 79df ldrb r7, [r3, #7]
> 0x002a: fcf6 6a34 ldc2lp10, c6, [r6], #0xd0
>
> OUT: [size=1040]
> 0x70849100: 8b 5d f0 movl -0x10(%rbp), %ebx
> 0x70849103: 85 dbtestl%ebx, %ebx
> 0x70849105: 0f 8c cb 02 00 00jl 0x708493d6
> 0x7084910b: 8b 5d 04 movl 4(%rbp), %ebx
> 0x7084910e: 44 8b 65 00 movl (%rbp), %r12d
> 0x70849112: 41 8b fc movl %r12d, %edi
> 0x70849115: c1 ef 05 shrl $5, %edi
> 0x70849118: 23 7d 80 andl -0x80(%rbp), %edi
> 0x7084911b: 48 03 7d 88 addq -0x78(%rbp), %rdi
> 0x7084911f: 41 8d 74 24 03 leal 3(%r12), %esi
> 0x70849124: 81 e6 00 fc ff ffandl $0xfc00, %esi
> 0x7084912a: 3b 77 04 cmpl 4(%rdi), %esi
> 0x7084912d: 41 8b f4 movl %r12d, %esi
> 0x70849130: 0f 85 ac 02 00 00jne 0x708493e2
> 0x70849136: 48 03 77 10 addq 0x10(%rdi), %rsi
> 0x7084913a: 89 1emovl %ebx, (%rsi)
> 0x7084913c: 41 8d 5c 24 04 leal 4(%r12), %ebx
> 0x70849141: 44 8b e3 movl %ebx, %r12d
> 0x70849144: 44 8b 6d 08 movl 8(%rbp), %r13d
> 0x70849148: 41 8b fc movl %r12d, %edi
> 0x7084914b: c1 ef 05 shrl $5, %edi
> 0x7084914e: 23 7d 80 andl -0x80(%rbp), %edi
> 0x70849151: 48 03 7d 88 addq -0x78(%rbp), %rdi
> 0x70849155: 41 8d 74 24 03 leal 3(%r12), %esi
> 0x7084915a: 81 e6 00 fc ff ffandl $0xfc00, %esi
> 0x70849160: 3b 77 04 cmpl 4(%rdi), %esi
> 0x70849163: 41 8b f4 movl %r12d, %esi
> 0x70849166: 0f 85 8f 02 00 00jne 0x708493fb
> 0x7084916c: 48 03 77 10 addq 0x10(%rdi), %rsi
> 0x70849170: 44 89 2e movl %r13d, (%rsi)
> 0x70849173: 83 c3 04 addl $4, %ebx
> 0x70849176: 44 8b e3 movl %ebx, %r12d
> 0x70849179: 44 8b 6d 0c movl 0xc(%rbp), %r13d
> 0x7084917d: 41 8b fc movl %r12d, %edi
> 0x70849180: c1 ef 05 shrl $5, %edi
> 0x70849183: 23 7d 80 andl -0x80(%rbp), %edi
> 0x70849186: 48 03 7d 88 addq -0x78(%rbp), %rdi
> 0x7084918a: 41 8d 74 24 03 leal 3(%r12), %esi
> 0x7084918f: 81 e6 00 fc ff ffandl $0xfc00, %esi
> 0x70849195: 3b 77 04 cmpl 4(%rdi), %esi
> 0x70849198: 41 8b f4 movl %r12d, %esi
> 0x7084919b: 0f 85 74 02 00 00jne 0x70849415
> 0x708491a1: 48 03 77 10 addq 0x10(%rdi), %rsi
> 0x708491a5: 44 89 2e movl %r13d, (%rsi)
> 0x708491a8: 83 c3 04 addl $4, %ebx
> 0x708491ab: 44 8b e3 movl %ebx, %r12d
> 0x708491ae: 44 8b 6d 10 movl 0x10(%rbp), %r13d
> 0x708491b2: 41 8b fc movl %r12d, %edi
> 0x708491b5: c1 ef 05 shrl $5, %edi
> 0x708491b8: 23 7d 80 andl -0x80(%rbp), %edi
> 0x708491bb: 48 03 7d 88 addq -0x78(%rbp), %rdi
> 0x708491bf: 41 8d 74 24 03 leal 3(%r12), %esi
> 0x708491c4: 81 e6 00 fc ff ffandl $0xfc00, %esi
> 0x708491ca: 3b 77 04 cmpl 4(%rdi), %esi
> 0x708491cd: 41 8b f4
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
Actually the ELF generates the .bin file which is being used to run on the
target (hardware). It's address starts from zero when I see the starting
frames of it. As follows:
IN:
0x0002: c0de stm r0!, {r1, r2, r3, r4, r6, r7}
0x0004: 0003 movs r3, r0
0x0006: movs r0, r0
0x0008: 0001 movs r1, r0
0x000a: movs r0, r0
0x000c: 0002 movs r2, r0
0x000e: movs r0, r0
0x0010: 0168 lsls r0, r5, #5
0x0012: movs r0, r0
0x0014: 5838 ldr r0, [r7, r0]
0x0016: movs r0, r0
0x0018: movs r0, r0
0x001a: movs r0, r0
0x001c: ac8e add r4, sp, #0x238
0x001e: 48d4 ldr r0, [pc, #0x350]
0x0020: 39bb subs r1, #0xbb
0x0022: 421b tst r3, r3
0x0024: 3db7 subs r5, #0xb7
0x0026: 5d30 ldrb r0, [r6, r4]
0x0028: 79df ldrb r7, [r3, #7]
0x002a: fcf6 6a34 ldc2lp10, c6, [r6], #0xd0
OUT: [size=1040]
0x70849100: 8b 5d f0 movl -0x10(%rbp), %ebx
0x70849103: 85 dbtestl%ebx, %ebx
0x70849105: 0f 8c cb 02 00 00jl 0x708493d6
0x7084910b: 8b 5d 04 movl 4(%rbp), %ebx
0x7084910e: 44 8b 65 00 movl (%rbp), %r12d
0x70849112: 41 8b fc movl %r12d, %edi
0x70849115: c1 ef 05 shrl $5, %edi
0x70849118: 23 7d 80 andl -0x80(%rbp), %edi
0x7084911b: 48 03 7d 88 addq -0x78(%rbp), %rdi
0x7084911f: 41 8d 74 24 03 leal 3(%r12), %esi
0x70849124: 81 e6 00 fc ff ffandl $0xfc00, %esi
0x7084912a: 3b 77 04 cmpl 4(%rdi), %esi
0x7084912d: 41 8b f4 movl %r12d, %esi
0x70849130: 0f 85 ac 02 00 00jne 0x708493e2
0x70849136: 48 03 77 10 addq 0x10(%rdi), %rsi
0x7084913a: 89 1emovl %ebx, (%rsi)
0x7084913c: 41 8d 5c 24 04 leal 4(%r12), %ebx
0x70849141: 44 8b e3 movl %ebx, %r12d
0x70849144: 44 8b 6d 08 movl 8(%rbp), %r13d
0x70849148: 41 8b fc movl %r12d, %edi
0x7084914b: c1 ef 05 shrl $5, %edi
0x7084914e: 23 7d 80 andl -0x80(%rbp), %edi
0x70849151: 48 03 7d 88 addq -0x78(%rbp), %rdi
0x70849155: 41 8d 74 24 03 leal 3(%r12), %esi
0x7084915a: 81 e6 00 fc ff ffandl $0xfc00, %esi
0x70849160: 3b 77 04 cmpl 4(%rdi), %esi
0x70849163: 41 8b f4 movl %r12d, %esi
0x70849166: 0f 85 8f 02 00 00jne 0x708493fb
0x7084916c: 48 03 77 10 addq 0x10(%rdi), %rsi
0x70849170: 44 89 2e movl %r13d, (%rsi)
0x70849173: 83 c3 04 addl $4, %ebx
0x70849176: 44 8b e3 movl %ebx, %r12d
0x70849179: 44 8b 6d 0c movl 0xc(%rbp), %r13d
0x7084917d: 41 8b fc movl %r12d, %edi
0x70849180: c1 ef 05 shrl $5, %edi
0x70849183: 23 7d 80 andl -0x80(%rbp), %edi
0x70849186: 48 03 7d 88 addq -0x78(%rbp), %rdi
0x7084918a: 41 8d 74 24 03 leal 3(%r12), %esi
0x7084918f: 81 e6 00 fc ff ffandl $0xfc00, %esi
0x70849195: 3b 77 04 cmpl 4(%rdi), %esi
0x70849198: 41 8b f4 movl %r12d, %esi
0x7084919b: 0f 85 74 02 00 00jne 0x70849415
0x708491a1: 48 03 77 10 addq 0x10(%rdi), %rsi
0x708491a5: 44 89 2e movl %r13d, (%rsi)
0x708491a8: 83 c3 04 addl $4, %ebx
0x708491ab: 44 8b e3 movl %ebx, %r12d
0x708491ae: 44 8b 6d 10 movl 0x10(%rbp), %r13d
0x708491b2: 41 8b fc movl %r12d, %edi
0x708491b5: c1 ef 05 shrl $5, %edi
0x708491b8: 23 7d 80 andl -0x80(%rbp), %edi
0x708491bb: 48 03 7d 88 addq -0x78(%rbp), %rdi
0x708491bf: 41 8d 74 24 03 leal 3(%r12), %esi
0x708491c4: 81 e6 00 fc ff ffandl $0xfc00, %esi
0x708491ca: 3b 77 04 cmpl 4(%rdi), %esi
0x708491cd: 41 8b f4 movl %r12d, %esi
0x708491d0: 0f 85 59 02 00 00jne 0x7084942f
0x708491d6: 48 03 77 10 addq 0x10(%rdi), %rsi
0x708491da: 44 89 2e movl %r13d, (%rsi)
0x708491dd: 83 c3 04 addl $4, %ebx
0x708491e0: 44 8b e3
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 30 Sept 2021 at 07:17, abhijeet inamdar wrote: > > But this very ELF file runs on the target(real hardware) perfectly. So how > different should it be to emulate? Real hardware doesn't have a magic ELF file loader. The details of what a debug environment or whatever mechanism you're using to put the ELF file on the target or an emulator expect from an ELF file vary. QEMU wants you to provide a vector table. (I imagine that the mechanism you're using with the real hardware starts execution at the ELF entry point.) -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
But this very ELF file runs on the target(real hardware) perfectly. So how different should it be to emulate? Thank you, Abhijeet. On Wed, Sep 29, 2021 at 10:31 PM Peter Maydell wrote: > On Wed, 29 Sept 2021 at 16:24, abhijeet inamdar > wrote: > > > > I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: > > 'int,exec,cpu' are probably also helpful. > > > [New Thread 0x7fffe700 (LWP 44283)] > > > > IN: > > 0x: andeqr0, r0, r0 > > We started at address 0 in not-thumb mode. Your ELF file is > almost certainly not correct (ie it does not include a suitable > vector table for the CPU to get its reset PC and SP from). > > -- PMM >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Wed, 29 Sept 2021 at 16:24, abhijeet inamdar wrote: > > I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: 'int,exec,cpu' are probably also helpful. > [New Thread 0x7fffe700 (LWP 44283)] > > IN: > 0x: andeqr0, r0, r0 We started at address 0 in not-thumb mode. Your ELF file is almost certainly not correct (ie it does not include a suitable vector table for the CPU to get its reset PC and SP from). -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: PROLOGUE: [size=45] 0x70849000: 55 pushq%rbp 0x70849001: 53 pushq%rbx 0x70849002: 41 54pushq%r12 0x70849004: 41 55pushq%r13 0x70849006: 41 56pushq%r14 0x70849008: 41 57pushq%r15 0x7084900a: 48 8b ef movq %rdi, %rbp 0x7084900d: 48 81 c4 78 fb ff ff addq $-0x488, %rsp 0x70849014: ff e6jmpq *%rsi 0x70849016: 33 c0xorl %eax, %eax 0x70849018: 48 81 c4 88 04 00 00 addq $0x488, %rsp 0x7084901f: c5 f8 77 vzeroupper 0x70849022: 41 5fpopq %r15 0x70849024: 41 5epopq %r14 0x70849026: 41 5dpopq %r13 0x70849028: 41 5cpopq %r12 0x7084902a: 5b popq %rbx 0x7084902b: 5d popq %rbp 0x7084902c: c3 retq [New Thread 0x7fffe700 (LWP 44283)] IN: 0x: andeqr0, r0, r0 OUT: [size=64] 0x70849100: 8b 5d f0 movl -0x10(%rbp), %ebx 0x70849103: 85 dbtestl%ebx, %ebx 0x70849105: 0f 8c 1f 00 00 00jl 0x7084912a 0x7084910b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) 0x70849112: 48 8b fd movq %rbp, %rdi 0x70849115: be 12 00 00 00 movl $0x12, %esi 0x7084911a: ba 00 00 00 02 movl $0x200, %edx 0x7084911f: b9 01 00 00 00 movl $1, %ecx 0x70849124: ff 15 0e 00 00 00callq*0xe(%rip) 0x7084912a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax 0x70849131: e9 e2 fe ff ff jmp 0x70849018 0x70849136: 90 nop 0x70849137: 90 nop 0x70849138: .quad 0x55a70e01 IN: 0x: andeqr0, r0, r0 OUT: [size=64] 0x70849240: 8b 5d f0 movl -0x10(%rbp), %ebx 0x70849243: 85 dbtestl%ebx, %ebx 0x70849245: 0f 8c 1f 00 00 00jl 0x7084926a 0x7084924b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) 0x70849252: 48 8b fd movq %rbp, %rdi 0x70849255: be 12 00 00 00 movl $0x12, %esi 0x7084925a: ba 00 00 00 02 movl $0x200, %edx 0x7084925f: b9 01 00 00 00 movl $1, %ecx 0x70849264: ff 15 0e 00 00 00callq*0xe(%rip) 0x7084926a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax 0x70849271: e9 a2 fd ff ff jmp 0x70849018 0x70849276: 90 nop 0x70849277: 90 nop 0x70849278: .quad 0x55a70e01 qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00= R01= R02= R03= R04= R05= R06= R07= R08= R09= R10= R11= R12= R13=ffe0 R14=fff9 R15= XPSR=4003 -Z-- A handler FPSCR: Thread 3 "qemu-system-arm" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe700 (LWP 44283)] 0x75f31438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) n [Thread 0x7fffe700 (LWP 44283) exited] [Thread 0x73049700 (LWP 44282) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) it aborts in the next step only. How can I proceed? Thank you, Abhijeet. On Fri, Sep 17, 2021 at 11:11 AM Peter Maydell wrote: > On Thu, 16 Sept 2021 at 20:13, abhijeet inamdar > > wrote: > > > > Is there any way/s to check where actually is it failing or point which > file? > > Use the usual debugging facilities -- gdbstub or -d debug logging. > > -- PMM >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 16 Sept 2021 at 20:13, abhijeet inamdar wrote: > > Is there any way/s to check where actually is it failing or point which file? Use the usual debugging facilities -- gdbstub or -d debug logging. -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
Is there any way/s to check where actually is it failing or point which file? Thank you, Abhijeet. On Thu, Sep 16, 2021 at 8:49 PM Peter Maydell wrote: > On Thu, 16 Sept 2021 at 19:46, Peter Maydell > wrote: > > > > On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar > > wrote: > > > How do I fix it ? it's for cortex-m3 and the below is the gdb trace > when I load ELF. > > > > > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority > -1) > > > > > > R00= R01= R02= R03= > > > R04= R05= R06= R07= > > > R08= R09= R10= R11= > > > R12= R13=ffe0 R14=fff9 R15= > > > XPSR=4003 -Z-- A handler > > > FPSCR: > > > This particular case is "we needed to take a HardFault exception, > > but we were already in a HardFault exception". The most common > > cause of this is that your code has crashed hard on startup > > (eg it tries to read from unreadable memory or jumps off into nowhere: > > if this happens before it has set up exception handling for HardFault > > then you get this. This also happens if its attempt to handle > > HardFaults is buggy and crashes.) > > Oh, and note that the PC is zero and the Thumb bit is not set: > this means that your guest code did something that caused the > CPU to try to take an exception, but your ELF file didn't > provide an exception vector table, and so the vector table > entry for the exception was 0. That means that the CPU will > attempt to execute from address 0 with the Thumb bit clear, > which provokes an immediate UsageFault exception, usually leading > to the exception-in-an-exception Lockup case above. > > -- PMM >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 16 Sept 2021 at 19:46, Peter Maydell wrote: > > On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar > wrote: > > How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I > > load ELF. > > > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > > > R00= R01= R02= R03= > > R04= R05= R06= R07= > > R08= R09= R10= R11= > > R12= R13=ffe0 R14=fff9 R15= > > XPSR=4003 -Z-- A handler > > FPSCR: > This particular case is "we needed to take a HardFault exception, > but we were already in a HardFault exception". The most common > cause of this is that your code has crashed hard on startup > (eg it tries to read from unreadable memory or jumps off into nowhere: > if this happens before it has set up exception handling for HardFault > then you get this. This also happens if its attempt to handle > HardFaults is buggy and crashes.) Oh, and note that the PC is zero and the Thumb bit is not set: this means that your guest code did something that caused the CPU to try to take an exception, but your ELF file didn't provide an exception vector table, and so the vector table entry for the exception was 0. That means that the CPU will attempt to execute from address 0 with the Thumb bit clear, which provokes an immediate UsageFault exception, usually leading to the exception-in-an-exception Lockup case above. -- PMM
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar wrote: > How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I > load ELF. > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > R00= R01= R02= R03= > R04= R05= R06= R07= > R08= R09= R10= R11= > R12= R13=ffe0 R14=fff9 R15= > XPSR=4003 -Z-- A handler > FPSCR: If the CPU goes into Lockup this indicates that something has gone very badly wrong with your guest code, and the situation is not recoverable. In real hardware the CPU sits there doing absolutely nothing forever more[*]. QEMU doesn't actually emulate the CPU being in Lockup state, so it just treats it as a fatal error. (Check the M-profile architecture reference for more information on Lockup and the various kinds of guest bug that can get you there.) This particular case is "we needed to take a HardFault exception, but we were already in a HardFault exception". The most common cause of this is that your code has crashed hard on startup (eg it tries to read from unreadable memory or jumps off into nowhere: if this happens before it has set up exception handling for HardFault then you get this. This also happens if its attempt to handle HardFaults is buggy and crashes.) You should approach this by debugging your guest and looking at what it is doing before it gets to this point. [*] Technically there are ways to get yourself out of Lockup state on a real CPU, such as having an external watchdog that resets the CPU, or some extremely esoteric tricks used only by code that's trying to test how Lockup state behaves. -- PMM
