DOCSLIB.ORG

Access Errors, Defined, 223 Addresses, See Also Virtual Memory Addresses

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Access Errors, Defined, 223 Addresses, See Also Virtual Memory Addresses INDEX A C access errors, defined, 223 C language, see also GNU C library addresses, see also virtual memory error reporting, 213–217 addresses C99 library extensions, splint, 221 breakpoints, 68 call command, 100 arrays, see also dynamic arrays call stacks, moving up and down, 17 inspecting, 37 catchpoints artificial arrays defined, 55 DDD, 107 GDB, 48 GDB, 106 CGDB, 13 assembly language, GDB and DDD, client/server network programs, 255–258 multiprogramming attributes, breakpoints, 67–69 techniques, 145–151 command lists, breakpoints, 85–89 B commands, see also specific commands DDD, 161 backtrace, seg fault location, 4 Eclipse, 161 binary search principle GDB, 161 syntax errors, 189 commands command, 99 using, 4 compilers binary trees, example, 95 using, 212 brackets, matching, 208 warnings, 210 breakpoints, 47–94, see also compiling, 185–193 hardware-assisted breakpoints; missing libraries, 190 temporary breakpoints multi-file programs, 57 about, 47 phantom line numbers in syntax command lists, 85–89 error messages, 185–190 conditional, 79–84 conditional breakpoints DDD, 9 Eclipse, 42 deleting, disabling and moving, using, 79–84 60–66 conditional expressions, watchpoints, GDB example, 56 17 lists, 49 configure scripts, 193 persistence, 59 confirmation principle resuming execution, 69–79 about, 2 setting, 51–56 GDB, 25, 31 using, 14 Java, 239 viewing attributes, 67–69 resuming execution, 69 watchpoints, 89–94 syntax error messages, 187 bugs, memory-access and seg faults, continue command, 74 124 convenience variables build scripts, libraries, 193 names, 115 bus errors, 128 The Art of Debugging with GDB, DDD, and Eclipse (C) 2008 by Norman Matloff and Peter Jay Salzman using, 114 detecting problems, 224 core files Electric Fence library, 225–228 crashes, 129–131 GNU C library tools, 228–233 seg fault location, 4 crashes, 117–144 E core files, 129–131 Eclipse example, 131–144 about, 2 memory management, 118–129 breakpoint lists, 51 critical sections, using, 156 command summary, 161 curses programs, 194–201 conditional breakpoints, 84 versus DDD, 9 D deleting and disabling breakpoints, data section, 119 63 DDD (Data Display Debugger) example, 38–43 about, 2 inspecting variables, 103 assembly language, 255–258 Perl, 246–247 breakpoint lists, 50 Python, 250 command summary, 161 resuming execution, 79 conditional breakpoints, 83 setting breakpoints, 56 deleting and disabling breakpoints, setting variables, 113 62 using GUI, 7 versus Eclipse, 9 viewing breakpoint attributes, 69 example, 36–37 Electric Fence library, dynamically inspecting variables, 102 allocated memory, 225–228 Java, 240–241 Emacs, features, 206 moving breakpoints, 64 enabling, breakpoints, 62 Perl, 244 errno, using, 213–217 Python, 249 errors, see also access errors; bus errors; resuming execution, 78 double frees; warnings setting breakpoints, 55 compiler options for checking, 213 setting variables, 113 reporting in C, 213–217 undoing and redoing breakpoint examples, see sample programs actions, 66 exceptions, crashes, 128 using GUI, 6 execution, resuming, 69–79 viewing breakpoint attributes, 69 expressions, see also conditional defaults, signal handlers, 126 expressions deleting breakpoints, 60–64 library functions, 82 Dijkstra algorithm, 172 watchpoints, 92, 93 disabling breakpoints, 62–64 display command, 98, 102 F displaying variables, 112 faults, see segmentation faults disposition, breakpoints, 68 FIFO queue, example, 251 double frees files, see core files; startup files defined, 224 compiling multi-file programs, 57 mtrace(), 231 finish command, 74 dumping core, 129, 130 FPE (floating-point exception), 128 dynamic arrays, inspecting, 104 functions, see also specific functions dynamically allocated memory, string handling, 132 221–233 The Art of Debugging with GDB, DDD, and Eclipse (C) 2008 by Norman Matloff and Peter Jay Salzman 260 INDEX G infinite loops GDB (GNU Project Debugger), see also GDB, 27 CGDB interrupts, 4 about, 2 inspecting variables, 15 advantages, 11 installing assembly language, 255–258 DDD, 2 breakpoint lists, 49 Eclipse, 2 command summary, 161 integrated development environments conditional breakpoints, 80–83 (IDE), text editors as, 211 deleting breakpoints, 61 Intel stacks, 256 disabling breakpoints, 62 interfaces, text-based versus GUI, 5–14 example, 22–36 interrupts, infinite loops, 4 expressions, 93 inspecting variables, 98 J Java, 238–241 Java, using GDB, DDD and Eclipse, resuming execution, 70–78 236–242 setting breakpoints, 51 JDB (Java Debugger), DDD as GUI for, setting variables, 113 241 startup files, 43 TUI mode, 12 L viewing breakpoint attributes, 67 .gbdinit files, 43 layout, see program layout general protection fault, see lexical highlighting, defined, 206 segmentation fault libraries, see also C99 library GNU C library extensions; curses programs; dynamically allocated memory, Electric Fence library; GNU C 228–233 library; static libraries GNU Project Debugger, see GDB compiling missing, 190 GNU/Linux, see Linux NOW architectures, 170 guard statements, using, 156 SDSM, 170 GUI programs, 194–201 types of, 191 GUI-based tools, see also DDD (Data library calls, errno, 213 Display Debugger); Eclipse library functions advantages, 10 compared to system calls, 217 versus text-based tools, 5–14 GDB expressions, 82 using DDD as a GUI for JDB, 241 line numbers, see phantom line numbers H lint, using, 219–221 Linux, dumping core, 130 hardware watchpoints, 91 lists, see also command lists hardware-assisted breakpoints, breakpoints, 49 defined, 54 loading, 185–193 help, see online help missing libraries, 190 phantom line numbers in syntax I error messages, 185–190 IDE (integrated development local variables, monitoring, 112 environment), text editors as, loops, see infinite loops 211 ltrace, using, 217–219 identifiers, breakpoints, 49 The Art of Debugging with GDB, DDD, and Eclipse (C) 2008 by Norman Matloff and Peter Jay Salzman INDEX 261 M moving up and down call stacks, 17 makefiles stepping though source code, 14 and compiler warnings, 210 watchpoints, 17 and Vim, 209 MALLOC_CHECK_, 228 P mcheck(), 230 page tables, 122 memory, see also dynamically allocated pages memory; virtual address space; about, 121 virtual memory addresses SDMS systems, 170 examining directly, 112 parallel applications, memory leaks, mtrace, 231 multiprogramming memory management, crashes, techniques, 163–171 118–129 parentheses, balancing, 208 message passing, defined, 163 Perl, DDD and Eclipse, 242–247 message-passing systems, perror(), 216 multiprogramming persistence, breakpoints, 59 techniques, 164–169 phantom line numbers, syntax error modular approach, see top-down messages, 185–190 approach pkconfig program, 193 monitoring, local variables, 112 plain text, see text moving, breakpoints in DDD, 64 principles, 2–5, see also binary search mtrace(), 231 principle; confirmation multiprogramming techniques, principle; top-down approach 145–183 confirmation, 2 client/server network programs, other, 4 145–151 printf(), using with trace code, 3 example, 171–183 printing, variables, 112 parallel applications, 163–171 process tables, defined, 152 threaded code, 151–163 processes, defined, 152 muntrace(), 231 program layout, memory, 118 Pthreads, example, 151 N Python, DDD and Eclipse, 247–251 networks, multiprogramming techniques for client/server R network programs, 145–151 redoing breakpoint actions in DDD, 66 non-int returning functions, 83 reporting, see errors; warnings NOW architectures libraries, 170 S O sample programs inspecting and setting variables, 95, offsets, GDB, 53 109 online help introductory debugging session, about, 19 19–43 OpenMP seg faults, 131–144, 171–183 example, 171–183 setting breakpoints with GDB, 56 true shared memory, 170 threaded code, 153–161 operations, 14–18 saving symbol tables, 21 inspecting variables, 15 The Art of Debugging with GDB, DDD, and Eclipse (C) 2008 by Norman Matloff and Peter Jay Salzman 262 INDEX SDSM (software distributed shared symbol tables, saving, 21 memory), libraries, 170 syntax error messages, phantom line segmentation faults numbers, 185–190 core files, 131 syntax highlighting, text editors, 206 defined, 118 system calls, compared to library determining location, 4 functions, 217 Eclipse, 42 GDB, 32 T memory-access bugs, 124 tables, see process tables; symbol tables Unix signals, 125 tasks, see processes setting temporary breakpoints breakpoints, 51–56 defined, 52 variables, 113 Eclipse, 56 watchpoints, 90 text editors, 206–212 shared memory, defined, 163 as IDEs, 211 shared-memory systems makefiles and compiler warnings, example, 171–183 210 multiprogramming techniques, 170 matching brockets, 208 shells, core files, 130 syntax highlighting, 206 Sieve of Eratosthenes, 153 Vim and makefiles, 209 signal handlers, Unix signals, 126 text section, 118 signals text, GDB, 6 seg faults, 125 versus GUI-based tools, 5–14 Simplified Wrapper and Interface threads Generator (SWIG), using, about, 151 251–254 defined, 153 snprintf(), 143 multiprogramming techniques, sockets, using, 148 151–163 software distributed shared memory top-down approach (SDSM), libraries, 170 about, 4 source code, stepping through, 14 GDB, 29 splint, using, 220–221 stepping, 73 stack frames, 17 trace code, using, 3 stack sections, 119 trees, see binary trees stacks, see call stacks; Intel stacks TUI mode, GDB, 12 startup files, using, 43–45 static code checkers, lint and other tools, 219–221 U static libraries, using, 191 ulimit command, 131 stepping undoing breakpoint actions in DDD, into versus over a function, 72 66 through source code, 14 Unix strace, using, 217–219 signals
Load more

Recommended publications
  • Ethereal Developer's Guide Draft 0.0.2 (15684) for Ethereal 0.10.11
    Ethereal Developer's Guide Draft 0.0.2 (15684) for Ethereal 0.10.11 Ulf Lamping, Ethereal Developer's Guide: Draft 0.0.2 (15684) for Ethere- al 0.10.11 by Ulf Lamping Copyright © 2004-2005 Ulf Lamping Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation. All logos and trademarks in this document are property of their respective owner. Table of Contents Preface .............................................................................................................................. vii 1. Foreword ............................................................................................................... vii 2. Who should read this document? ............................................................................... viii 3. Acknowledgements ................................................................................................... ix 4. About this document .................................................................................................. x 5. Where to get the latest copy of this document? ............................................................... xi 6. Providing feedback about this document ...................................................................... xii I. Ethereal Build Environment ................................................................................................14 1. Introduction .............................................................................................................15
    [Show full text]
  • A.5.1. Linux Programming and the GNU Toolchain
    Making the Transition to Linux A Guide to the Linux Command Line Interface for Students Joshua Glatt Making the Transition to Linux: A Guide to the Linux Command Line Interface for Students Joshua Glatt Copyright © 2008 Joshua Glatt Revision History Revision 1.31 14 Sept 2008 jg Various small but useful changes, preparing to revise section on vi Revision 1.30 10 Sept 2008 jg Revised further reading and suggestions, other revisions Revision 1.20 27 Aug 2008 jg Revised first chapter, other revisions Revision 1.10 20 Aug 2008 jg First major revision Revision 1.00 11 Aug 2008 jg First official release (w00t) Revision 0.95 06 Aug 2008 jg Second beta release Revision 0.90 01 Aug 2008 jg First beta release License This document is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License [http:// creativecommons.org/licenses/by-nc-sa/3.0/us/]. Legal Notice This document is distributed in the hope that it will be useful, but it is provided “as is” without express or implied warranty of any kind; without even the implied warranties of merchantability or fitness for a particular purpose. Although the author makes every effort to make this document as complete and as accurate as possible, the author assumes no responsibility for errors or omissions, nor does the author assume any liability whatsoever for incidental or consequential damages in connection with or arising out of the use of the information contained in this document. The author provides links to external websites for informational purposes only and is not responsible for the content of those websites.
    [Show full text]
  • Hands on #1 Overview
    Hands On #1 ercises Overview See Wednesday’ s hands on Part Where1 : Starting is your andinstallation familiarizing ? Getting the example programs Running novice examples : N01, N03, N02 … Part Examine2 : Looking cross into sections Geant4, trying it out with ex Simulate depth dose curve Compute and plot Bragg curve Addenda : other examples, histogramming Your Geant4 installation VMware Player users under Windows or Mac OS all files downloaded from http://geant4.in2p3.fr/cenbg/vmware.html in principle, no installation needed all your peripherals should be operational (WiFi, disks,…) Installation from beginning CERN link http://geant4.web.cern.ch/geant4/support/download.shtml SLAC link http://geant4.slac.stanford.edu/installation/ User forum http://geant4-hn.slac.stanford.edu:5090/HyperNews/public/get/installconfig.html Installation guide http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/InstallationGuide/html/index.html This Hands On will help you check your installation of Geant4 is correct If not, we can try to help during this Hands On… Access your Geant4 installation for VMware users Start the VMware player software Start your VMware machine Log onto the VMware machine Username: local1 , password: local1 Open a terminal (right click on desktop with mouse) You are now working under Scientific Linux 4.2 with gcc 3.4.4 By default on your Windows PC, the directory /mnt/hgfs/echanges is a link to C:\ Tips for VMware users (1/2) Geant4 8.3 installation path : /usr/local/geant4 you need root privileges
    [Show full text]
  • Source Level Debugging GDB: Gnu Debugger Starting/Exiting GDB Stopping and Continuing the Execution of Your Program In
    Source Level Debugging GDB: Gnu DeBugger ● A source level debugger has a number of useful features that facilitates debugging problems ● GDB is a line oriented debugger where actions associated with executing your program. are issued by typing in commands. ● You have to create symbolic table information ● It can be invoked for executables compiled by within the executable by using the -g option when gcc or g++ with the -g option. compiling with gcc or g++. ● General capabilities: ● This symbolic table information includes the correspondances between – Starting/exiting your program from the debugger. – Stopping and continuing the execution of your – statements in the source code and locations of instructions program. in the executable – Examining the state of your program. – variables in the source code and locations in the data areas of the executable – Changing state in your program. Starting/Exiting GDB Stopping and Continuing the ● Bring up the gdb debugger by typing: Execution of Your Program in GDB gdb executable_name ● Setting and deleting breakpoints. ● Initiate your executable by using the command: run [command-line arguments] ● Execution stepping and continuing. – Command line arguments can include anything that would normally appear after the executable name on the command line. ● run-time options, filenames, I/O redirection, etc. – When no arguments are specified, then gdb uses the arguments specified for the previous run command during the current gdb session. ● Exit the gdb debugger by typing: quit Setting and Deleting Breakpoints Examples of Setting and Deleting Breakpoints ● Can set a breakpoint to stop: – at a particular source line number or function (gdb) break # sets breakpoint at current line # number – when a specified condition occurs (gdb) break 74 # sets breakpoint at line 74 in the # current file ● General form.
    [Show full text]
  • Appendix B Development Tools
    Appendix B Development Tools Problem Statement Although more proprietary packages are available, there are abundant open source packages, giving its users unprecedented flexibility and freedom of choice, that most users can find an application that exactly meets their needs. However, it is also this pool of choices that drive individuals to share a wide range of preferences and biases. As a result, Linux/Open source packages (and softeware in general) is flooded with religious wars over programming languages, editors, licences, etc. Some are worthwhile debates, others are meaningless flamewars. Throughout Appendix B and next chapter, Appendix C, we intend to summarize a few essential tools (from our point of view) that may help readers to know the aspects and how-to of (1) development tools including programming, debugging, and maintaining, and (2) network experiment tools including name-addressing, perimeter probing, traffic-monitoring, benchmarking, simulating/emulating, and finally hacking. Section B.1 guides readers to begin the developing journey with programming tools. A good first step would be writing the first piece of codes using a Visual Improved (vim) text editor. Then compiling it to binary executables with GNU C compiler (gcc), and furthermore offloading some repetitive compiling steps to the make utility. The old 80/20 rule still works on programming where 80% of your codes come from 20% of your efforts leaving 80% of your efforts go buggy about your program. Therefore you would need some debugging tools as dicussed in Section 1.2. including source-level debugging, GNU Debugger (gdb), or a GUI fasion approach, Data Display Debugger (ddd), and debug the kernel itself using remote Kernel GNU Debugger (kgdb).
    [Show full text]
  • The Data Display Debugger Ddd [−−Gdb] [−−Dbx] [−−Xdb] [−−Jdb]
    () () NAME ddd, xddd - the data display debugger SYNOPSIS ddd [ −−gdb ][−−dbx ][−−xdb ][−−jdb ][−−pydb ][−−perl ][−−debugger name ][−−[r]host [username@]hostname ]] [−−help ][−−trace ][−−version ][−−configuration ][options... ] [ program [ core | process-id ]] but usually just ddd program DESCRIPTION The purpose of a debugger such as DDD 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 crashed. DDD can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act: • 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. “Classical” UNIX debuggers such as the GNU debugger (GDB) provide a command-line interface and a multitude of commands for these and other debugging purposes. DDD is a comfortable graphical user interface around an inferior GDB, DBX, XDB, JDB, Python debugger, or Perl debugger. INVOKING DDD You can run DDD with no arguments or options. However, the most usual way to start DDD is with one argument or two, specifying an executable program as the argument: ddd program You can also start with both an executable program and a core file specified: ddd program core You can, instead, specify a process ID as a second argument, if you want to debug a running process: ddd program 1234 would attach DDD to process 1234 (unless you also have a file named ‘ 1234 ’; DDD does check for a core file first).
    [Show full text]
  • Debugging and Tuning Linux for EDA
    Debugging and Tuning Linux for EDA Fabio Somenzi [email protected] University of Colorado at Boulder Outline Compiling gcc icc/ecc Debugging valgrind purify ddd Profiling gcov, gprof quantify vtl valgrind Compiling Compiler options related to static checks debugging optimization Profiling-driven optimization Compiling with GCC gcc -Wall -O3 -g reports most uses of potentially uninitialized variables -O3 (or -O6) necessary to trigger dataflow analysis can be fooled by if (cond) x = VALUE; ... if (cond) y = x; Uninitialized variables not considered for register allocation may escape Achieving -Wall-clean code is not too painful and highly desirable Compiling C code with g++ is more painful, but has its rewards Compiling with GCC gcc -mcpu=pentium4 -malign-double -mcpu=pentium4 optimizes for the Pentium 4, but produces code that runs on any x86 -march=pentium4 uses Pentium 4-specific instructions -malign-double forces alignment of double’s to double-word boundary Use either for all files or for none gcc -mfpmath=sse Controls the use of SSE instructions for floating point For complete listing, check gcc’s info page under Invoking gcc ! Submodel Options Compiling with ICC ICC is the Intel compiler for IA-32 systems. http://www.intel.com/software/products/ icc -O3 -g -ansi -w2 -Wall Aggressive optimization Retain debugging info Strict ANSI conformance Display remarks, warnings, and errors Enable all warnings Remarks tend to be a bit overwhelming Fine grain control over diagnostic: see man page Compiling with ICC icc -tpp7 Optimize instruction scheduling
    [Show full text]
  • The Visual Development of GCC Plug-Ins with GDE
    The Visual Development of GCC Plug-ins with GDE Daniel J. Dean Sean Callanah Erez Zadok Stony Brook University Stony Brook University Stony Brook University [email protected] [email protected] [email protected] Appears in the Proceedings of the 2009 GCC Developers’ Summit Abstract application-specific custom optimizations, integrated type checking, function call logging, or parallism to Being able to directly affect code compilation with code code at compile time [2] [30] [24] [21]. Code trans- transformations allows the seamless addition of custom formations give developers this ability by modify- optimizations and specialized functionality to code at ing the compiler’s internal representation of compiling compile time. Traditionally, this has only been possi- code. The traditional development of code transforma- ble by directly modifying compiler source code: a very tions,however, requires the direct modification of com- difficult task. Using GCC plug-ins, developers can di- piler source files, a difficult and error prone task. As rectly affect code compilation, without actually modi- Section 3 explains, GNU Compiler Collection (GCC) fying the source code of GCC. While this makes ap- plug-ins are code transformations which do not require plying a completed plug-in easy, plug-in development the developer modify the compiler source itself [6]. Al- is transformation development nonetheless: an arduous though this makes the application and deployment of task. The plug-in developer is required to have the same completed transformations a relatively simple process, thorough understanding of compiler internals, complex plug-in development is an arduous task. compiler internal representations, and non-trivial source to internal representation mappings as any other trans- The GCC developer community has a great deal of ex- formation developer.
    [Show full text]
  • Professional Linux Programming.Pdf
    01_776130 ffirs.qxp 2/2/07 10:13 PM Page iii Professional Linux® Programming Jon Masters Richard Blum 01_776130 ffirs.qxp 2/2/07 10:13 PM Page ii 01_776130 ffirs.qxp 2/2/07 10:13 PM Page i Professional Linux® Programming 01_776130 ffirs.qxp 2/2/07 10:13 PM Page ii 01_776130 ffirs.qxp 2/2/07 10:13 PM Page iii Professional Linux® Programming Jon Masters Richard Blum 01_776130 ffirs.qxp 2/2/07 10:13 PM Page iv Professional Linux® Programming Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2007 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data: Masters, Jon, 1981- Professional Linux programming / Jon Masters, Richard Blum. p. cm. Includes index. ISBN: 978-0-471-77613-0 (paper/website) 1. Linux. 2. Operating systems (Computers) I. Blum, Richard, 1962- II. Title. QA76.76.O63M37153 2007 005.4’32—dc22 2006102202 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600.
    [Show full text]
  • ANIMAL-FARM: an Extensible Framework for Algorithm Visualization
    ANIMAL-FARM: An Extensible Framework for Algorithm Visualization Vom Fachbereich Elektrotechnik und Informatik der Universitat¨ Siegen zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften (Dr.-Ing.) genehmigte Dissertation von Diplom-Informatiker Guido Roßling¨ geboren in Darmstadt 1. Gutachter: Prof. Dr. Bernd Freisleben 2. Gutachter: Prof. Dr. Mira Mezini Tag der mundlichen¨ Prufung:¨ 11. April 2002 ii Acknowledgments The material presented in this thesis is based on my research during my time as a research assistant in the Parallel Systems Research Group at the Department of Electrical Engineering and Computer Science at the University of Siegen, Germany. I would like to thank all collaboration partners who made this research enjoyable and productive. Apart from many discussion partners at conferences who offered insights or sparked ideas, I want to thank some persons individually. First of all, I want to thank my academic mentor Bernd Freisleben who gave me the freedom needed for developing this thesis. He also supported the incorporation of algorithm visualizations in the Introduction to Computer Science course. Apart from giving hints on academic research techniques and assisting me in writing papers, he has also graciously invested much financial support into the stressful year of 2000, when I was presenting my research status at six conferences. I also wish to thank my second advisor Mira Mezini for her advice in software engineering aspects. Her insights on developing adaptable software systems gave me a starting point for my exploration of dynamically configurable and extensible software. Several members at the department have helped developing ANIMAL-FARM and the ANIMAL sys- tem. Markus Schuler¨ helped to design and implement the first ANIMAL prototype as his Mas- ter’s Thesis.
    [Show full text]
  • Used Tools and Mechanisms in Open Source Projects (A School Seminar Work)
    Used tools and mechanisms in Open Source projects (a school seminar work) Heikki Orsila <heikki.orsila@iki.fi> 2007-03-08 This document may be used and distributed under GNU Free Documen- tation (http://www.gnu.org/copyleft/fdl.html) and/or Commons Attribution- Share Alike 2.5 (http://creativecommons.org/licenses/by-sa/2.5/) license con- ditions. 0-0 1 Outline • Present some common tools and mechanisms used in developing Open Source projects • Focuses on GNU/Linux and UNIX-like operating systems, other oper- ating systems are ignored • Focuses on C language tools, since C is the dominant language used in Open Source operating systems • Presents only Open Source tools • The purpose is to only present most popular tools and most common mechanisms in development • This document was created from following information sources: – Freshmeat: http://freahmeat.net is an excellent source for finding UNIX programs by category, see http://freshmeat.net/browse/18/ 0-1 – Wikipedia – Google – Personal experience ;) – Acquaints from IRCNet ;) 0-2 • Topics of this presentation are: – Section 2: Compilers and linkers – Section 3: Interpreted languages – Section 4: Source code tools – Section 5: Debugging tools – Section 6: Documentation tools – Section 7: Version control tools – Section 8: Text editors – Section 9: Building tools – Section 10: Integrated development environments (IDEs) – Section 11: Reverse engineering tools – Section 12: Compression, cryptography and packaging tools – Section 13: Network tools – Section 14: Emulators 0-3 2 Compilers and linkers • A compiler is the main tool for programming • A compiler translates source code into executable format, possibly opti- mising and verifying the code for correctness • C is the most widely used programming language on UNIX systems and GNU C compiler is the most popular compiler • GNU Compiler Collection (GCC ) provides compilers for Ada, C, C++, Objective-C, Fortran and Java.
    [Show full text]
  • CSE 303 Lecture 13A
    CSE 303 Lecture 13a Debugging C programs reading: Programming in C Ch. 13 slides created by Marty Stepp http://www.cs.washington.edu/303/ 1 gdb • gdb : GNU debugger. Helps you step through C programs. absolutely essential for fixing crashes and bad pointer code your program must have been compiled with the -g flag • usage: $ gdb program GNU gdb Fedora (6.8-23.fc9) Copyright (C) 2008 Free Software Foundation, Inc... (gdb) run parameters ... • redirecting input: $ gdb program (gdb) run parameters < inputfile 2 gdb commands command description run or r parameters run the program break or b place sets a breakpoint at the given place: - a function's name - a line number - a source file : line number print or p expression prints the given value / variable step or s advances by one line of code ("step into") next or n advances by one line of code ("step over") finish runs until end of function ("step out") continue or c resumes running program backtrace or bt display current function call stack quit or q exits gdb 3 A gdb session $ gdb intstack GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. (gdb) b 34 Breakpoint 1 at 0x4010ea: file intstack.c, line 34. (gdb) r Starting program: /home/user/intstack Breakpoint 1, main () at intstack.c:34 34 Node* oldFront = stack; (gdb) p stack $1 = (Node *) 0x4619c0 (gdb) n 35 printf("%d\n", stack->data); (gdb) n 36 stack = stack->next; (gdb) n 37 free(oldFront); (gdb) p stack $4 = (Node *) 0x462856 (gdb) p oldFront $2 = (Node *) 0x4619c0 (gdb) p *oldFront $3 = {data = 10, next = 0x462856} (gdb) c Continuing.
    [Show full text]