Is arch/x86/boot/main.c main obsolete?
CPU: Intel x86 KabyLake. I'm using 5.17 Kernel built from upstream and GRUB 2.04 When debugging the kernel initialization process I found out that there is a function void main(void) in the source file arch/x86/boot/main.c (source link: https://elixir.bootlin.com/linux/v5.17/source/arch/x86/boot/main.c#L134) which seems to be the entry point which the boot loader is supposed to jump into. But objdump-ing the Kernel image shows that there is no such symbol as main. GDB attached to QEMU does not know about this symbol either. The earliest stage of Kernel Initialization I could manage to catch with GDB is x86_64_start_kernel (source link: https://elixir.bootlin.com/linux/v5.17/source/arch/x86/kernel/head64.c#L467) The question is what function GRUB actually jump into passing control to the Kernel code and what is the purpose of arch/x86/boot/main.c::main?
On Sat, Jun 25, 2022 at 7:35 PM ebashinskii <ebashinskii@proton.me> wrote:
CPU: Intel x86 KabyLake. I'm using 5.17 Kernel built from upstream and GRUB 2.04
When debugging the kernel initialization process I found out that there is a function *void main(void)* in the source file *arch/x86/boot/main.c* (source link: https://elixir.bootlin.com/linux/v5.17/source/arch/x86/boot/main.c#L134) which seems to be the entry point which the boot loader is supposed to jump into.
But *objdump*-ing the Kernel image shows that there is no such symbol as *main*. GDB attached to QEMU does not know about this symbol either.
The earliest stage of Kernel Initialization I could manage to catch with GDB is *x86_64_start_kernel* (source link: https://elixir.bootlin.com/linux/v5.17/source/arch/x86/kernel/head64.c#L467 )
The question is what function GRUB actually jump into passing control to the Kernel code and what is the purpose of *arch/x86/boot/main.c::main*?
This should answer most of the questions you may have about the kernel boot process: https://0xax.gitbooks.io/linux-insides/content/Booting/ :-)
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I tried to set up a breakpoint inGDB and to lookup void main(void) and _start with objdumpon the kernel image without any success. Actually it clearly says that the control Jump to the C code inarch/x86/boot/main.c. But as I mentioned before there's simply no such symbol as void main(void) in the Kernel image. How can it jump to something that does not exist?
On Sat, Jun 25, 2022 at 5:35 PM ebashinskii <ebashinskii@proton.me> wrote:
CPU: Intel x86 KabyLake. I'm using 5.17 Kernel built from upstream and GRUB 2.04
When debugging the kernel initialization process I found out that there is a function *void main(void)* in the source file *arch/x86/boot/main.c* (source link: https://elixir.bootlin.com/linux/v5.17/source/arch/x86/boot/main.c#L134) which seems to be the entry point which the boot loader is supposed to jump into.
But *objdump*-ing the Kernel image shows that there is no such symbol as *main*. GDB attached to QEMU does not know about this symbol either.
The earliest stage of Kernel Initialization I could manage to catch with GDB is *x86_64_start_kernel* (source link: https://elixir.bootlin.com/linux/v5.17/source/arch/x86/kernel/head64.c#L467 )
What are you trying to do that start-kernel is insufficiently early ? main.c 's that you dont hit dont really matter do they ? fwiw, I really like virtme virtme-run $KRUN_SHOW $KRUN_STDS $KDBG_OPTS $* $QM_OPTS --smp 3 -s -S the -s -S stops me early enough to anything Ive needed to so far.
participants (3)
-
Aruna Hewapathirane -
ebashinskii -
jim.cromie＠gmail.com