Updated gdb guide, added info on difference between simulator and real thing re: memory

commit d52067c03fb047c316c7dc46272776e15dfdddf3
Author: Julie Zelenski <[email protected]>
Date:   Sat Jan 26 23:05:16 2019 -0800

    Updated gdb guide, added info on difference between simulator and real thing re: memory

Author: zelenski

_config.yml

@@ -5,6 +5,9 @@ kramdown:
 permalink: pretty
 exclude:
   - /cs107e/
+  - /firmware/
+  - /hardware/
+  - /stickers/
 include:
   - _assets
 defaults:
@@ -16,4 +19,6 @@ defaults:
       layout: "default"
 plugins:
   - jekyll-sitemap
-
+error_mode: warn
+strict_variables: true
+strict_filters: true

_includes/navbar.html

@@ -28,6 +28,7 @@
             <li><a href="/policies/">Policies</a></li>
             <li><a href="/schedule/">Schedule</a></li>
             <li><a href="/guides/">Guides</a></li>
+            <li><a href="/demos/">External demos</a></li>
             <li><a href="/resources/">External resources</a></li>
           </ul>
         </li>

guides/binutils.md

@@ -48,15 +48,15 @@ and links them together is `ld`, described below.
 
 The most common use of `as` is as follows:
 
-    % as code.s -o code.o
+    $ as code.s -o code.o
 
 This tells the assembler that `code.s` is its input of assembly code, and to output object
 code to `code.o`. If you do not include `-o code.o` then it will default to outputting to
 `a.out`. If you do not include `code.s` it will default to taking its input from standard
 input. These two invocations are therefore equivalent:
 
-    % cat code.s | as
-    % as code.s -o a.out
+    $ cat code.s | as
+    $ as code.s -o a.out
 
 ### `ld`
 
@@ -81,28 +81,28 @@ where `f` exists.
 
 The basic use for `ld` is as follows:
 
-    % ld code1.o code1.o -o code.bin
+    $ ld code1.o code1.o -o code.bin
 
 This takes two object files, links them together, and outputs the result as `code.bin`.
 
 When you invoke GCC without the `-c` option, it typically runs `ld` as its last step. For
 example,
 
-    % gcc -o test test.c
+    $ gcc -o test test.c
 
 is mostly equivalent (I'm leaving out a lot of options that are added by default) to:
 
-    % gcc -S test.S test.c  # Generate assembly
-    % as -o test.o test.S   # Generate object file
-    % ld -o test test.o 
+    $ gcc -S test.S test.c  # Generate assembly
+    $ as -o test.o test.S   # Generate object file
+    $ ld -o test test.o 
 
 The most commonly used options for `ld` are `-l` and `-L`. The `-l` option tells `ld`
 to link a library, which is basically just an object file. But libraries are typically
 stable code that you don't update often and are used by many programs, so they live
 in separate directories for that purpose (e.g, `/usr/lib`). The `-L` option tells `ld`
 what directories to look for libraries in. So, for example,
 
-    % ld -o test test.o -lgcc -L/usr/lib
+    $ ld -o test test.o -lgcc -L/usr/lib
 
 tells `ld` to link a file name `libgcc.a` (or `libgcc.so`, but we will not be using
 shared objects in this class, so don't worry about them) which it should search for
@@ -144,14 +144,14 @@ second column states what kind of symbol it is. The types are:
 
 So in the above example, the object file defines a function `f`, a function `main`, and a variable `a`.
 The other symbols (generally, symbols that start with `_`) are generated by the compiler for
-bookeeping and linking.
+bookkeeping and linking.
 
 ### `size`
 
 Lists the size of sections (and total size) of object files. Can be invoked on multiple 
 files at once simply by listing the desired files, 
 
-    % size test.o test2.o
+    $ size test.o test2.o
 
 which produces output like this:
 
@@ -170,7 +170,7 @@ the section sizes in hexadecimal, use the `-x` option (`size -x test.o`). You ca
 file type if it is not automatically recognized. For example if you want to know the size of a raw 
 binary file, you could use 
 
-    % size --target=binary test.bin
+    $ size --target=binary test.bin
 
 ### `strings`
 
@@ -179,13 +179,13 @@ for searching binary files, which are not readable using a text editor. For exam
 wanted to search an object file for a particular string, you could call strings and pipe the result to 
 grep, like this:
 
-    % strings test.o | grep "my string"
+    $ strings test.o | grep "my string"
 
 By default, `strings` looks for strings of at least 4
 printable characters (followed by a NUL character indicating the end of a string).
 To set a minimum string length other than 4, use the `-n` option. For example,
 
-    % strings -n 6 test.o
+    $ strings -n 6 test.o
 
 looks for strings of at least 6 characters.
 
@@ -206,11 +206,11 @@ options to `objcopy` are `-O` and `-I`, which specify the output and input forma
 elf32-bigarm, ihex, and binary. Sometimes `objcopy` can tell what the format is and so doesn't need to be
 told explicitly (e.g., ELF). In its most basic use, `objcopy` just makes a copy of the file. For example,
 
-    % objcopy main main2
+    $ objcopy main main2
 
 creates a simple of main in main2. In contrast,
 
-    % objcopy main -O binary main.bin 
+    $ objcopy main -O binary main.bin 
 
 takes main as input (an ELF file), transforms it into a raw binary file and outputs that raw binary as main.bin.
 
@@ -221,9 +221,9 @@ options, which indicate what type of information you would like to view. There a
 check out `man objdump` to see what it can show.
 
 A very useful option is the `-d` option, which allows you to view the assembly instructions 
-associated with the executable part of the binary file (`-d` is for dissassemble):
+associated with the executable part of the binary file (`-d` is for disassemble):
 
-    % objdump -d test.o
+    $ objdump -d test.o
 
 ### `ar`
 
@@ -243,7 +243,7 @@ functions.
 
 For example,
 
-    % ar cr libtest.a test.o test2.o
+    $ ar cr libtest.a test.o test2.o
 
 makes the library archive file libtest.a containing test.o and test2.o. Then you can link to this 
 library by specifying `-ltest` in the `ld` command (see `ld` above).

guides/ci.md

@@ -32,7 +32,7 @@ solution.
 
 You can also click the icon next to a commit to see the results of a Travis
 build. This icon will show a red "x" for a build failure, a yellow circle for a
-build in progress, and a green checkmark for a succesful build.
+build in progress, and a green checkmark for a successful build.
 <img title="Pull request page." src="/guides/images/travis-github-commit-icon.png" width="800">
 
 The build page shows the result of testing one particular commit you pushed.