GDB does not stop at assembly code address

GDB does not stop at assembly code address

[deffo]

Hi there,

I'm currently debugging the 32 bit Linux Kernel 4.8.1 remotely with GDB and Qemu i386 2.7. My GDB script looks like this:

target remote localhost:10000
source .
symbol-file vmlinux
set width 0
set height 0
set verbose off

b rest_init
commands
continue
end

b console_init
commands
continue
end

b start_kernel
commands
continue
end

b startup_32
commands
continue
end

continue

Now apparently I'm missing something, since the breakpoints in C land, that is start_kernel, console_init, rest_init are recognized as breakpoints and thus jumped at by GDB just fine.

What does not work is the breakpoint on startup_32, which is still in Assembly land. GDB just jumps over it as if it wasn't called, but it is definitely called since it's the 32-bit kernel entrypoint.

Is this due to some real-mode/protected-mode fiddlings?

Best regards,
J.

Re: GDB does not stop at assembly code address

[Yao Qi]

On Fri, Oct 14, 2016 at 4:21 PM,  <deffo@gmx.de> wrote:
>
> What does not work is the breakpoint on startup_32, which is still in Assembly land. GDB just jumps over it as if it wasn't called, but it is definitely called since it's the 32-bit kernel entrypoint.
>

What is startup_32 address and where does GDB set breakpoint?
You can do "print startup_32" and "info breakpoints" to get the answer
of two questions above.

-- 
Yao (齐尧)

Re: GDB does not stop at assembly code address

[Jan Kratochvil]

On Fri, 14 Oct 2016 17:21:36 +0200, deffo@gmx.de wrote:
> What does not work is the breakpoint on startup_32, which is still in
> Assembly land. GDB just jumps over it as if it wasn't called, but it is
> definitely called since it's the 32-bit kernel entrypoint.
> 
> Is this due to some real-mode/protected-mode fiddlings?

On Tue, 18 Oct 2016 18:53:05 +0200, deffo@gmx.de wrote:
> (gdb) b startup_32
> Breakpoint 1 at 0xc1000000: file arch/x86/kernel/head_32.S, line 97.

It is because it is too early bootstap which does not yet run from virtual
addresses.  0xc1000000 is a virtual address - if it was a physical address
Linux kernel could not run on any machine with less than 3GB of RAM.
(Which it can - there did exist machines with less than 3GB RAM. :-)  )

This startup_32 code sets up the virtual memory page tables where it later
jumps.  But sure it does not jump to 0xc1000000 as it would dead-lock itself.

It is better written in the 64-bit startup code but the principle is the same:
arch/x86/kernel/head_64.S
63               * Since we may be loaded at an address different from what we were
64               * compiled to run at we first fixup the physical addresses in our page
65               * tables and then reload them.

Debugging any bootstrapping code usually has many pitfalls.


Jan

Re: GDB does not stop at assembly code address

[deffo]

Here's the output:

(gdb) b startup_32
Breakpoint 1 at 0xc1000000: file arch/x86/kernel/head_32.S, line 97.
(gdb) print startup_32
$1 = {<text variable, no debug info>} 0xc1000000 <startup_32>
(gdb) info breakpoints
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0xc1000000 arch/x86/kernel/head_32.S:97

(gdb) b start_kernel
Breakpoint 1 at 0xc1be3755: file init/main.c, line 480.
(gdb) print start_kernel
$1 = {void (void)} 0xc1be3755 <start_kernel>
(gdb) info breakpoints
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0xc1be3755 in start_kernel at init/main.c:480

I guess the "no debug info" would be the explanation, but why is that? The address is listed as a FUNC in readelf -Ws vmlinux, thus it should be correct. What do I have to do?

----------------------------------------------------------------------------------------------

What is startup_32 address and where does GDB set breakpoint?
You can do "print startup_32" and "info breakpoints" to get the answer
of two questions above.

-- 
Yao (齐尧)

Re: GDB does not stop at assembly code address

[Yao Qi]

On Tue, Oct 18, 2016 at 12:53 PM,  <deffo@gmx.de> wrote:
> Here's the output:
>
> (gdb) b startup_32
> Breakpoint 1 at 0xc1000000: file arch/x86/kernel/head_32.S, line 97.
> (gdb) print startup_32
> $1 = {<text variable, no debug info>} 0xc1000000 <startup_32>
> (gdb) info breakpoints
> Num     Type           Disp Enb Address    What
> 1       breakpoint     keep y   0xc1000000 arch/x86/kernel/head_32.S:97
>
> (gdb) b start_kernel
> Breakpoint 1 at 0xc1be3755: file init/main.c, line 480.
> (gdb) print start_kernel
> $1 = {void (void)} 0xc1be3755 <start_kernel>
> (gdb) info breakpoints
> Num     Type           Disp Enb Address    What
> 1       breakpoint     keep y   0xc1be3755 in start_kernel at init/main.c:480
>

Looks breakpoint is set on the right place.  Nothing wrong there.

> I guess the "no debug info" would be the explanation, but why is that? The address is listed as a FUNC in readelf -Ws vmlinux, thus it should be correct. What do I have to do?
>

"no debug info" is about startup_32, which is written in assembly without debug
information.  It is nothing wrong there.  I have no idea why breakpoint on
startup_32 is not hit.

-- 
Yao (齐尧)