On 28.03.18 14:15, Heinrich Schuchardt wrote:
I have an EFI payload which causes a data abort exception on arm32:
data abort pc : [<79e7afe6>] lr : [<79e7aff5>]
reloc pc : [<44f15fe6>] lr : [<44f15ff5>]
sp : 7af3a740 ip : 7efb0420 fp : 7af774f8
r10: 7af3a7f0 r9 : 7af44ed8 r8 : 7ef9b1d0
r7 : 00000000 r6 : 00000000 r5 : 7ef8af21 r4 : 7af774f8
r3 : 00000003 r2 : 79f2f040 r1 : 00000000 r0 : 79f2f079
Flags: Nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
"reloc pc" is calculated as instruction_pointer(regs) - gd->reloc_off
This relocation offset is the one used for U-Boot not the one used for the EFI payload.
When a data abort occurs we may have multiple loaded EFI images. For the analysis we need the offset, the start address, and the end address for each of these. Then we can determine to which image the PC points to and via the offset find the assembly instruction in the image file.
Printing this information when an image is started may destroy the screen content. Furthermore the screen may be cleared afterwards.
So the most appropriate time for printing the information would be when the abort occurs. If the memory is not corrupted we could loop over all loaded image handles and retrieve the information from there. We could call an efi function for this purpose right after show_regs(pt_regs) in arch/arm/lib/interrupts.c.
What is your view on this?
I think it's a great idea.
Alex