I am currently implementing a new scheduler on linux (Tizen) kernel version 4.19.49 running on qemu, and want my new scheduler to take place of the CFS scheduler. I've modified several points of /kernel/sched/core.c and implemented (new_scheduler).c to face a problem that the kernel won't even boot, to the point that no log message nor any printk messages won't be printed, maybe because my scheduler is not functional at the moment. The circumstances makes debugging very difficult, and any debuggig method that works would make my day. Please help...
I've tried printk and attaching gdb to qemu. printk won't work, and gdb won't take any commands such as run, continue.
First, make sure that the kernel runs with the identical config/build etc but without any of your changes in it, as a baseline so you know you're debugging a problem in your own code, not one in how you've configured or are building the kernel.
Second, make sure you enable earlycon (or earlyprintk if you have a really old kernel). This makes the kernel start sending its logging to the terminal immediately, so you get to see information for crashes or panics in the early stages of bootup, rather than no output at all.
Thirdly, use git bisect on your new kernel changes to narrow down what part of it introduces the crash. (If you didn't have your changes split out into nicely self-contained small pieces, this is is why doing that is worthwhile :-))
Fourthly, you can use QEMU's built-in gdbstub to debug the guest.