[haiku-gsoc] Re: [ARM port] Fixing KDL memory access fault when printing the backtrace
- From: "Ithamar R. Adema" <ithamar@xxxxxxxxxxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 12 Aug 2014 10:17:43 -0400
Hi Arvind,
On Tue, Aug 12, 2014 at 10:10 AM, Arvind S Raj <sraj.arvind@xxxxxxxxx>
wrote:
> Hello everyone,
> Currently, KDL faults because the termination condition when printing
> the backtrace is incorrect(it merely checks if the frame pointer is
> not 0 and doesn't check if the location is accessible). The x86 code
> uses debug_memcpy(which I suppose has a fault handler) but it doesn't
> work on ARM - the memcpy call faults and doesn't seem to pass control
> onto the fault handler(if there is one).
>
> Additionally, debug_memcpy displays arch_start_kernel(which invokes
> the kernel) and it's callers in the backtrace. Should those callers
> also be displayed or should the backtrace stop at _start(kernel
> entry)? If the ones before kernel entry needn't be displayed, then
> debug_memcpy won't work in it's current state and would require some
> fixing specifically for ARM. Ideally, I think modifying get_next_frame
> to do something ARM specific would be the best solution; even not
> invoking debug_memcpy is probably fine unless uniformity across all
> archs needs to be maintained.
>
> As a temporary workaround, I added a check in get_next_frame to ensure
> that the difference between the pointer to the current frame and that
> of the previous do not differ by greater than 0x100000, which seems to
> work because I get a 'kdebug>" prompt.
>
I suspect our exception handling is broken to start with, it was never
tested for anything else then ARMv5. If that is the case, then the fault
handler handling will be broken too. I suspect that's what you are seeing.
Way to go to get the kdebug> prompt though, tried any KDL hangman yet? ;)
Ithamar.
Other related posts:
