https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2020W_Lecture_6 2026-06-02T22:24:21Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2020W_Lecture_6&diff=22571&oldid=prev 2020-03-20T02:32:25Z

<p>Created page with &quot;==Video== The video for the lecture given on January 24, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec06-20200124.m4v is now available]...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> The video for the lecture given on January 24, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec06-20200124.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> ===Topics===<br /> * highlight relevant chapters from textbook<br /> * gdb<br /> ** [https://sourceware.org/gdb/onlinedocs/gdb/Forks.html follow-fork-mode] (parent, child)<br /> ** detach-on-fork (on, off)<br /> ** follow-exec-mode (new, same)<br /> ** [https://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html catch] exec<br /> ** catch syscall<br /> ** [https://sourceware.org/gdb/onlinedocs/gdb/TUI-Commands.html#TUI-Commands layout regs]<br /> ** layout split<br /> ** layout src<br /> ** layout asm<br /> ** [https://sourceware.org/gdb/onlinedocs/gdb/Data.html print]<br /> ** explore<br /> <br /> ===Textbook chapters===<br /> <br /> http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-intro.pdf<br /> http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-api.pdf<br /> http://pages.cs.wisc.edu/~remzi/OSTEP/vm-intro.pdf<br /> <br /> ===In Class===<br /> <br /> &lt;pre&gt;<br /> Lecture 6<br /> ---------<br /> <br /> Running gdb<br /> - problem: want to run gdb in a separate window from program we are debugging<br /> - solution: run two terminals, use gdb -p &lt;PID&gt; to attach to process<br /> (or attach command inside gdb)<br /> <br /> - problem: won&#039;t work in standard configuration, can only run gdb on child<br /> processes<br /> - solution:<br /> sudo su - (to become root)<br /> echo 0 &gt; /proc/sys/kernel/yama/ptrace_scope &lt;-- lost on reboot<br /> <br /> or<br /> sudo nano /etc/sysctl.d/10-ptrace.conf<br /> change &quot;kernel.yama.ptrace_scope = 0&quot; &lt;-- persistent<br /> <br /> - problem: how do I debug the child process? by default it debugs only<br /> the parent<br /> - solution: &quot;set follow-fork-mode child&quot; in gdb<br /> <br /> - problem: I want to see what system calls a process is making<br /> - solution: catch syscall<br /> also can specify specific syscalls to stop on<br /> <br /> - problem: I want to follow an execve (change the program that is being<br /> followed)<br /> - solution: set follow-exec-mode new (rather than same)<br /> <br /> - problem: I set a breakpoint for a function, how did we get to that<br /> breakpoint?<br /> - solution: bt (backtrace) to see the call stack<br /> <br /> Why am I showing you all this stuff with gdb?<br /> - I want you to understand how the programs we cover in the course run,<br /> particularly the system calls they run<br /> - strace can help with this, but sometimes you need to see things go down<br /> one line at a time. Hence gdb.<br /> <br /> Note that gdb uses a special system call to control other processes: ptrace<br /> - ptrace isn&#039;t always the most reliable<br /> - you don&#039;t want to ptrace processes in production; there are other tools<br /> which we will cover later in the term<br /> <br /> *Note* that if you want strace to follow forks, you need to specify the -f option<br /> <br /> Differences of fork versus execve<br /> - with fork<br /> - you start with one process (one PID)<br /> - you end with two processes: parent (with original PID) and<br /> child (with new PID)<br /> - parent and child are identical right after fork except for return<br /> value of fork(). Hence they are running the same program binary<br /> - with execve<br /> - only one process at start and end<br /> - before, running program that makes the execve call<br /> - after, running new program *specified* by the execve call<br /> - note that code after an execve call NEVER RUNS...unless<br /> execve fails (e.g., you tried to run a program and that file<br /> doesn&#039;t exist or you don&#039;t have permission to run it)<br /> <br /> In a normal shell, execve is run in a child (so after a fork)<br /> - otherwise the shell would terminate<br /> <br /> /proc and /sys<br /> - direct interfaces into kernel state<br /> - provide a file interface because, what would be better?<br /> - if you made a system call to get these, how would you have<br /> so many options? You&#039;d have to pass in magic numbers or strings<br /> - if you&#039;re passing in strings, why not make them filenames<br /> - then you get a hierarchy of strings!<br /> - big idea: a filesystem is just a mapping of filenames to data,<br /> doesn&#039;t have to correspond to &quot;real&quot; files (i.e., files stored on disk)<br /> - really, a file is just something that can be used with the<br /> filesystem API (open, read, write, close, etc)<br /> <br /> - view of processes in /proc is mostly read-only<br /> - can&#039;t kill a process by deleting files in /proc<br /> - but this is just a historical artifact of us already having a way<br /> of killing processes (with signals)<br /> <br /> Note that /etc is system configuration stored in persistent files<br /> - preserved across reboots<br /> <br /> Data in /proc and /sys is ephemeral<br /> - destroyed when system is rebooted<br /> - just reflects state of current kernel<br /> &lt;/pre&gt;</div>

Soma