|[Top]||[Contents]||[Index]||[ ? ]|
GDB might tell
schedule() doesn't exist, which is arguably a GDB bug.
You can work around this by setting the breakpoint by filename and line
break thread.c:ln where ln is the line
number of the first declaration in
schedule(). At the time of this
writing, that line is number 556.
We will treat these terms as synonyms. There is no standard distinction between them, although Intel processor manuals make a minor distinction between them on 80x86.
This rule is common but not universal. One modern exception is the x86-64 System V ABI, which designates 128 bytes below the stack pointer as a "red zone" that may not be modified by signal or interrupt handlers.
This is because
arguments on the stack and the 80x86 SVR4 calling convention
requires the caller, not the called function, to remove them when the
call is complete. See [ SysV-i386] chapter 3 for details.
Actually, virtual to physical translation on the 80x86 architecture occurs via an intermediate "linear address," but Pintos (and most modern 80x86 OSes) set up the CPU so that linear and virtual addresses are one and the same. Thus, you can effectively ignore this CPU feature.
Because we are working in binary, the "decimal" point might more correctly be called the "binary" point, but the meaning should be clear.
pintos-gdb is a wrapper around
gdb (80x86) or
i386-elf-gdb (SPARC) that loads
the Pintos macros at startup.
You may get a warning of a remote failure reply.
gdb will work anyway.
To be precise, GDB will stop
only when running under Bochs. When running under QEMU, you must
set a breakpoint in the
page_fault function to stop execution
when a page fault occurs. In that case, the
btpagefault macro is
This is typically
vi, type : q Enter.