Re: [kdb] kdb patch for 2.6.24 and ARMv7

[Basavaraj Dengi <basavarajdengi@xxxxxxxxx>]

Hi Jason,

 

Thanks for your reply. 

 

I am more interested in kdb because,

 

It does not required any tools[except for heperterminal] on host side [kgdb requires a linux pc]

Will enter automatically on kernel crash/panic and gives option to dump some memory area.

 

And to me

Single stepping is not on the list.

Dis-assembly is of lower priority.

 

And

Kdump requires configuration of another kernel.

So kdb and lkcd look to suit our situation. And I have started with kdb and I am yet investigate more on lkcd.

 

Thanks once again for your reply.

 

Regards

Basavaraj

 

 

 

 

On Fri, Jun 12, 2009 at 11:16 PM, Jason Wessel <jason.wessel@xxxxxxxxxxxxx> wrote:

Martin Hicks wrote:
> On Fri, Jun 12, 2009 at 06:00:46PM +0900, Basavaraj Dengi wrote:
>
>> Hi,
>>
>> After applying below patches
>> kdb-v4.4-2.6.24-common-2.bz2
>> kdb-v4.3-2.4.20-xscale-1.bz2
>>
>
> Are you really applying these two different patches?
> I really don't know what major changes happened between v4.3 and 4.4,
> but I'm not really shocked that things don't work.
>
> You might be on your own to get this working again.
> Jason Wessel has been working on getting KB to function as a front-end
> for KGDB.  He posted patches to LKML about a month ago.  They might be
> of interest to you.
>
>

I doubt the whole armv7 instruction set was in the old xscale patch.

In terms of the patch set Martin mentioned, the kdb front end code does
happen to work on ARM, but I had extra patches which I did not publish
which contained the logic for software single stepping on ARM.  The
reason these were never published is that whole mess deserves a complete
re-write.  There are traps that get placed and removed and ugly extra
exception logic in place.

The right way to implement single stepping is to use the concept of out
of line instruction emulation such that you can execute the instruction
equivalent on a particular kernel thread and the final instruction would
be a trap to indicate the end of the out of line instruction execution.

This allows you to do things like leave a breakpoint planted or truly
single step an individual kernel thread while not planting a breakpoint
in shared kernel code.  This is a back burner project however at the
current time, unless someone else wants to contribute this logic or port
it from gdb.

You might be better served to consider using kgdboc + gdb, if you want
to do some instruction disassembly.

Jason.