Re: kgdb on arm for 2.6

Lance,

The TASK_SIZE check in kgdb prevents reading user memory when kgdb holds a 
kernel. User memory could be swapped out in case of MMU systems, so doing it 
from inside kgdb might cause a lockup if the page being refered to has to be 
brought in.

This check is not required on your platform since it doesn't have MMU.

TASK_SIZE should be set to the highest address a "user" process can have. Does 
this platform have "user" processes?
-Amit

On Tuesday 10 Jan 2006 4:25 am, Lance Spaulding wrote:
> Hi,
>
> I'm trying to get kgdb working on a custom non-MMU ARM-based platform
> but am running into problems.  I can add  a call to breakpoint() in the
> kernel and am able to connect with gdb/ddd but I cant step or resume
> execution once stopped.  I can view memory and registers, view the
> backtrace, etc so I know my custom serial code is working OK.  In trying
> to track down the breakpoint issue, I found that both kgdb_set_mem() and
> kgdb_get_mem() have the following lines:
>
>         if ((unsigned long)addr < TASK_SIZE)
>             return -EINVAL;
>
> I'm loading the kernel starting at address 0  so the address value being
> passed in is fairly small (my kernel image is only a couple meg).  On my
> platform, I wasn't sure what to set TASK_SIZE to so I copied what some
> other arm-based platforms have and set it to 0x01a00000UL.  This of
> course causes all get or set mem calls to fail.  If I comment-out these
> checks I can set the breakpoint correctly and continue to it.  I'm
> hoping someone can help me understand what this check is supposed to be
> doing and if I should be setting TASK_SIZE much smaller than I currently
> am.
>
> Also, at any breakpoint, if I try to execute a step/next, I always get
> "warning: Invalid remote reply:" returned.  Should this work on an ARM
> (nommu) platform?
>
> By the way, for reference, I'm using 2.6.14.3 with both the uc0 and hsc0
> patches applied in addition to all the current kgdb patches.
>
> Thanks,
> Lance
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Kgdb-bugreport mailing list
> Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click