George Anzinger wrote:
Lance Spaulding wrote:
Thanks guys. Breakpoints are working now with these checks compiled
out. I'd still like to know if single-stepping is supposed to be
working or not. I added some code to print out the packets sent
between gdb and kgdb and it looks like gdb sends a 's' packet which
kgdb ignores and sends back an empty reply. gdb is hung after that.
Here's a cut-and-paste of the last few packets up to the hang:
outgoing kgdb packet: [f0df2de9]
incoming kgdb packet: [m834e8,4]
outgoing kgdb packet: [04b04ce2]
incoming kgdb packet: [m834ec,4]
outgoing kgdb packet: [54d04de2]
incoming kgdb packet: [m834f0,4]
outgoing kgdb packet: [34000be5]
incoming kgdb packet: [m834f4,4]
outgoing kgdb packet: [38100be5]
incoming kgdb packet: [m834f8,4]
outgoing kgdb packet: [3c200be5]
incoming kgdb packet: [Hc1]
outgoing kgdb packet: [OK]
incoming kgdb packet: [s]
outgoing kgdb packet: []
Should this work? In looking at the code, it appears that 's' isn't
supported but I assume others are single-stepping so what am I
missing? Do I need a specific version of gdb for this to work?
case 's':
if (kgdb_contthread && kgdb_contthread != current) {
/* Can't switch threads in kgdb */
error_packet(remcom_out_buffer, -EINVAL);
break;
}
/* Followthrough to default processing */
default:
You stopped a few lines short. I suspect that the default is to hand
it off to the arch part of kgdb to do the actual step code. Once the
"s" is sent, gdb expects the next reply to be notice of an exception,
i.e. a breakpoint, single step completion, what ever.
For what its worth, you can get these packets from the gdb side by doing:
set debug remote 1
(a lot easier than puting in printks...)
George
Sorry about that. I meant to include the rest but somehow forgot. The
'default' section calls kgdb_arch_handle_exception() which doesn't
appear to handle the 's' command as shown below:
int kgdb_arch_handle_exception(int exception_vector, int signo,
int err_code, char *remcom_in_buffer,
char *remcom_out_buffer,
struct pt_regs *linux_regs)
{
long addr;
char *ptr;
switch (remcom_in_buffer[0]) {
case 'c':
kgdb_contthread = NULL;
/*
* Try to read optional parameter, pc unchanged if no parm.
* If this was a compiled breakpoint, we need to move
* to the next instruction or we will just breakpoint
* over and over again.
*/
ptr = &remcom_in_buffer[1];
if (kgdb_hex2long(&ptr, &addr)) {
linux_regs->ARM_pc = addr;
} else if (compiled_break == 1) {
linux_regs->ARM_pc += 4;
}
compiled_break = 0;
return 0;
}
return -1;
}
Is single-stepping supposed to work on ARM platforms in the current
version of kgdb?
Also, thanks for the pointer on printing the commands -- much easier.
Thanks,
Lance
Thanks in advance,
Lance
George Anzinger wrote:
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
