Operating Systems 2019F: Tutorial 3 - Revision history

Soma: /* Comparing C and assembly */

2019-10-03T21:17:22Z

Comparing C and assembly

← Older revision		Revision as of 21:17, 3 October 2019
Line 24:		Line 24:
	Do the following with hello.c and syscall-hello.c, as before.		Do the following with hello.c and syscall-hello.c, as before.

	A few tips on reading assembly code. See [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax] for more information.		A few tips on reading assembly code. See [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax] for more information on syntax and [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions] for how functions are called.
	* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).		* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
	* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.		* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.

Soma at 20:34, 22 September 2019

2019-09-22T20:34:38Z

← Older revision		Revision as of 20:34, 22 September 2019
Line 1:		Line 1:
	'~~''This tutorial~~ is ~~not yet finalized~~.~~'''~~		In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

	~~In this tutorial we~~'~~re going to look at how processes work at a low level: how they make system calls & library calls~~, ~~how C~~ and ~~assembly compare, and and how memory is laid out~~.		If you haven't already, please set up and start using a VM on openstack.

	==Tasks==		==Tasks==

Soma: /* Function calls, library calls, and system calls */

2019-09-19T13:51:59Z

Function calls, library calls, and system calls

← Older revision		Revision as of 13:51, 19 September 2019
Line 6:		Line 6:

	===Function calls, library calls, and system calls===		===Function calls, library calls, and system calls===

			''Note that this section mostly overlaps with question 12 from Tutorial 1. If you worked hard on it, you can skip this section.''

	For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). To download programs to your VM, use the wget command, e.g.		For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). To download programs to your VM, use the wget command, e.g.

Soma at 04:22, 19 September 2019

2019-09-19T04:22:55Z

← Older revision		Revision as of 04:22, 19 September 2019
Line 1:		Line 1:
			'''This tutorial is not yet finalized.'''

	In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.		In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

Soma: /* Examining the runtime memory map */

2019-09-19T04:22:27Z

Examining the runtime memory map

← Older revision		Revision as of 04:22, 19 September 2019
Line 46:		Line 46:
	# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?		# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
	# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)		# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
			# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?

	==Code==		==Code==

Soma at 04:20, 19 September 2019

2019-09-19T04:20:27Z

@@ Line 1: / Line 1: @@
 In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.
-==Function calls, library calls, and system calls==
+==Tasks==
 For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c).  To download programs to your VM, use the wget command, e.g.
@@ Line 14: / Line 16: @@
 # (optional) Look up the documentation for each of the system calls made by the static versions of the programs.  You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.
-==Comparing C and assembly==
+===Comparing C and assembly===
 Do the following with hello.c and syscall-hello.c, as before.
@@ Line 37: / Line 39: @@
 # Re-run all of the previous gcc commands adding the "-v" flag.  What is all of that output?
-==Examining the runtime memory map==
+===Examining the runtime memory map===
 Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
@@ Line 44: / Line 46: @@
 # Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls.  Would you expect the heap to ever run into the stack?  Why or why not?
 # Change each malloc call to allocate more than 128K.  What happens to the values of sbrk?  Why?  (Hint: use strace)

Soma: Created page with "In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid o..."

2019-09-19T04:17:46Z

Created page with "In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid o..."

New page

In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

==Function calls, library calls, and system calls==

For [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c hello.c] and [http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/syscall-hello.c syscall-hello.c] do the following (substituting the appropriate source file for prog.c). To download programs to your VM, use the wget command, e.g.
<pre>
wget https://homeostasis.scs.carleton.ca/~soma/os-2017f/code/tut1/hello.c
</pre>
# Compile the program prog.c using <tt>gcc -O2 prog.c -o prog-dyn</tt> and run prog-dyn. What does it do?
# Statically compile and optimize prog.c by running <tt>gcc -O2 -static prog.c -o prog-static</tt>. How does the size compare with <tt>prog</tt>?
# See what system calls prog-static produces by running <tt>strace -o syscalls-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more system calls? '''Note: system calls are saved in the log file syscalls-static.log. Feel free to save them in a different file.'''
# See what library calls prog-static produces by running <tt>ltrace -o library-static.log ./prog-static</tt>. Do the same for <tt>prog-dyn</tt>. Which version generates more library calls? (If ltrace isn't installed, run <tt>sudo apt-get install ltrace</tt>)
# Use the command <tt>ls -l</tt> to see the metadata associated with prog.c and prog-dyn, and prog-static. Who owns these files? What group are they in? Do you notice any pattern with the permissions (rwx) associated with each file?
# (optional) Look up the documentation for each of the system calls made by the static versions of the programs. You may need to append a 2 or 3 to the manpage invocation, e.g. "man 2 write" gets you the write system call documentation.

==Comparing C and assembly==

Do the following with hello.c and syscall-hello.c, as before.

A few tips on reading assembly code. See [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax] for more information.
* The last letter of many instructions refers to the size of the operand. For example, callq means call a function using a "quad" value (64 bits).
* A dollar sign preceding a value means that it is a literal value, a percent sign means it is a register.
* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
# Run the command <tt>gcc -c -O2 prog.c</tt> to produce an object file. What file was produced? What symbols does it define?
# Look at the assembly code of the program by running <tt>gcc -S -O2 prog.c</tt>. What file was produced? Identify the following in the assembly code (if present):
#* A function call (call)
#* A return from a function (ret)
#* Registers being saved onto the stack (push)
#* Registers being retrieved from the stack (pop)
#* Subtraction (sub)
#* A system call (syscall)
# Disassemble the object file using <tt>objdump -d</tt>. How does this disassembly compare with the output from gcc -S?
# Examine the headers of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -h</tt>
# Examine the contents of object file, dynamically linked executable, and the statically linked executable using <tt>objdump -s</tt>
# Re-run all of the previous gcc commands adding the "-v" flag. What is all of that output?

==Examining the runtime memory map==

Compile and run [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000memview.c 3000memview.c], then consider the following questions.
# Why are the addresses inconsistent between runs?
# Roughly where does the stack seem to be? The heap? Code? Global variables?
# Observe how the heap grows (i.e. the value of sbrk changes) in response to malloc calls. Would you expect the heap to ever run into the stack? Why or why not?
# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)