Amit Kale wrote:
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.
If I recall correctly, this was a check to avoid the memory fault such an
access would create. Since we now correctly detect and recover from these
after the fact, I think this code should be removed. Am I remembering wrong
here?
George
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
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
--
George Anzinger george@xxxxxxxxxx
HRT (High-res-timers):
http://sourceforge.net/projects/high-res-timers/
-------------------------------------------------------
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
