Re: GDB does not stop at assembly code address

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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