JoelFernandes.org

Age is of no importance unless you're a cheese -- Billie Burke

Hello! I’m Joel and this my personal website built with Jekyll! I currently work at Nvidia. My interests are scheduler, RCU, tracing, synchronization, memory models and other kernel internals. I also love contributing to the upstream Linux kernel and other open source projects. In prior jobs, I worked at Google, Amazon and TI.

Connect with me on Twitter, and LinkedIn. Or, drop me an email at: joel at joelfernandes dot org

Look for my name in the kernel git log to find my upstream kernel patches. Check out my resume for full details of my work experience. I also actively present at conferences, see a list of my past talks, presentations and publications.

Full list of all blog posts on this site:
  • 25 Jun 2023   SVM and vectors for the curious
  • 10 Jun 2023   SELinux Debugging on ChromeOS
  • 28 Apr 2023   Understanding Hazard Pointers
  • 25 Apr 2023   PowerPC stack guard false positives in Linux kernel
  • 24 Feb 2023   Getting YouCompleteMe working for kernel development
  • 29 Jan 2023   Figuring out herd7 memory models
  • 13 Nov 2022   On workings of hrtimer's slack time functionality
  • 25 Oct 2020   C++ rvalue references
  • 06 Mar 2020   SRCU state double scan
  • 18 Oct 2019   Modeling (lack of) store ordering using PlusCal - and a wishlist
  • 02 Sep 2019   Making sense of scheduler deadlocks in RCU
  • 22 Dec 2018   Dumping User and Kernel stacks on Kernel events
  • 15 Jun 2018   RCU and dynticks-idle mode
  • 10 Jun 2018   Single-stepping the kernel's C code
  • 10 May 2018   RCU-preempt: What happens on a context switch
  • 11 Feb 2018   USDT for reliable Userspace event tracing
  • 08 Jan 2018   BPFd- Running BCC tools remotely across systems
  • 01 Jan 2017   ARMv8: flamegraph and NMI support
  • 19 Jun 2016   Ftrace events mechanism
  • 20 Mar 2016   TIF_NEED_RESCHED: why is it needed
  • 25 Dec 2015   Tying 2 voltage sources/signals together
  • 04 Jun 2014   MicroSD card remote switch
  • 07 May 2014   Linux Spinlock Internals
  • 24 Apr 2014   Studying cache-line sharing effects on SMP systems
  • 23 Apr 2014   Design of fork followed by exec in Linux
  • Most Recept Post:

    Single-stepping the kernel's C code

    | Comments

    Recently, I have had to use the GNU debugger (gdb) connected to a Qemu instance of a RISC-V processor to step through some kernel code.

    Turns out that the Linux kernel is compiled with gcc -O2 flag for optimizations it needs during the build. This causes several problems for a debugger. One of them is that the gdb command info registers will show values as <optimized out>. Another issue is that single-stepping will make the debugger appear to jump back and forth across lines of code as code is stepped through with next or step gdb commands.

    To circumvent this issue, I ended up with a hack that works well. I don’t claim this is recommended or correct, but it makes it through the build and gdb works fine. In my debugging, I have wanted to single-step through scheduler code in the __schedule kernel function. For this purpose, all I have to do is add the following to kernel/sched/Makefile.

    CFLAGS_REMOVE_core.o := -O2
    CFLAGS_core.o := -O0
    

    This works brilliantly! What do you think? Let me know in the comments.

    Some more tips:

    • CONFIG_DEBUG_INFO is needed to ensure kernel has debug symbols for gdb to load, and ofcourse CONFIG_DEBUG_KERNEL.
    • CONFIG_FRAME_POINTER should be enabled to ensure stack unwinding, backtraces work correctly.
    • CONFIG_GDB_SCRIPTS is a bunch of useful gdb scripts automatically load when a vmlinux is gdb’d.