Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

C - Lab 8 | Introduction to Software Engineering | CSCI 0320, Lab Reports of Software Engineering

Material Type: Lab; Class: Introduction to Software Engineering; Subject: Computer Science; University: Brown University; Term: Unknown 2009;

Typology: Lab Reports

Pre 2010

Uploaded on 08/18/2009

koofers-user-mfx
koofers-user-mfx 🇺🇸

10 documents

1 / 8

Toggle sidebar

Related documents


Partial preview of the text

Download C - Lab 8 | Introduction to Software Engineering | CSCI 0320 and more Lab Reports Software Engineering in PDF only on Docsity! CS032 2009 Lab 08 C 1 C - It’s Legit So most likely you’ve seen some C. Hopefully, you’ve done the homework already. If not, you should get on that, because it’s due pretty soon. C is one of the most widely used programming languages. It has become such a popular choice due to its efficiency and the power it gives the programmer over the machine. Almost any electronic device that uses a microprocessor can be programmed in C. Whether its a typical computer, a specialized gaming console, or a onboard real-time system controlling a military jet, C gives you the power to tell a machine what to do, and how to do it. Of course, there are more exact ways to program, such as MIPS Assembly, but C is a good middle ground between Java and a magnifying glass, a magnet, a stick of ram, and a very steady hand. This lab is going to cover some C basics. We can’t cover enough C in two hours to actually prepare you for the coming assignments, so we trust that you have read or at some point will read the CS123 C mini course at http://www.cs.brown.edu/courses/cs123/resources/c mini course.pdf. 2 Tools 2.1 gcc gcc is just one tool in the larger GNU compiler collection. This set of compilers is typical for all Linux distributions because it is open source. It contains many compilers, including an open source Java compiler called gcj. We’ll cover some gcc basics, but most of your compilation will be done with Makefiles. 2.2 make You will inevitably have projects with tons of files, which will lead to tons of .o files and issues about binaries being out of date and what not. Make can be thought of like a script for your compiler, but with significantly more control than a shell script. Think of it like Ant, except instead of build.xml, your file will be called Makefile, and instead of sucking, it’ll be awesome. True story. 2.3 man This is Unix’s Hitchhiker’s Guide To The Galaxy. Any information you need about a shell command, a system function, a built-in program, random facts about Andy Van Dam, etc...it’s all there. 2.4 gdb GNU Debugger. The best program ever. This will save your life. It’s like the debugger in Eclipse, but faster and better. 3 gcc 3.1 The Code For this part of the lab, you’ll be using the code in the make/ directory. This is a copy of an old CS36 assignment called myalloc, implemented by Josh Dawidowicz in 2007. It is a simplified implementation of 1 malloc, about which you will learn more than you want to know in CS167. It has two different run modes, Task 1 and Task 2, which can be switched in myalloc.h. None of this matters for your lab. 3.2 gcc is Way Complicated “UNIX is the answer, but only if you phrase the question VERY carefully.” -Button on the bulletin board in the Sunlab gcc is very robust, but very complicated. It has one of the longest man pages, which should tell you something. It will do a ton of stuff for you on its own, but you need to guide it. It helps to know how gcc works before you start compiling stuff with it, but this is not a systems class, so if you’d like to investigate, we’ve included the old CS36 lab1 for your reading pleasure. For now, we’ll just be dealing with compiling, taking pre-processing and linking as givens. 3.2.1 Compiler Flags Once the C pre-processor has had its turn, the compiler takes over. The compiler is responsible for generating assembly or machine code from source code. Binary files produced by gcc are known as object files and have a file extension of .o. It’s important to note now that unless specific flags are passed into gcc it will attempt to build an executable from source, rather than the intermediate step of building an object file. In order to build an object file, we pass the -c flag to gcc. In order to give a specific name to the outputted file, we pass the -o flag. Here is an example of the above. /u/jdawidow % gcc -o file.o -c file.c In the example above, we are trying to compile the file file.c, requesting object file output, renaming the output file to file.o. Remember to specify the new filename after the -o flag if you’re trying to rename it. 3.2.2 Linking and Loading The final step in building an executable is the linking and loading stage. All of the references to other files are taken care of in the linker. To link object files into a larger executable, invoke gcc without the -c option. Consider the example below. /u/jdawidow % gcc -o theProgram file.o file2.o In this example, myExecutable is built by linking the two object files file.o, and file2.o, which were built separately. Alternatively, there are several instances when a user may want to compile a program linking against an external library. For example, suppose you want to use a support code library called, appropriately, support. In this instance, if the library is in a central location, you would simply use the -l option in the compiler /u/jdawidow % gcc -o theProgram -lsupport file.o file2.o 3.2.3 Checkpoint 1 Compile myAlloc and show a TA. Remove the .o files and the executable and you’ll be ready for part 2. 4 Manual Pages While you won’t actually write any code during this part, it’s a good time to tell you about the manual pages. The manual pages, often referred to as manpages, are like Javadocs, but for all of UNIX. Manpages exist for UNIX commands as well as C standard library function. Often, if you’re not sure how to invoke 1gcc man.pdf, in this lab directory 2 Bourne Shell6. This comes in handy if one wants a rule to call make in another directory to compile a library or other module. Rules like these can get really convoluted, especially since each script command must be parsed as one line by make. Luckily, you’ve probably made a typo in your shell where you type \by accident and the shell gives you a ?. That’s because the \character tells the shell “Hey bro, there’s more to this command, but I ran out of room, so hold on.” Go ahead and try ls; \ls. It’s baller. 5.6 Checkpoints 2-5 • Write a Makefile to compile myAlloc. Use dependencies and variables whenever possible. • Modify your Makefile, unless you did it already on your first try, to use pattern matching. • Create a target, tidy, to remove all .o files • Create a target, clean, to do what tidy does, as well as get rid of backups and executables 5.7 Additional Information Anything you may ever need about Makefiles is at http://www.gnu.org/software/make/manual/make.html. Epic win. 6 GDB As software projects get bigger and bigger, debugging becomes more and more difficult. You may have gotten used to debugging by printing out every single variable, but trust us, there are much easier ways to fix your programs. With gdb you can pause the execution of your program, print out variables at run time and check for errors in memory usage, all without recompiling. 7 6.1 Background and Command Summary Once you learn a few of the basic commands of gdb, you will be able to do a lot. One important command to know is help. If you type help you will get a list of broad help topics. If you wanted to get more information about running programs within gdb typing help will show you that running is a help topic. You can then type help running to get sub-topics related to running programs. Typing help <command> will usually give you a great deal of information about that command and its use. The gdb help system is a great resource, do not forget about it! 6.2 Starting gdb and running programs Loading up a executable in gdb is relatively simple. Simply type gdb <your executable name> to start gdb up on the executable. In order to use gdb you MUST have compiled your program with the -g compiler option. When you are in gdb and have a program loaded, these commands will help you get started: • help running – Will give a list of commands related to running the program. • run <args> – Will run the current program being debugged with the given arguments. 6Read the manpage for sh if you’re curious 7For the manual on gdb, http : //sources.redhat.com/gdb/current/onlinedocs/gdb toc.html 5 • set args <args> – Will permanently set the arguments being sent to the program. One thing to note is that gdb has a very nice tab completion system. It will tab complete commands, file names, and even symbols within your program! One slight caveat to this is that to complete C++ symbols you need to start an expression with a single quote when you tab complete. C symbols will work fine without the single quote. Another tip is that when invoking a gdb command you only have to type as many letters as is necessary to disambiguate that command from any others. For instance, if you type ’whe’ and hit enter gdb will assume you are just being lazy and you want to run the ’where’ command. 6.3 Commands to control execution Here are some basic commands that will let you pause the execution of your program and examine data. • info <action type> - Displays all breakpoints or auto-display expressions in effect. The ’action type’ argument can be several things, for instance, you can use ’breakpoints’ or ’display’ depending upon whether you wish to examine breakpoints auto-display expressions. You can even use ’locals’ to show all local varaibles of the current stack frame. Try help info for more information. • break <location> - This command sets a breakpoint at a specified location. Some examples: break main - Sets a breakpoint in the main() function. break Foo::myFunc - Sets a breakpoint in the Foo::myFunc method. 8 break main.c:100 - Sets a breakpoint in the main.c file, at line number 100 • break <location> if <condition> - This command sets a breakpoint at a specified location with a conditional requirement such that the breakpoint is only hit if the conditional is true. For example: break myFunc if m_variable==0 Sets a breakpoint at the start of the myFunc function only if m variable==0 • condition <breakpoint number> <condition> - This command sets an already created break- point to be conditional so that execution of the program only halts at the specified breakpoint when the the condition specified is true. • step - If stopped in execution, this will execute the next line of code. If this line is a function call, it will enter the function call. It is common to repeatedly call step to advance slowly through your program’s execution. • next - If stopped in execution, this will execute the next line of code, not stepping into any function calls. It is common to repeatedly call next to advance slowly through your program’s execution. • continue If stopped in execution, this will begin to execute normally and run until the next breakpoint or until the program exits. It is common to call cont when you have finished using step or next to examine things closely and want to have the program execute at full speed. • kill - This simply kills the execution of the program being debugged. Useful if the program won’t stop running and you need to force it to end. • delete [<action type>] <number> - This deletes one of the breakpoints or auto-display expres- sions displayed by the info command. The ’action type’ argument can either be ’breakpoints’ or ’display’ depending on whether you are deleting a breakpoint or auto-display expression. If the ’action type’ argument is not given that it is assumed you are deleting a break point. 8If you don’t understand this :: syntax yet, don’t worry. It’s C++ syntax indicating a class method call as opposed to a straight C function call. In this case, we break at the myFunc method of the Foo class 6 • clear [<location>] - This clears a specified location of all breakpoints. If no line number is specified this clears all breakpoints. • call <function>(args) - Instructs gdb to call the given function, with the given arguments. Use print to show the return value (see next section). 6.4 Displaying and Naming Data Once you reach a certain point in the execution of a program, it is often useful to be able to print out information about the execution of the program up to that point. For example, say you have some functions: funcOne calls funcTwo which calls funcThree. If you stop at a breakpoint in funcThree, you can print out the stack trace using the where command. This will print out a list of the calls which led to reaching funcThree, and the values of their arguments. While you are stopped in funcThree, you can also print out the values of all variables within the scope of the function, which may include local variables, class variables, and memory addresses, by using the print, display, and examine commands. Within the scope of funcThree, you can’t access the variables in the scope of funcTwo. However, you can move between stack frames by using the up and down commands. Using the up command will move you from the scope of funcThree to the scope of funcTwo, where you can view the stack trace and variables of funcTwo. Using the down command will bring you back to the scope of funcThree. The important commands to know for looking at data are: • where - Prints a list of all stack frames, along with the function and argument values for each stack frame. • up [<number>] - Move up one stack frame. An optional argument can move up multiple frames. • down [<number>] - Move down one stack frame. An optional argument can move down multiple frames. • frame <number> - Jump to an exact frame number. • print <expression> Prints the value of the given expression. The expression can be a function call, local variable, or a constant. • list - Prints the code that surrounds the current point of execution. • display <expression> - Display the value of an expression every time execution is halted at a breakpoint. It should be noted that all the above expressions may be arbitrarily complex and contain any math, bit operations, etc. They need not use variables from the program (e.g. print (1291 & 15) << 2). 6.5 Abbreviations • n is equivalent to next • s is equivalent to step • c is equivalent to cont • wh is equivalent to where • do is equivalent to down • b is equivalent to break • p is equivalent to print • l is equivalent to list • bt9 is equivalent to where 9bt is short for backtrace, which is the same as where 7
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved