using openocd + gdb to debug linux kernel on arm926ejs

using openocd + gdb to debug linux kernel on arm926ejs

[f. achkar]

hi,
This is my second posting (I'm not sure the first one passed the filter) sorry for that ...

I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
zImage, this image boots properly via u-boot-1.1.6, however I simply 
failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger.
is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?

details:
1. let u-boot start the board;
2. I get the u-boot command prompt:

# bdinfo
      arch_number = 0x00000648
      env_t       = 0x00000000
      boot_params = 0x30000100
      DRAM bank   = 0x00000000
      -> start    = 0x30000000
      -> size     = 0x04000000
      DRAM bank   = 0x00000001
      -> start    = 0x38000000
      -> size     = 0x04000000
      ethaddr     = 00:40:5C:26:0A:5B
      ip_addr     = 192.168.3.5
      baudrate    = 115200 bps

3. halt the target via openocd/telnet;
4. cd to root directory of linux source code and issue:
gdb vmlinux
GNU gdb (GDB) 6.8.50.20090417
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb)

5.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0xc3e01874 in ?? ()
0xc3e01874:    ldr    r3, [r0, #16]
(gdb)

6.
(gdb) set remote hardware-breakpoint-limit 2
(gdb) set remote hardware-watchpoint-limit 2

7.
(gdb) load
Loading section .init, size 0x7b000 lma 0xc0008000
Loading section .text, size 0x2bb618 lma 0xc0083000
Loading section __ksymtab, size 0x4a58 lma 0xc033f000
Loading section __ksymtab_gpl, size 0x1360 lma 0xc0343a58
Loading section __ksymtab_gpl_future, size 0x18 lma 0xc0344db8
Loading section __ksymtab_strings, size 0xcab7 lma 0xc0344dd0
Loading section __param, size 0x654 lma 0xc0351888
Loading section .data, size 0x21538 lma 0xc0352000
Start address 0xc0008000, load size 3582507
Transfer rate: 35 KB/sec, 15922 bytes/write.
(gdb)

8. if I do continue (gdb) c, then I don't see any output on the serial
console (as normally do during zImage booting process!)

where I'm messing up?

thanks,
ferar

using openocd + gdb to debug linux kernel on arm926ejs

[Steve Chen]

On Wed, May 26, 2010 at 2:12 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
> hi,
> This is my second posting (I'm not sure the first one passed the filter) sorry for that ...
>
> I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
> zImage, this image boots properly via u-boot-1.1.6, however I simply
> failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger.
> is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?

Actually, Nicolas Pitre posted an response in your first try.  In
summary, use uImage for uboot.  vmlinux won't work.

Regards,

Steve

using openocd + gdb to debug linux kernel on arm926ejs

[f. achkar]

On 05/26/2010 03:41 PM, Steve Chen wrote:
> On Wed, May 26, 2010 at 2:12 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
>   
>> hi,
>> This is my second posting (I'm not sure the first one passed the filter) sorry for that ...
>>
>> I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
>> zImage, this image boots properly via u-boot-1.1.6, however I simply
>> failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger.
>> is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?
>>     
> Actually, Nicolas Pitre posted an response in your first try.  In
> summary, use uImage for uboot.  vmlinux won't work.
>
> Regards,
>
> Steve
>   
Steve,
thanks,  I'm not sure I got what you mean!  if I do the following:
gdb arch/arm/boot/uImage
GNU gdb (GDB) 6.8.50.20090417
...
"/home/ferar/DW-SB02-linux-final/arch/arm/boot/uImage": not in
executable format: File format not recognized
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0xc0008164 in ?? ()
0xc0008164:    b    0xc0008160
(gdb) set remote hardware-breakpoint-limit 2
(gdb) set remote hardware-watchpoint-limit 2
(gdb) load
No executable file specified.
Use the "file" or "exec-file" command.

Note it is not executable format, I need to load and debug the kernel
not just boot (I don't have booting issues) I'm having trouble trying to
debug the kernel via jtag (openocd)  gdb as outlined in the detail part
of my previous post! I wonder if you people got that portion of the post?
thanks,
ferar

using openocd + gdb to debug linux kernel on arm926ejs

[Steve Chen]

On Wed, May 26, 2010 at 2:51 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
> On 05/26/2010 03:41 PM, Steve Chen wrote:
>> On Wed, May 26, 2010 at 2:12 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
>>
>>> hi,
>>> This is my second posting (I'm not sure the first one passed the filter) sorry for that ...
>>>
>>> I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
>>> zImage, this image boots properly via u-boot-1.1.6, however I simply
>>> failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger.
>>> is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?
>>>
>> Actually, Nicolas Pitre posted an response in your first try. ?In
>> summary, use uImage for uboot. ?vmlinux won't work.
>>
>> Regards,
>>
>> Steve
>>
> Steve,
> thanks, ?I'm not sure I got what you mean! ?if I do the following:
> gdb arch/arm/boot/uImage
> GNU gdb (GDB) 6.8.50.20090417
> ...
> "/home/ferar/DW-SB02-linux-final/arch/arm/boot/uImage": not in
> executable format: File format not recognized
> (gdb) target remote localhost:3333
> Remote debugging using localhost:3333
> 0xc0008164 in ?? ()
> 0xc0008164: ? ?b ? ?0xc0008160
> (gdb) set remote hardware-breakpoint-limit 2
> (gdb) set remote hardware-watchpoint-limit 2
> (gdb) load
> No executable file specified.
> Use the "file" or "exec-file" command.
>
> Note it is not executable format, I need to load and debug the kernel
> not just boot (I don't have booting issues) I'm having trouble trying to
> debug the kernel via jtag (openocd) ?gdb as outlined in the detail part
> of my previous post! I wonder if you people got that portion of the post?
> thanks,
> ferar
>

I have never used gdb to debug the kernel, so I'm not qualify to
answer your questions.  In general, if you need to use gdb (actually
more accurately kgdb), you need to something like

1.  Enable kgdb in the kernel config.
2.  Boot your kernel as usual.
3.  run cross-gdb on your host machine.
4.  Do remote debugging in gdb from your host via either serial or
Ethernet depends on how you have it configured.

Regards,

Steve

using openocd + gdb to debug linux kernel on arm926ejs

[f. achkar]

On 05/26/2010 04:11 PM, Steve Chen wrote:
> On Wed, May 26, 2010 at 2:51 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
>   
>> On 05/26/2010 03:41 PM, Steve Chen wrote:
>>     
>>> On Wed, May 26, 2010 at 2:12 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
>>>
>>>       
>>>> hi,
>>>> This is my second posting (I'm not sure the first one passed the filter) sorry for that ...
>>>>
>>>> I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
>>>> zImage, this image boots properly via u-boot-1.1.6, however I simply
>>>> failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger.
>>>> is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?
>>>>
>>>>         
>>> Actually, Nicolas Pitre posted an response in your first try.  In
>>> summary, use uImage for uboot.  vmlinux won't work.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>       
>> Steve,
>> thanks,  I'm not sure I got what you mean!  if I do the following:
>> gdb arch/arm/boot/uImage
>> GNU gdb (GDB) 6.8.50.20090417
>> ...
>> "/home/ferar/DW-SB02-linux-final/arch/arm/boot/uImage": not in
>> executable format: File format not recognized
>> (gdb) target remote localhost:3333
>> Remote debugging using localhost:3333
>> 0xc0008164 in ?? ()
>> 0xc0008164:    b    0xc0008160
>> (gdb) set remote hardware-breakpoint-limit 2
>> (gdb) set remote hardware-watchpoint-limit 2
>> (gdb) load
>> No executable file specified.
>> Use the "file" or "exec-file" command.
>>
>> Note it is not executable format, I need to load and debug the kernel
>> not just boot (I don't have booting issues) I'm having trouble trying to
>> debug the kernel via jtag (openocd)  gdb as outlined in the detail part
>> of my previous post! I wonder if you people got that portion of the post?
>> thanks,
>> ferar
>>
>>     
> I have never used gdb to debug the kernel, so I'm not qualify to
> answer your questions.  In general, if you need to use gdb (actually
> more accurately kgdb), you need to something like
>   
thanks Steve,
let say I'm 95% sure that if you have jtag you don't need kgdb you
simply use gdb through the IEEE 1149.1 standard (1990!). Also for you
information you can use the jtag for boundary scan which also quite
useful (I think ;-/ ).

I'm sure few intelligent humans on this form have the know-how, and hope
they share that with the rest of us.
best regards,
ferar
> 1.  Enable kgdb in the kernel config.
> 2.  Boot your kernel as usual.
> 3.  run cross-gdb on your host machine.
> 4.  Do remote debugging in gdb from your host via either serial or
> Ethernet depends on how you have it configured.
>
> Regards,
>
> Steve
>   

debugging kernel with gdb

[Jeff Hane]

Hello,

 I'm bringing up a new chip with an ARM1136 and trying to step thru the
code with gdb but because it's been optimized it's not working so well.
The code was being compiled with -O2 and -g.  I thought the obvious
thing to do is just change this to -O0 in the top level Makefile;
however this results in the following message.   

Error: selected processor does not support `ldrexb


 I'm trying to figure out if optimization can't be turned off or if I
have some issue with my toolchain. 

thanks,
jeff

debugging kernel with gdb

[Baurzhan Ismagulov]

On Wed, Jul 21, 2010 at 03:44:21PM -0700, Jeff Hane wrote:
> The code was being compiled with -O2 and -g.  I thought the obvious
> thing to do is just change this to -O0 in the top level Makefile;
> however this results in the following message.   

This doesn't work (I've never looked why) and is not supported.

With kind regards,
Baurzhan.

debugging kernel with gdb

[ikjn]

try -O1.
it's better

On Fri, Jul 23, 2010 at 2:15 AM, Baurzhan Ismagulov <ibr@radix50.net> wrote:
> On Wed, Jul 21, 2010 at 03:44:21PM -0700, Jeff Hane wrote:
>> The code was being compiled with -O2 and -g. ?I thought the obvious
>> thing to do is just change this to -O0 in the top level Makefile;
>> however this results in the following message.
>
> This doesn't work (I've never looked why) and is not supported.
>
> With kind regards,
> Baurzhan.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

using openocd + gdb to debug linux kernel on arm926ejs

[Kees Jongenburger]

Hello  Ferar,

On Wed, May 26, 2010 at 9:12 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
> I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
> zImage, this image boots properly via u-boot-1.1.6, however I simply
> failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger.
> is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?

Did you read
http://elinux.org/DebuggingTheLinuxKernelUsingGdb ?

>
> details:
> 1. let u-boot start the board;
> 2. I get the u-boot command prompt:
>
> 3. halt the target via openocd/telnet;

If you plan on replacing the kernel using gdb you need really to stop
at a known location
The moment you halt the target needs to be after memory initialization
and prior  to the kernel being loaded

> 4. cd to root directory of linux source code and issue:
> gdb vmlinux
> GNU gdb (GDB) 6.8.50.20090417
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. ?Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=arm-none-linux-gnueabi".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> (gdb)
>
> 5.
> (gdb) target remote localhost:3333
> Remote debugging using localhost:3333
> 0xc3e01874 in ?? ()
> 0xc3e01874: ? ?ldr ? ?r3, [r0, #16]
> (gdb)
Is this kernel code?

> 8. if I do continue (gdb) c, then I don't see any output on the serial
> console (as normally do during zImage booting process!)
>
> where I'm messing up?

First try just booting and connecting to the target afterwards. All
you really need is a vmlinuz so don't load the kernel over JTAG

Hope this helps

Greetings

using openocd + gdb to debug linux kernel on arm926ejs

[f. achkar]

On 05/26/2010 03:46 PM, Kees Jongenburger wrote:
> Hello  Ferar,
>
> On Wed, May 26, 2010 at 9:12 PM, f. achkar <fachkar.datawind@gmail.com> wrote:
>   
>> I'm newbie and have a s3c2450 based board (arm926ejs), I have a working compressed kernel image
>> zImage, this image boots properly via u-boot-1.1.6, however I simply
>> failed to debug remotely the vmlinux (root directory of linux source tree) via openocd-0.4.0 with a j-link segger.
>> is there a good reference on how to properly debug the linux kernel via openocd/gdb for an arm target on a linux hot machine?
>>     
> Did you read
> http://elinux.org/DebuggingTheLinuxKernelUsingGdb ?
>   
Yes and many other similar documents! and the steps below are based on
those readings :(
>   
>> details:
>> 1. let u-boot start the board;
>> 2. I get the u-boot command prompt:
>>
>> 3. halt the target via openocd/telnet;
>>     
> If you plan on replacing the kernel using gdb you need really to stop
> at a known location
> The moment you halt the target needs to be after memory initialization
> and prior  to the kernel being loaded
>   
yes I halt the target after memory initialization as done by uboot which
also prepares the tagged list required by the kernel @

boot_params = 0x30000100

>   
>> 4. cd to root directory of linux source code and issue:
>> gdb vmlinux
>> GNU gdb (GDB) 6.8.50.20090417
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "--host=i686-pc-linux-gnu
>> --target=arm-none-linux-gnueabi".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> (gdb)
>>
>> 5.
>> (gdb) target remote localhost:3333
>> Remote debugging using localhost:3333
>> 0xc3e01874 in ?? ()
>> 0xc3e01874:    ldr    r3, [r0, #16]
>> (gdb)
>>     
> Is this kernel code?
>   
I'm not sure, also not sure why gdb showed that particular memory location!
>   
>> 8. if I do continue (gdb) c, then I don't see any output on the serial
>> console (as normally do during zImage booting process!)
>>
>> where I'm messing up?
>>     
> First try just booting and connecting to the target afterwards. All
> you really need is a vmlinuz so don't load the kernel over JTAG
>   
do you mean the following steps:
1. arm-linux-gdb vmlinux
2.
target remote localhost:3333
set remote hardware-breakpoint-limit 2
set remote hardware-watchpoint-limit 2

3. reset the target and let u-boot/zImage finish running until I get the
bash# of busy box then try to insert break points as needed?

many thanks ...

> Hope this helps
>
> Greetings
>