Week 3.b
CS6640
09/21 2023
https://naizhengtan.github.io/23fall/

1. normal vs. kernel debugging
2. Memory layout in egos
3. gdb
4. a tricky bug
----

1. normal vs. kernel debugging

  Q: how do you debug a normal C program, like your lab2 in CS5600?

  * "normal" C program
    + you do not need to understand hardware details (like CPU)
    + you have clear error messages
    + you do not have to worry about touching important memory
      (the program will be killed)
    + you do not use addresses directly
    + you have a nice address space containing your program only
    + you have a lot of tools (like IDE)

  * kernel programming
    - you need to understand hardware details (like CPU)
    - you have semi-clear error messages (if you know CPU)
    - your have to worry about touching important memory
      (the kernel will write something to there and later crash)
    - you sometimes need to use addresses directly
    - you do not have a nice address space
    - you have limited yet powerful tools

  * ULT labs? a mix of the two
    + you need to understand hardware details (like CPU)
    - you have semi-clear error messages (if you know CPU)
    - your have to worry about touching important memory
    + you do not use addresses directly
    - you do not have a nice address space
    - you have limited yet powerful tools

  * some debugging principles
    - "die" earlier than later
    - use "ASSERT" a lot
    - use "printf" but don't trust "printf" entirely
    - binary-printf is still useful
    - use "static analysis" more often (e.g., "git diff")

  [skipped]
  * common "error messages":
    accessing invalid memory
       w/ and w/o virtual memory
       [example: invalid memory]

2. Memory layout in egos

  Talking about memory...

  * egos design:
    - earth: abstract hardware (like interrupt, memory, disk)
    - grass: provide services (like process, scheduler, syscall)
    - apps:
       -- system apps: provide basic functionalities (like fs, shell)
       -- user apps: normal apps

  * memory layout of your ULT
    [see handout]

  * check .lst files
    [take a look at 
      earth.lst,
      grass.lst,
      sys_shell.lst, ult.lst]

  * where are stacks defined?
     apps/app.S
     earth/earth.S

  * grass and earth interfaces
    library/egos.h

3. gdb

  * how to run
    You need two shells:

      sh1> make qemu-gdb

      sh2> riscv64-unknown-elf-gdb

  * egos gdb setup

     qemu <--[port:6640]--> gdb
    [stop]
                          [connect]
                          (gdb) c
  [start to run]
       ...
                          <Ctrl-C>
    [stop]
                          (gdb) quit
    [continue]

  [skipped]
  * gdb basics

    Scenario 1: "what's wrong?"
    - run to failure
    - use gdb to see the final status

    Scenario 2: "I suspect this is wrong"
    - set a breakpoint
    - continue the egos
    - run until the breakpoint
    - single step running & monitoring

    [exmaple: invalid memory]

  Q: why the watchpoints/breakpoints have been triggered multiple times?

    because...
    ...so far, you don't have all apps share the same memory layout...
    ...we don't have virtual address space for each process,...
    ...which will be your future labs

  Q: wait...if all apps are using the same chunks of memory.
     how can egos run them?

    A: whenever scheduling a new app, kernel saves the previous app
       and copies the new app's memory
       to the corresponding memory addresses.

  * gdb on egos
    - initial symbols: earth and grass
    - add new symbol file:
      "(gdb) add-symbol-file build/release/ult.elf"
    - breakpoints at apps' region may be triggered by other apps
    - there are timer interrupts

4. a tricky bug: lost item

   [example: lost item]