Debugging a custom kernel

Debugging a custom kernel

[Christopher Harvey]

On 06/29/11 16:14, Apelete Seketeli wrote:
> Hello,
>
> I am working on a custom kernel, and I would like to add the necessary
> support to enable it to boot with qemu.
When you say "debug inside qemu", do you run
gdb qemu
or
gdb vmlinux
> In order to achieve that I am
> trying to debug it inside qemu by attaching a gdb to it.
you do this by adding -S -s to the qemu boot parameters.
the from the gdb shell, target remote :1234.
 > I still can't
> figure where the boot process is getting stuck with step-by-step
> execution, but it seems that the last function called is "delay_loop"
> from arch/x86/lib/delay.c.
Have you run the backtrace (bt) command from the gdb shell? That should 
tell you what function is calling the __delay.
> That function contains some assembly code, does someone know what it
> is supposed to do ?
Probably wait a specific amount of time. Since a compiler optimizes C 
you can't write an accurate delay in C. The compiler wont optimize the 
inline assembly.
> Beside, do you have any advice on the way I should proceed to get the
> necessary information to port the kernel ?
You should find an existing board and tweak it to get started, or post 
the backtrace output.
>
> Thanks.

Have you had any luck with a google search along the lines of "qemu gdb 
kernel"?

Debugging a custom kernel

[Apelete Seketeli]

Hello,

I am working on a custom kernel, and I would like to add the necessary
support to enable it to boot with qemu. In order to achieve that I am
trying to debug it inside qemu by attaching a gdb to it. I still can't
figure where the boot process is getting stuck with step-by-step
execution, but it seems that the last function called is "delay_loop"
from arch/x86/lib/delay.c.
That function contains some assembly code, does someone know what it
is supposed to do ?
Beside, do you have any advice on the way I should proceed to get the
necessary information to port the kernel ? 

Thanks.
-- 
        Apelete

Debugging a custom kernel

[Jonathan Neuschäfer]

On Wed, Jun 29, 2011 at 10:14:41PM +0200, Apelete Seketeli wrote:
> Hello,
> 
> I am working on a custom kernel, and I would like to add the necessary
> support to enable it to boot with qemu. In order to achieve that I am
> trying to debug it inside qemu by attaching a gdb to it. I still can't
> figure where the boot process is getting stuck with step-by-step
> execution, but it seems that the last function called is "delay_loop"
> from arch/x86/lib/delay.c.
> That function contains some assembly code, does someone know what it
> is supposed to do ?
> Beside, do you have any advice on the way I should proceed to get the
> necessary information to port the kernel ? 

Does a stock kernel work in your setup?
If so, try using its config, most distributions put it into /boot as
config-`uname -r` or something.

HTH,
	Jonathan Neusch?fer

Debugging a custom kernel

[Apelete Seketeli]

On 29-Jun-11, Christopher Harvey wrote:
> On 06/29/11 16:14, Apelete Seketeli wrote:
> > Hello,
> >
> > I am working on a custom kernel, and I would like to add the necessary
> > support to enable it to boot with qemu.
> When you say "debug inside qemu", do you run
> gdb qemu
> or
> gdb vmlinux

"gdb vmlinux" actually. The focus is on the kernel, to know what going
on during the boot process (since it doesn't boot in qemu).

> > In order to achieve that I am
> > trying to debug it inside qemu by attaching a gdb to it.
> you do this by adding -S -s to the qemu boot parameters.
> the from the gdb shell, target remote :1234.

"qemu -S -kernel bzImage", then, using the monitor inside qemu I start
a gdbserver to which I connect to debug the kernel.

>  > I still can't
> > figure where the boot process is getting stuck with step-by-step
> > execution, but it seems that the last function called is "delay_loop"
> > from arch/x86/lib/delay.c.
> Have you run the backtrace (bt) command from the gdb shell? That should 
> tell you what function is calling the __delay.

I didn't, will try that and see if it helps.

> > That function contains some assembly code, does someone know what it
> > is supposed to do ?
> Probably wait a specific amount of time. Since a compiler optimizes C 
> you can't write an accurate delay in C. The compiler wont optimize the 
> inline assembly.

Okay, so I really need to know which function is calling the delay and
go down from there.

> Have you had any luck with a google search along the lines of "qemu gdb 
> kernel"?

Running gdb with qemu caused me some headache, but I got it, as said
before. Thanks for the tips, I'll try and see if I can get something
useful.

-- 
        Apelete

Debugging a custom kernel

[Christopher Harvey]

On Wed, 29 Jun 2011 23:27:41 +0200, Apelete Seketeli wrote:
> On 29-Jun-11, Christopher Harvey wrote:
>> On 06/29/11 16:14, Apelete Seketeli wrote:
>>  > I still can't
>> > figure where the boot process is getting stuck with step-by-step
>> > execution, but it seems that the last function called is 
>> "delay_loop"
>> > from arch/x86/lib/delay.c.
>> Have you run the backtrace (bt) command from the gdb shell? That 
>> should
>> tell you what function is calling the __delay.
>
> I didn't, will try that and see if it helps.

That command is your bread and butter. If you type "up" into gdb it 
will take you to the line that called __delay. Keep typing up to see 
exactly what series of functions were called to get to the __delay.