Debugging and Tuning Linux for EDA
Total Page:16
File Type:pdf, Size:1020Kb
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 -
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. -
Rational Purifyplus for UNIX
Develop Fast, Reliable Code Rational PurifyPlus for UNIX Customers and end-users demand that your Automatically Pinpoint code works reliably and offers adequate execu- Hard-To-Find Bugs tion performance. But the reality of your deliv- Reliability problems, such as runtime errors and ery schedule often forces you to sacrifice relia- memory leaks in C/C++, can kill a software bility or performance – sometimes both. And company’s reputation. These errors are hard to without adequate time for testing, you may not find, hard to reproduce, and hardest of all, to even know these issues exist. So you reluctant- explain to customers who discover them. No ly deliver your code before it’s ready, knowing one intentionally relies on their customer as good and well that the integrity of your work their "final QA." But without adequate tools, this may be suspect. is the inevitable outcome. Even the best pro- Rational Software has a solution for ensuring grammers make mistakes in their coding. that your code is both fast and reliable. Rational PurifyPlus for UNIX automatically finds HIGHLIGHTS Rational® PurifyPlus for UNIX combines runtime these reliability errors in C/C++ code that can’t error detection, application performance profil- Automatically finds runtime be found in any other way. It finds the errors ing, and code coverage analysis into a single, errors in C/C++ code even before visible symptoms occur (such as a complete package. Together, these functions system crash or other spurious behavior). And help developers ensure the highest reliability Quickly isolates application it shows you exactly where the error originated, and performance of their software from the very performance bottlenecks regardless of how remote from the visible first release. -
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 -
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. -
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). -
The Developer's Guide to Debugging
The Developer’s Guide to Debugging Thorsten Grotker¨ · Ulrich Holtmann Holger Keding · Markus Wloka The Developer’s Guide to Debugging 123 Thorsten Gr¨otker Ulrich Holtmann Holger Keding Markus Wloka Internet: http://www.debugging-guide.com Email: [email protected] ISBN: 978-1-4020-5539-3 e-ISBN: 978-1-4020-5540-9 Library of Congress Control Number: 2008929566 c 2008 Springer Science+Business Media B.V. No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Printed on acid-free paper 987654321 springer.com Foreword Of all activities in software development, debugging is probably the one that is hated most. It is guilt-ridden because a technical failure suggests personal fail- ure; because it points the finger at us showing us that we have been wrong. It is time-consuming because we have to rethink every single assumption, every single step from requirements to implementation. Its worst feature though may be that it is unpredictable: You never know how much time it will take you to fix a bug - and whether you’ll be able to fix it at all. Ask a developer for the worst moments in life, and many of them will be related to debugging. It may be 11pm, you’re still working on it, you are just stepping through the program, and that’s when your spouse calls you and asks you when you’ll finally, finally get home, and you try to end the call as soon as possible as you’re losing grip on the carefully memorized observations and deductions. -
Heapmon: a Low Overhead, Automatic, and Programmable Memory Bug Detector ∗
Appears in the Proceedings of the First IBM PAC2 Conference HeapMon: a Low Overhead, Automatic, and Programmable Memory Bug Detector ∗ Rithin Shetty, Mazen Kharbutli, Yan Solihin Milos Prvulovic Dept. of Electrical and Computer Engineering College of Computing North Carolina State University Georgia Institute of Technology frkshetty,mmkharbu,[email protected] [email protected] Abstract memory bug detection tool, improves debugging productiv- ity by a factor of ten, and saves $7,000 in development costs Detection of memory-related bugs is a very important aspect of the per programmer per year [10]. Memory bugs are not easy software development cycle, yet there are not many reliable and ef- to find via code inspection because a memory bug may in- ficient tools available for this purpose. Most of the tools and tech- volve several different code fragments which can even be in niques available have either a high performance overhead or require different files or modules. The compiler is also of little help a high degree of human intervention. This paper presents HeapMon, in finding heap-related memory bugs because it often fails to a novel hardware/software approach to detecting memory bugs, such fully disambiguate pointers [18]. As a result, detection and as reads from uninitialized or unallocated memory locations. This new identification of memory bugs must typically be done at run- approach does not require human intervention and has only minor stor- time [1, 2, 3, 4, 6, 7, 8, 9, 11, 13, 14, 18]. Unfortunately, the age and execution time overheads. effects of a memory bug may become apparent long after the HeapMon relies on a helper thread that runs on a separate processor bug has been triggered. -
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). -
IBM Rational Purifyplus for AIX Helps Developers and Testers Deliver Applications Faster and with Fewer Errors
IBM Europe, Middle East, and Africa Software Announcement ZP09-0129, dated May 12, 2009 IBM Rational PurifyPlus for AIX helps developers and testers deliver applications faster and with fewer errors Table of contents 1 At a glance 4 Publications 1 Overview 4 Technical information 2 Key prerequisites 5 Ordering information 2 Planned availability dates 7 Terms and conditions 2 Product positioning 9 IBM Electronic Services 3 Program number 10 Prices 3 Offering Information 10 Announcement countries At a glance tm IBM® Rational® PurifyPlus for AIX® is the newest member of an award-winning family of products that provide a dynamic analysis solution designed to help developers write faster, more reliable code. It includes four basic capabilities: • Memory debugging: Pinpoints hard to find memory errors such as uninitialized memory access, buffer overflow, and improper freeing of memory. • Memory leak detection: Identifies memory blocks that no longer have a valid pointer. • Application performance profiling: Highlights application performance bottlenecks and improves application understanding with a graphical representation of function calls. • Code coverage analysis: Identifies untested code with line-level precision. Overview IBM Rational PurifyPlus for AIX is a set of dynamic analysis tools designed for improving application reliability and performance on the IBM System p® platform. The PurifyPlus software combines the following capabilities into a single, complete package: • Memory debugging • Memory leak detection • Application performance profiling • Code coverage analysis Together, these capabilities help developers and testers to realize high reliability and performance of their software from its very first release. IBM Rational PurifyPlus for AIX allows developers and testers to monitor an entire application or just a subset of an application's modules. -
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. -
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.