[U-Boot] [PATCH v2 1/1] arm: print instructions pointed to by pc
If an exception occurs in a loaded image and the relocation offset is unknown, it is helful to know the instructions pointed to by the program counter. This patch adds the missing output.
A possible output is: *pc: fb de f7 e7 1e ff 2f e1 01 00 50 e3 f0 4d 2d e9 01 80 a0 e1
The output can be disassembled with xxd -pc -r - > a.out $(CROSS_COMPILE)objdump -D -marm -b binary a.out
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- v2 print bytes not halfwords --- arch/arm/lib/interrupts.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c index 28ba3f14f36..25489e34462 100644 --- a/arch/arm/lib/interrupts.c +++ b/arch/arm/lib/interrupts.c @@ -59,6 +59,9 @@ static void show_efi_loaded_images(struct pt_regs *regs) void show_regs (struct pt_regs *regs) { unsigned long __maybe_unused flags; + /* The least significant bit chooses thumb, remove it. */ + u8 *pc = (u8 *)(instruction_pointer(regs) & ~1); + int i; const char __maybe_unused *processor_modes[] = { "USER_26", "FIQ_26", "IRQ_26", "SVC_26", "UK4_26", "UK5_26", "UK6_26", "UK7_26", @@ -96,6 +99,10 @@ void show_regs (struct pt_regs *regs) fast_interrupts_enabled (regs) ? "on" : "off", processor_modes[processor_mode (regs)], thumb_mode (regs) ? " (T)" : ""); + printf("*pc:"); + for (i = 0; i < 24; ++i) + printf(" %02x", pc[i]); + printf("\n"); }
/* fixup PC to point to the instruction leading to the exception */
Hi,
On Thu, 10 May 2018 16:38:30 +0200 Heinrich Schuchardt xypron.glpk@gmx.de wrote:
If an exception occurs in a loaded image and the relocation offset is unknown, it is helful to know the instructions pointed to by the program counter. This patch adds the missing output.
A possible output is: *pc: fb de f7 e7 1e ff 2f e1 01 00 50 e3 f0 4d 2d e9 01 80 a0 e1
The output can be disassembled with xxd -pc -r - > a.out $(CROSS_COMPILE)objdump -D -marm -b binary a.out
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
v2 print bytes not halfwords
Note that Linux already comes with a scripts/decodecode tool where you paste the output of an Oops and it disassembles the "Code: " line from the dump. So I'd vote for importing scripts/decodecode from Linux and making U-Boot's output compatible with Linux.
On 05/13/2018 02:22 PM, Tuomas Tynkkynen wrote:
Hi,
On Thu, 10 May 2018 16:38:30 +0200 Heinrich Schuchardt xypron.glpk@gmx.de wrote:
If an exception occurs in a loaded image and the relocation offset is unknown, it is helful to know the instructions pointed to by the program counter. This patch adds the missing output.
A possible output is: *pc: fb de f7 e7 1e ff 2f e1 01 00 50 e3 f0 4d 2d e9 01 80 a0 e1
The output can be disassembled with xxd -pc -r - > a.out $(CROSS_COMPILE)objdump -D -marm -b binary a.out
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
v2 print bytes not halfwords
Note that Linux already comes with a scripts/decodecode tool where you paste the output of an Oops and it disassembles the "Code: " line from the dump. So I'd vote for importing scripts/decodecode from Linux and making U-Boot's output compatible with Linux.
Sounds good.
btw if you get exception because the memory at PC is inaccessible, this will trigger a double-fault I think.
On 13.05.18 16:45, Marek Vasut wrote:
On 05/13/2018 02:22 PM, Tuomas Tynkkynen wrote:
Hi,
On Thu, 10 May 2018 16:38:30 +0200 Heinrich Schuchardt xypron.glpk@gmx.de wrote:
If an exception occurs in a loaded image and the relocation offset is unknown, it is helful to know the instructions pointed to by the program counter. This patch adds the missing output.
A possible output is: *pc: fb de f7 e7 1e ff 2f e1 01 00 50 e3 f0 4d 2d e9 01 80 a0 e1
The output can be disassembled with xxd -pc -r - > a.out $(CROSS_COMPILE)objdump -D -marm -b binary a.out
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
v2 print bytes not halfwords
Note that Linux already comes with a scripts/decodecode tool where you paste the output of an Oops and it disassembles the "Code: " line from the dump. So I'd vote for importing scripts/decodecode from Linux and making U-Boot's output compatible with Linux.
Sounds good.
btw if you get exception because the memory at PC is inaccessible, this will trigger a double-fault I think.
Yes, but it will only trigger it at the end of the handler at which point we're panicking anyways, no?
Alex
On 05/24/2018 10:57 AM, Alexander Graf wrote:
On 13.05.18 16:45, Marek Vasut wrote:
On 05/13/2018 02:22 PM, Tuomas Tynkkynen wrote:
Hi,
On Thu, 10 May 2018 16:38:30 +0200 Heinrich Schuchardt xypron.glpk@gmx.de wrote:
If an exception occurs in a loaded image and the relocation offset is unknown, it is helful to know the instructions pointed to by the program counter. This patch adds the missing output.
A possible output is: *pc: fb de f7 e7 1e ff 2f e1 01 00 50 e3 f0 4d 2d e9 01 80 a0 e1
The output can be disassembled with xxd -pc -r - > a.out $(CROSS_COMPILE)objdump -D -marm -b binary a.out
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
v2 print bytes not halfwords
Note that Linux already comes with a scripts/decodecode tool where you paste the output of an Oops and it disassembles the "Code: " line from the dump. So I'd vote for importing scripts/decodecode from Linux and making U-Boot's output compatible with Linux.
Sounds good.
btw if you get exception because the memory at PC is inaccessible, this will trigger a double-fault I think.
Yes, but it will only trigger it at the end of the handler at which point we're panicking anyways, no?
Linux prints the faulting function at the top.
participants (4)
-
Alexander Graf -
Heinrich Schuchardt -
Marek Vasut -
Tuomas Tynkkynen