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 71.0% (up from 68.9% last January) of all the websites whose operating system we know..”
Linux is used by 48.7% (down from 53.9% last January) of all the websites whose operating system we know. (This 49.1% is a part of the 71.0% 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
No code to write
Some (short) articles to read
Some navigation within a Linux command line window
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
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 (not me).
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
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 – 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.
The graders will pull the labs from Carmen and test them on stdlinux based on the grading criteria.
J.E.Jones
OSU CSE 2421
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
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