[haiku-gsoc] Re: [ARM port] Fixing KDL memory access fault when printing the backtrace
- From: Arvind S Raj <sraj.arvind@xxxxxxxxx>
- To: haiku-gsoc <haiku-gsoc@xxxxxxxxxxxxx>
- Date: Tue, 12 Aug 2014 20:01:49 +0530
Hello Ithamar,
On 12 August 2014 19:47, Ithamar R. Adema <ithamar@xxxxxxxxxxxxxxxxxxx> wrote:
> 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.
Ah I see. Should I investigate exception handlers or simply use the
difference check and try to move things ahead? This is the last week
of GSoC work so what would be the best thing to do :)?
> Way to go to get the kdebug> prompt though, tried any KDL hangman yet? ;)
Well I don't know what KDL hangman is :) - did someone implement
hangman in KDL(can't be but just getting the obvious possibility out
of the way)? Also, I'm not sure if I can since there seem to be no
commands registered in KDL('Unknown command "help". Enter "help" to
get a list of all supported commands.'). I suspect it's probably
because KDL was arrived via panic and thus no commands are registered.
I didn't investigate it much after that since I was investigating the
double spinlock acquire which caused the KDL.
Other related posts:
