[U-Boot] [RFC] Analyzing data abort in EFI payload

[Alexander Graf]

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