Sistema de Llamadas al Sistema

1.Utilizando gdb (fácil)

Abre dos terminales, ambas en el directorio xv6

En la primera terminal ingresa:
make qemu-gdb
En la segunda terminal ingresa:
riscv64-unknown-elf-gdb

1. Observando la salida del backtrace, ¿qué función llamó a syscall?

(gdb) backtrace
#0  syscall () en kernel/syscall.c:138
#1  0x0000000080001d74 en usertrap () en kernel/trap.c:67
#2  0x0505050505050505 en ?? ()

La función se encuentra en kernel/trap.c --> usertrap()2. ¿Cuál es el valor de p->trapframe->a7 y qué representa ese valor? (Sugerencia: revisa user/initcode.S, el primer programa usuario que inicia xv6).

(gdb) p /x p->trapframe->a7
$3 = 0x7

xv6 utiliza el registro a7 para almacenar el número de llamada al sistema, revisa kernel/syscall.h

#define SYS_exec    7

La llamada al sistema número 7 es SYS_exec 3. ¿Cuál era el modo anterior en el que se encontraba la CPU?

(gdb) p /x $sstatus
$4 = 0x200000022

Revisando el documento riscv-privileged.pdf

El bit SPP de sstatus, es decir Supervisor Previous Privilege, indica el modo de máquina anterior al modo supervisor

SPP está en el bit 8, 0x200000022 tiene un 0 en el bit 8 (contando de derecha a izquierda), según el documento, 0 representa modo usuario

Por lo tanto era modo usuario 4. Anota la instrucción de ensamblaje donde el kernel está entrando en pánico. ¿Qué registro corersponde a la variable num?

Ejecuta xv6, el mensaje de error es el siguiente

make qemu
qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3 -nographic -global virtio-mmio.force-legacy=false -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0

xv6 kernel is booting

hart 2 starting
hart 1 starting
scause 0x000000000000000d
sepc=0x0000000080002054 stval=0x0000000000000000
panic: kerneltrap
QEMU: Terminated

El código de ensamblaje correspondiente a 80002054 es

num = *(int *)0;
	80002054:	00002683          	lw	a3,0(zero) # 0 <_entry-0x80000000>

El registro correspondiente a num es a35. ¿Por qué falla el kernel? Sugerencia: revisa la figura 3-3 en el texto; ¿la dirección 0 está mapeada en el espacio de direcciones del kernel? ¿Eso se confirma con el valor en scause anterior? (Ver descripción de scause en instrucciones privilegiadas de RISC-V)

1. Ejecuta gdb, establece un breakpoint en 0x0000000080002054

b *0x0000000080002054

2. El valor de scause es: 13, la dirección de destino es 0
3. Revisa el diagrama de distribución de memoria del libro xv6

La dirección 0 corresponde a Unused, no es una dirección del kernel

Revisa el documento RISC-V privileged instructions, figura 4.2, cuando scause es 13, el error correspondiente es Load page fault6. ¿Cuál es el nombre del binario que se estaba ejecutando cuando el kernel entró en pánico? ¿Cuál es su ID de proceso (pid)?

Al ocurrir el error, se estaba ejecutando el archivo kernel/syscall.c, compilado en el binario kernel

(gdb) p p->pid
$2 = 1

El pid es 1

2.Rastreo de llamadas al sistema (moderado)

Código: github

1. Agrega trace a UPROGS en el Makefile
2. Agrega la definición de la función trace a user/user.h
3. Agrega trace a user/usys.pl
4. Agrega SYS_trace a kernel/syscall.h

#define SYS_trace 22

5. Agrega trace_mask a struct proc en kernel/proc.h, para registrar el trace_mask del hilo actual
6. Modifica kernel/syscall.c para conectar SYS_trace y trace

Agrega una función de mapeo de nombre de llamada al sistema en syscall_names, para obtener el nombre de la llamada al sistema 7. Modifica la función fork en kernel/proc.c, para copiar trace_mask al proceso hijo

3.Sysinfo (moderado)

Código: github