This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB does not stop at assembly code address
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: deffo at gmx dot de
- Cc: gdb at sourceware dot org
- Date: Tue, 18 Oct 2016 21:47:28 +0200
- Subject: Re: GDB does not stop at assembly code address
- Authentication-results: sourceware.org; auth=none
- References: <trinity-155e70d9-b72e-49fd-86ca-815bb77c2481-1476458496665@3capp-gmx-bs30>
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