CS代考程序代写 file system assembly compiler OSU CSE 2421

OSU CSE 2421
CSE 2421
J.E.Jones

OSU CSE 2421
 Developed from 1969-1971 at AT&T Bell Laboratories (Ken Thompson/Dennis Ritchie/Brian Kernighan/Douglas McIIroy/Joe Ossanna)
 Written largely in C (some assembly language code as well)
 C was originally developed as a programming language to
write the Unix OS, which was a multi-user, multi-tasking OS.
 Proprietary (requires a license for use)
 AT&T sold Unix to Novell in the early 1990s, which then sold its Unix business to the Santa Cruz Operation (SCO) in 1995
 UNIX trademark passed to the industry standards consortium The Open Group, which allows the use of the mark for certified operating systems compliant with the Single UNIX Specification (SUS). Among these is Apple’s MacOS which is the Unix version with the largest installed base as of 2014.
J.E.Jones

OSU CSE 2421
 “Modular design”: The OS provides a collection of simple tools that each implement a limited, well- defined function. (This was very forward thinking at the time.)
 More complex functionality is provided by combining the simple tools.
 A unified file system is the main means of communication; for example, devices (e.g., disk drives, keyboards) are treated as files.
 First “portable” operating system
J.E.Jones

OSU CSE 2421
 Developed in 1991 by Linus Torvalds, a graduate student in Computer Science at the University of Helsinki.
 Linux is a Unix “clone,” we can say, because it does not use Unix code (which is proprietary, and therefore could not be freely distributed), but it provides the same functionality and features as Unix generally, and follows the Unix OS philosophy.
 Open source, so it is available in versions without cost (There are also versions which are licensed for a fee, often with support, as well as the OS itself)
 Various “distributions,” which are all broadly similar, but also exhibit various differences (If you would like to get a Linux distribution, ask me, and I’ll be glad to point you to some!).
 It is worth your time and effort to learn as much as you can about Linux, because you are likely to encounter Linux/Unix in the work world.
J.E.Jones

OSU CSE 2421
 http://tldp.org/LDP/intro-linux/html/sect_01_01.html
◦ This link comes from: https://cse.osu.edu/computing- services/getting-help under the External Resources section “Introduction to Linux”
 http://www.diffen.com/difference/Linux_vs_Unix
Fully expect a question or two from these two articles on the mid-term. Perhaps, even before that.
J.E.Jones

OSU CSE 2421
 “Unix is used by 72.4% (up from 68.9% last January) of all the websites whose operating system we know..”
 Linux is used by 38.7% (down from 53.9% last January) of all the websites whose operating system we know. (This 38.7% is a part of the 72.4% aggregate above.)
http://w3techs.com/technologies/details/os-unix/all/all
Linux also runs on 96-98% of the top 500 supercomputers! Has anyone used a Raspberry Pi??? Then you have used Linux
J.E.Jones

OSU CSE 2421
 Use xterm as your vehicle to work on stdlinux. Part of this course is learning how to maneuver around linux/Unix in a BASH shell.
 If you choose to use MATE, then you won’t be able to answer the BASH shell questions on the midterm.
 Don’t start working on a lab the day it is due. It has not worked out well for any of my students in the past. You may be the exception, but, maybe, not.
 Get comfortable with the man command and how to read the manual pages it brings up.
J.E.Jones

OSU CSE 2421
 No code to write
 Some (short) articles to read
 Some navigation within a Linux command line window (BASH shell)
 Compiling C programs
 Some experience using the gdb debugger
 How to zip files (many may already know)
 How to submit to Carmen from stdlinux
J.E.Jones

OSU CSE 2421
 By convention, C source code files in a Unix/Linux environment have a .c “extension” (It isn’t really an extension in Unix/Linux, and the OS does not need it; the source code file is just a text file, and the OS can identify it as a text file without the .c).
 Unix/Linux files names cannot contain spaces unless “acrobatics” are used to reference the file name
J.E.Jones

OSU CSE 2421
 Documented in the Lab 1 Description document
 Copy the file exactly as it is. This is not the time for “poetic license”. Don’t use copy/paste. You will likely get a few unprintable characters in your .c file that will cause problems.
 Part of the reason to type it in is to allow you to really observe how the program was written. How it is different from (similar to) other languages you have used.
J.E.Jones

OSU CSE 2421
 After you enter the complete source code as specified in the Lab 1 description document, save the file from within the text editor.
 You can leave the text editor open and enter commands on the Linux command line (if you used ‘&’ when you opened the text editor).
 After saving, you can compile the source code as follows:
% gcc -ansi -pedantic –g -o lab1 lab1.c lab1_func.c
Although using the supplied Makefile is easier:
% make
J.E.Jones

OSU CSE 2421
 The gcc compiler collection can be used to compile, or more technically, build, C source code under a number of different standards, including ANSI C (sometimes called C89), C90, or C99
 In this class, we will learn ANSI C, or C89, which is actually the same standard as C90 (but the two were published separately, and that’s why there are two distinct names, even though there is only a single standard).
 When you build/compile code for any C language lab in this class, you must build it with the -ansi -pedantic options, so that you will get warnings about code that does not comply with the C89/C90 standard (the -pedantic option does this).
 The graders will build your code this way. ANY lab code that, when compiled as above, generates any errors or warnings, even if it builds successfully (that is, even if there are no syntax errors which prevent compilation) will receive NO POINTS. NO EXCEPTIONS.
 The –g option is used when we plan to use the executable with the debugger, gdb (in our example).
J.E.Jones

OSU CSE 2421
 A large percentage of industry environments still use ANSI C (C89/C90), so it’s important to learn this standard, and that’s why we use it in this course. This is a mandate from the CSE 2421 Course Coordinator.
 For this reason, in terms of portability, writing ANSI-compliant C code is important also. (Employers like this.)
 Learning the differences later between ANSI C and another standard, say C99, is not difficult if you need to do it later.
J.E.Jones

OSU CSE 2421
 Learning how to use the debugging program, gdb, will make your life in this class significantly easier. As well, make you more marketable.
◦ Some interviewers use experience with a debugging program as a gate to second interviews
 Using print statements helps some, but not as much as using gdb.
 gdb allows you to:
◦ watch your program run instruction by instruction
◦ observe a variable change values and see when things you thought would happen don’t
◦ Give you opportunities to fix them within your code with significantly less effort than staring at your code into the wee hours of the morning.
 Reference Bryant & O’Hallaron Figure 3.39 for sample gdb commands
J.E.Jones

OSU CSE 2421
 Learning how to use the debugging program, gdb, will make your life in this class significantly easier. As well, make you more marketable.
◦ Some interviewers use experience with a debugging program as a gate to second interviews
 Using print statements helps some, but not as much as using gdb.
 gdb allows you to:
◦ watch your program run instruction by instruction
◦ observe a variable change values and see when things you thought would happen don’t
◦ Give you opportunities to fix them within your code with significantly less effort than staring at your code into the wee hours of the morning.
 Reference Bryant & O’Hallaron Figure 3.39 for sample gdb commands
This reference will help you A LOT!!
J.E.Jones

OSU CSE 2421
 gdb(1) GNU Tools gdb(1)  NAME

gdb – The GNU Debugger
 
SYNOPSIS
 
DESCRIPTION
     
crashed.
GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:
gdb [-help] [-nx] [-q] [-batch] [-cd=dir] [-f] [-b bps] [-tty=dev] [-s symfile] [-e prog] [-se prog] [-c core] [-x cmds] [-d dir] [prog[core|procID]]
The purpose of a debugger such as GDB is to allow you to see what is going on ‘‘inside’’ another program while it executes—or what another program was doing at the moment it
ꞏ Start your program, specifying anything that might affect its behavior.
ꞏ Make your program stop on specified conditions.
ꞏ Examine what has happened, when your program has stopped.
ꞏ Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.
Check out Figure 3.39 in Computer Systems: A Programmer’s Perspective, 3rd Edition (page 280)
J.E.Jones

OSU CSE 2421
 ddd(1) GNU Tools ddd(1)
 NAME
 ddd – The Data Display Debugger
 SYNOPSIS
 ddd 

[–help] [–gdb] [–dbx] [–ladebug] [–wdb] [–xdb] [–jdb] [–pydb] [–perl] [–debugger name] [–[r]host [[username@]hostname]] [–trace] [–version] [–config- uration] [options…] [prog[core|procID]]
 but usually just
 ddd program
 DESCRIPTION
 DDD is a graphical front-end for GDB and other command-line debuggers. Using DDD, you can
 see what is going on “inside” another program while it executes—or what another program was
 doing at the moment it crashed.
 DDD can do four main kinds of things (plus other things in support of these) to help you
 catch bugs in the act:
J.E.Jones

OSU CSE 2421 ddd –manual
File: ddd.info, Node: Top, Next: Summary, Up: (dir)
Debugging with DDD ******************
DDD is a graphical front-end for GDB and other command-line debuggers.
This is the First Edition of `Debugging with DDD’, 8 Feb, 2009, for DDD Version 3.3.12.
The first part of this master menu lists the major nodes in this Info document, including the label and command indices. The rest of the menu lists all the lower level nodes in the document.
* Menu:
* Summary::
Summary of DDD.
* Sample Session:: * Invocation::
* Windows::
* Navigating::
A sample DDD session. Getting in and out of DDD.
* Stopping:: * Running::
Making your program stop at specific locations. Running programs under DDD.
The DDD windows, menus, and buttons. Moving through the source code.
J.E.Jones

OSU CSE 2421
 http://www.gnu.org/software/ddd/manual/
The DDD manual is available in the following formats:
•formatted in HTML (633K characters, 3.5M pictures) entirely on one web page.
•formatted as a PDF file (1.5M characters).
•formatted as a PostScript file (859K characters zipped).
A plain text version of the DDD manual is compiled within DDD; it can be viewed
• from within DDD using `Help -> DDD Manual’ or
• by invoking DDD as `ddd –manual’.
Texinfo sources as well as Info files are included in the DDD source distribution.
J.E.Jones

OSU CSE 2421
Execute gdb or ddd in the directory that contains all your source code files and your executable. This might be $HOME/cse2421/lab1 
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? – Brian Kernighan, “The Elements of Programming Style”, 2nd edition, chapter 2
The most effective debugging tool is still careful thought, coupled with
judiciously placed print statements. – Brian Kernighan, “Unix for Beginners” (1979)
(Unfortunately, print statements can change the timing of programs, thus hiding
the bug you are trying to find. This is especially true when trying to debug networking or operating system code. As well, sometimes print statements don’t finish executing before your program abnormally exits.– Janis Jones)
J.E.Jones

OSU CSE 2421
 Once you can compile and run the program successfully and have performed the debugger commands specified, you can submit it.
 Programs must be submitted to Carmen in a .zip file.
 The instructions for creating a .zip file are included in the lab1
description document and in your Makefile
 The graders will pull the labs from Carmen and test them on stdlinux based on the grading criteria.
J.E.Jones

OSU CSE 2421
 Did you submit ALL necessary files so that your program compiles? If no, then 0 points awarded.
 Were there any errors or warnings when compiled? If yes, then 0 points awarded.
 Does the program execute correctly with the example input provided? What about other valid input?
 Does the program execute correctly when “boundary” conditions are encountered?
 Were the constraints from the lab description adhered to?
 Did you follow all other lab description instructions?
J.E.Jones

OSU CSE 2421
 If you use it, this shell file will help you ensure that you are submitting a .zip file that will compile for the graders.
 Once you create the file in your directory, you will have to change its properties so that it will execute with the following shell command: chmod +x verify
echo “files in lab directory” ls
mkdir test
unzip lab1.zip –d test
make –C test lab1
echo “files in test directory” ls test
rm -rf test
 In each lab, you will have to change the name of the zip file and the make instruction target
J.E.Jones

OSU CSE 2421
 Take a look at the other Linux commands that are shown in the document called LabUnixCommands.pdf on Piazza.
 The commands in the pdf should be all that you’ll need for this course.
 Nonetheless, if you need to know how to do something that you haven’t done before, you can do an internet search to find the relevant commands.
 There may even be a quiz on the commands 
J.E.Jones

Leave a Reply

Your email address will not be published. Required fields are marked *