Skip to contentSkip to conversation

kgdb with linux-mips problem

DISCUSSION Shaolin Zhang 3 participants 5 messages Sep 19, 2001 MIPS

lore
Share & tools
lore
#0 lore raw

Hello ,

Now we have some problems in using kgdb to debug the Linux-mips kernel on IDT 79s334A board.

1.I enabled the kernel startup option kgdb=on to debug the kernel setup.
At first, the gdb on host pc connected to the target boards correctly. Then I use a few "n"(Next) command to debug the kernel, but the kernel
seems
to run out of my hands, as if I had executed some "c" command.
I use "set debug remote 1" command to see the packets gdb send&receive:
and find :
the gdb send a "c" packet to the stub at the end of packet sequence.

I guess that the gdb on the host pc send some wrong command , or it can't
get right info
to debug?

2.I want to debug some init_module function in module , like this :

int init_module(void)

{
    breakpoint(); // use the breakpoint function in kernel to get a break.
    my_functions();
}

When I insmod this module, it through exception 9 (breakpoint), then I run "bt"
command in gdb, but this time gdb report "can't find the start of function 0x....".
Is this a gdb problem or gdb stub problem? BTW, when I first bootup the kernel
and connect the gdb&stub ,the sample problem happened.

#1 lore raw

What version of GDB are you using? I recommend you get the current CVS snapshot and try again.

Quoted 35 lines · Shaolin Zhang

Hello ,

Now we have some problems in using kgdb to debug the Linux-mips kernel on IDT 79s334A board.

1.I enabled the kernel startup option kgdb=on to debug the kernel setup.
At first, the gdb on host pc connected to the target boards correctly. Then I use a few "n"(Next) command to debug the kernel, but the kernel
seems
to run out of my hands, as if I had executed some "c" command.
I use "set debug remote 1" command to see the packets gdb send&receive:
and find :
the gdb send a "c" packet to the stub at the end of packet sequence.

I guess that the gdb on the host pc send some wrong command , or it can't
get right info
to debug?

2.I want to debug some init_module function in module , like this :

int init_module(void)

{
    breakpoint(); // use the breakpoint function in kernel to get a break.
    my_functions();
}

When I insmod this module, it through exception 9 (breakpoint), then I run "bt"
command in gdb, but this time gdb report "can't find the start of function 0x....".
Is this a gdb problem or gdb stub problem? BTW, when I first bootup the kernel
and connect the gdb&stub ,the sample problem happened.

Signature · 2 lines
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
#2 lore raw

My gcc verison is 2.95.3 19991030, gdb verison is 20000204. What is current version of bintuil and egcs,and where can i get it ? thanks.

----- Original Message -----
From: "Daniel Jacobowitz" <[email protected]>
To: "Shaolin Zhang" <[email protected]>
Cc: <[email protected]>; "Ernest Jih" <[email protected]>; "recc stone" <[email protected]>
Sent: Wednesday, September 19, 2001 10:46 AM
Subject: Re: kgdb with linux-mips problem

Quoted 43 lines

What version of GDB are you using? I recommend you get the current CVS snapshot and try again.

Quoted 35 lines · Shaolin Zhang

Hello ,

Now we have some problems in using kgdb to debug the Linux-mips kernel on IDT 79s334A board.

1.I enabled the kernel startup option kgdb=on to debug the kernel setup.
At first, the gdb on host pc connected to the target boards correctly. Then I use a few "n"(Next) command to debug the kernel, but the kernel
seems
to run out of my hands, as if I had executed some "c" command.
I use "set debug remote 1" command to see the packets gdb send&receive:
and find :
the gdb send a "c" packet to the stub at the end of packet sequence.

I guess that the gdb on the host pc send some wrong command , or it can't
get right info
to debug?

2.I want to debug some init_module function in module , like this :

int init_module(void)

{
    breakpoint(); // use the breakpoint function in kernel to get a break.
    my_functions();
}

When I insmod this module, it through exception 9 (breakpoint), then I run "bt"
command in gdb, but this time gdb report "can't find the start of function 0x....".
Is this a gdb problem or gdb stub problem? BTW, when I first bootup the kernel
and connect the gdb&stub ,the sample problem happened.

Signature · 2 lines
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
#3 lore raw
Quoted 3 lines · Shaolin Zhang

My gcc verison is 2.95.3 19991030, gdb verison is 20000204. What is current version of bintuil and egcs,and where can i get it ? thanks.

From gcc.gnu.org/sources.redhat.com. The one you'll really need to update is GDB: sources.redhat.com/pub/gdb/, I think, and look for a snapshot from the past few weeks.

I highly recommend you use an existing toolchain - MontaVista's (www.mvista.com, look for Journeyman) or H.J. Lu's (don't know the URL offhand).

Signature · 2 lines
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
#4 lore raw
In reply to Shaolin Zhang

I'm not 100% sure about where your first problem is coming from,but you should not be too surprised that gdb is sending a continue message as part of implementing the "next" command. The gdb kernel agent has no idea what the composition of the source code would be - that's up to gdb. Gdb implements commands like "next" by computing a breakpoint address, setting an (internal) breakpoint, and telling the agent to resume execution, presumably with a "c" packet.

This problem *may* be linked with the second you describe, which is one I know well. While this may have been fixed in more recent versions of gdb, the last time I used kgdb for MIPS, it was certainly the case that gdb looked for text (code) symbols *only* in the *.text* section of the kernel image. All of the init_module functions are grouped together in a seperate (".init_text" or something like that) section of the file. They need to be loaded together in a seperate hunk of memory, after all. That causes the backtrace problem you describe on a compiled-in breakpoint, and makes it very tricky to dynamically set breakpoints in the init modules. I remember that I had to set them, not by symbol, but by hex address after having manually dumped the kernel symbol table. This situation could also explain why doing a "next" command while the kernel is still executing in init modules is causing bad behavior.

This, along with some other bugs that are fatal to the kernel during kgdb sessions, should have been fixed in gdb long ago, but I don't know that they ever were. When I was using it, I was in sufficiently desperate need of *something* that I accepted doing a lot of painful procedural work-arounds.

Kevin K.

----- Original Message -----
From: "Shaolin Zhang" <[email protected]>
To: <[email protected]>
Cc: "Ernest Jih" <[email protected]>; ""recc stone"" <[email protected]>
Sent: Wednesday, September 19, 2001 4:42 AM
Subject: kgdb with linux-mips problem

Quoted 3 lines

Hello ,

Now we have some problems in using kgdb to debug the Linux-mips kernel

on IDT 79s334A board.

Quoted 11 lines

1.I enabled the kernel startup option kgdb=on to debug the kernel setup.
At first, the gdb on host pc connected to the target boards correctly. Then I use a few "n"(Next) command to debug the kernel, but the kernel
seems
to run out of my hands, as if I had executed some "c" command.
I use "set debug remote 1" command to see the packets gdb send&receive:
and find :
the gdb send a "c" packet to the stub at the end of packet sequence.

I guess that the gdb on the host pc send some wrong command , or it

can't

Quoted 21 lines

get right info
to debug?

2.I want to debug some init_module function in module , like this :

int init_module(void)

{
    breakpoint(); // use the breakpoint function in kernel to get a break.
    my_functions();
}

When I insmod this module, it through exception 9 (breakpoint), then I run "bt"
command in gdb, but this time gdb report "can't find the start of function 0x....".
Is this a gdb problem or gdb stub problem? BTW, when I first bootup the kernel
and connect the gdb&stub ,the sample problem happened.