DOCSLIB.ORG

Undefined Behaviour in Language C

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Undefined Behaviour in Language C MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Undefined behaviour in language C MASTER’S THESIS Branislav Košˇcák Brno, autumn 2014 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Branislav Košˇcák Advisor: Mgr. Marek Grác, Ph.D. ii Acknowledgement I am very grateful to my supervisor Miroslav Franc for his guidance, invaluable help and feedback throughout the work on this thesis. iii Abstract This Master’s Thesis deals with the concept of undefined behaviour in the C language from the point of view of a tester and a developer. It further describes what the purpose of undefined behaviour is, why it is dangerous, and it provides a summary of the current state regard- ing prevention and detection of undefined behaviour. Blind spots where there is currently no tool available are identified. The thesis contains a set of sample programs. iv Keywords undefined behaviour, C, testing, programming language, exploit, stan- dard, detection v Contents 1 Introduction ............................1 1.1 ISO requirements......................1 1.2 Analysis Tools........................3 1.3 Goals.............................4 2 Undefined Behaviour ......................5 2.1 Reason for Undefined Behaviour.............5 2.1.1 Performance – compile/run-time........5 2.1.2 Support of HW portability............6 2.2 Drawbacks of Undefined Behaviour...........7 3 Analyzed Undefined Behaviours ................9 3.1 Object Lifetime.......................9 3.1.1 Detection...................... 10 3.2 Integer Overflow...................... 11 3.2.1 Detection...................... 13 3.3 Integer Conversion..................... 13 3.3.1 Detection...................... 14 3.4 Void Expression....................... 15 3.5 Pointer Conversion..................... 16 3.6 Pointer to Function..................... 17 3.6.1 Detection...................... 18 3.7 Modifying String Literal.................. 19 3.8 Sequence Points....................... 20 3.8.1 Detection...................... 21 3.9 Function Prototype..................... 22 3.10 Pointer Type......................... 23 3.11 Use of Library Functions.................. 24 3.11.1 Detection...................... 25 3.12 Pointer Arithmetic..................... 26 3.12.1 Detection...................... 27 3.13 Shifting Overflow...................... 28 3.13.1 Detection...................... 29 3.14 Pointers Comparison.................... 29 3.14.1 Detection...................... 30 3.15 Integer Constant Expression................ 31 3.16 Longjmp/Setjmp...................... 32 vi 3.16.1 Detection...................... 33 3.17 Multiple External Definitions............... 34 3.18 Pointer to FILE....................... 35 3.19 Output Functions...................... 36 3.20 Copy of Overlapping Objects............... 37 3.20.1 Detection...................... 39 4 Conclusion ............................. 40 Bibliography.............................. 43 A Shared Library Implementation ................ 44 B Content of the CD-ROM ..................... 46 vii 1 Introduction Nowadays there are various types of programming languages avail- able. They differ by programming style – paradigm, by syntax and semantics they use, whether they are strongly or weakly typed and by other specifications. It is natural that single programming lan- guage cannot handle all tasks equally efficiently. Performing quick queries on a large database requires different approach than low level GPU programming. Every language has its advantages and limita- tions. Mastering both minimizes errors and also leads to better per- formance and an effective code. In 1972 C programming language was developed. Combination of principles and main features of BCPL and B programming lan- guage resulted into creation of C. It soon spread among universities and became used by several organizations. The problem was that dif- ferent versions of C were used what caused compatibility problems. It was necessary to establish a standard definition of C. The first was ANSI C (later adopted by ISO organization and thus referred as ISO C). The standard has been evolving, undergoing several changes and adding new features that were lacking in previous standards. The current standard for C programming language is C11 [9]. C is imperative programming language. It is a flexible program- ming language whose important feature is that it allows low level programming while using syntax of high level languages. It allows fast program execution, has ability to manipulate with memory on low level. C is weakly typed. No bounds checking and pointer valid- ity checking improves the performance of C programs. This is pow- erful tool for experienced programmer. On the other hand it can lead to severe problems and undesired results when used inappropriately. 1.1 ISO requirements C programming language comes with additional concepts whose knowledge is required when programming. Unspecified behaviour, implementation-defined behaviour and undefined behaviour are as- pects of C which may cause programs to misbehave, even though a compiler does not report any error. However, as it often happens, af- 1 1. INTRODUCTION ter a change in compiler implementation or language specification, the program may suddenly stop working. Unspecified behaviour is defined as the use of an unspecified value, or other behaviour where by standard two or more options are possible, and it is not specified which one would be chosen. For example order in which the operands of an assignment operator are evaluated. Program that contains unspecified behaviour but is cor- rect in all other aspects is considered to be correct. Implementation-defined behaviour is like unspecified behaviour where operations and choices that are made are described with re- spect to implementation documents. For example the number of bits in a byte. In ISO C undefined behaviour is described as "behaviour, upon use of a non-portable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements". As there are no constraints, a program containing undefined behaviour can be- have in an expected way, it can crash or run with unpredictable re- sults with or without an issuance of a diagnostic messages. The specification of C language contains full list of program con- structs that will lead to undefined behaviour. The occurrence can be of different type. From preprocessor directives, functions decla- rations, expression evaluation or calling library functions. Causing undefined behaviour should be avoided as it may lead into undesired interpretations. In better case program would not work. But because results can be arbitrary there is also a possibility that it could be exploited. As stated in C specification, signed integer overflow causes un- defined behaviour. Example [7] of the real situation when this could have been exploited, is the Linux kernel 2.4.25 and earlier where inte- ger overflow in the SCTP_SOCKOPT_DEBUG_NAME SCTP socket option in socket.c allowed local users to execute arbitrary code. Since C programming language imposes only a few constraints on a programmer it can easily result into problems that may be diffi- cult to discover. There are many tools available to aid programmers to avoid some of the problems that can occur in a code and may re- main hidden as they are not reported by a compiler. Analysis can be static (compile-time) or dynamic (run-time), performed on source code or binary. 2 1. INTRODUCTION 1.2 Analysis Tools One of the main problems with undefined behaviour is that the range of possible errors is quite wide, the C specification lists more than 190 types of undefined behaviour. Unless a programmer knows the C standard, it is easy to make a mistake. The programmer may not even know that there is something wrong with the code. For exam- ple null pointer dereference is known bug which usually leads into a program crash. This kind of error is frequent and programmers usu- ally pay attention to prevent it. Even though statement like a[i] = i++; does not look suspicious, it is by the standard considered to be unde- fined. Again, consequences may or may not occur. Expressions like this usually do not cause program to crash, just results of program computation can be unexpected and it may be difficult to find the reason. i = i + 1; //Well defined behaviour i = i++ + 1; //Undefined behaviour Figure 1.1: Defined versus undefined behaviour The need for automated code check is obvious. For undefined be- haviour detection both static and dynamic analyzers are available. Clang is a front-end for the LLVM compiler [12] which comes with several sanitizers such as memory, address and also undefined be- haviour sanitizer. Analyzers that explicitly do not seek undefined behaviour can be used as well. For example the programming tool that detects er- rors at run-time – Valgrind [17]. Even though the main usage of Val- grind tool Memcheck is connected with memory issues, it can dis- cover problems resulting from undefined behaviour (out of bound access, multiple free memory). There are various static analyzers such as Clang Static Analyzer [13], Cppcheck [3], Splint [16] available too. They provide checkers that can detect numerous problems. Apart from performance, there are areas where results of static analysis differs from dynamic code check. 3 1. INTRODUCTION 1.3
Load more

Recommended publications
  • Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++
    Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++ Christopher S. Zakian, Timothy A. K. Zakian Abhishek Kulkarni, Buddhika Chamith, and Ryan R. Newton Indiana University - Bloomington, fczakian, tzakian, adkulkar, budkahaw, [email protected] Abstract. Library and language support for scheduling non-blocking tasks has greatly improved, as have lightweight (user) threading packages. How- ever, there is a significant gap between the two developments. In previous work|and in today's software packages|lightweight thread creation incurs much larger overheads than tasking libraries, even on tasks that end up never blocking. This limitation can be removed. To that end, we describe an extension to the Intel Cilk Plus runtime system, Concurrent Cilk, where tasks are lazily promoted to threads. Concurrent Cilk removes the overhead of thread creation on threads which end up calling no blocking operations, and is the first system to do so for C/C++ with legacy support (standard calling conventions and stack representations). We demonstrate that Concurrent Cilk adds negligible overhead to existing Cilk programs, while its promoted threads remain more efficient than OS threads in terms of context-switch overhead and blocking communication. Further, it enables development of blocking data structures that create non-fork-join dependence graphs|which can expose more parallelism, and better supports data-driven computations waiting on results from remote devices. 1 Introduction Both task-parallelism [1, 11, 13, 15] and lightweight threading [20] libraries have become popular for different kinds of applications. The key difference between a task and a thread is that threads may block|for example when performing IO|and then resume again.
    [Show full text]
  • User's Manual
    rBOX610 Linux Software User’s Manual Disclaimers This manual has been carefully checked and believed to contain accurate information. Axiomtek Co., Ltd. assumes no responsibility for any infringements of patents or any third party’s rights, and any liability arising from such use. Axiomtek does not warrant or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information in this document. Axiomtek does not make any commitment to update the information in this manual. Axiomtek reserves the right to change or revise this document and/or product at any time without notice. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Axiomtek Co., Ltd. Trademarks Acknowledgments Axiomtek is a trademark of Axiomtek Co., Ltd. ® Windows is a trademark of Microsoft Corporation. Other brand names and trademarks are the properties and registered brands of their respective owners. Copyright 2014 Axiomtek Co., Ltd. All Rights Reserved February 2014, Version A2 Printed in Taiwan ii Table of Contents Disclaimers ..................................................................................................... ii Chapter 1 Introduction ............................................. 1 1.1 Specifications ...................................................................................... 2 Chapter 2 Getting Started ......................................
    [Show full text]
  • Cg 2015 Huong Vu Thanh
    c 2015 Huong Vu Thanh Luu OPTIMIZING I/O PERFORMANCE FOR HIGH PERFORMANCE COMPUTING APPLICATIONS: FROM AUTO-TUNING TO A FEEDBACK-DRIVEN APPROACH BY HUONG VU THANH LUU DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign, 2015 Urbana, Illinois Doctoral Committee: Professor Marianne Winslett, Chair Professor William Gropp, Director of Research Professor Marc Snir Dr Robert Ross, Argonne National Laboratory ABSTRACT The 2014 TOP500 supercomputer list includes over 40 deployed petascale systems, and the high performance computing (HPC) community is working toward developing the first exaflop system by 2023. Scientific applications on such large-scale computers often read and write a lot of data. With such rapid growth in computing power and data intensity, I/O continues to be a challenging factor in determining the overall performance of HPC applications. We address the problem of optimizing I/O performance for HPC applica- tions by firstly examining the I/O behavior of thousands of supercomputing applications. We analyzed the high-level I/O logs of over a million jobs rep- resenting a combined total of six years of I/O behavior across three leading high-performance computing platforms. Our analysis provides a broad por- trait of the state of HPC I/O usage. We proposed a simple and e↵ective analysis and visualization procedure to help scientists who do not have I/O expertise to quickly locate the bottlenecks and inefficiencies in their I/O ap- proach. We proposed several filtering criteria for system administrators to find application candidates that are consuming system I/O resources ineffi- ciently.
    [Show full text]
  • Shared Memory Programming
    Outline •" Parallel Programming with Threads Shared Memory Programming: •" Parallel Programming with OpenMP •" See parlab.eecs.berkeley.edu/2012bootcampagenda •" 2 OpenMP lectures (slides and video) by Tim Mattson Threads and OpenMP •" openmp.org/wp/resources/ •" computing.llnl.gov/tutorials/openMP/ •" portal.xsede.org/online-training Lecture 6 •" www.nersc.gov/assets/Uploads/XE62011OpenMP.pdf •" Slides on OpenMP derived from: U.Wisconsin tutorial, which in turn were from LLNL, NERSC, U. Minn, and OpenMP.org James "Demmel •" See tutorial by Tim Mattson and Larry Meadows presented at www.cs.berkeley.edu/~demmel/cs267_Spr16/! SC08, at OpenMP.org; includes programming exercises ! •" (There are other Shared Memory Models: CILK, TBB…) •" Performance comparison •" Summary CS267 Lecture 6! 1! 02/04/2016 CS267 Lecture 6! 2! Recall Programming Model 1: Shared Memory •" Program is a collection of threads of control. •" Can be created dynamically, mid-execution, in some languages •" Each thread has a set of private variables, e.g., local stack variables •" Also a set of shared variables, e.g., static variables, shared common Parallel Programming blocks, or global heap. with Threads" •" Threads communicate implicitly by writing and reading shared variables. •" Threads coordinate by synchronizing on shared variables Shared memory s s = ... y = ..s ... i: 2 i: 5 Private i: 8 memory P0 P1 Pn CS267 Lecture 6! 3! 02/04/2016 CS267 Lecture 6! 4! CS267 Lecture 2 1 Shared Memory Programming Common Notions of Thread Creation Several Thread Libraries/systems
    [Show full text]
  • Embedded Multicore: an Introduction
    Embedded Multicore: An Introduction EMBMCRM Rev. 0 07/2009 How to Reach Us: Home Page: www.freescale.com Web Support: http://www.freescale.com/support Information in this document is provided solely to enable system and software USA/Europe or Locations Not Listed: implementers to use Freescale Semiconductor products. There are no express or Freescale Semiconductor, Inc. implied copyright licenses granted hereunder to design or fabricate any integrated Technical Information Center, EL516 circuits or integrated circuits based on the information in this document. 2100 East Elliot Road Tempe, Arizona 85284 Freescale Semiconductor reserves the right to make changes without further notice to +1-800-521-6274 or any products herein. Freescale Semiconductor makes no warranty, representation or +1-480-768-2130 www.freescale.com/support guarantee regarding the suitability of its products for any particular purpose, nor does Freescale Semiconductor assume any liability arising out of the application or use of Europe, Middle East, and Africa: Freescale Halbleiter Deutschland GmbH any product or circuit, and specifically disclaims any and all liability, including without Technical Information Center limitation consequential or incidental damages. “Typical” parameters which may be Schatzbogen 7 provided in Freescale Semiconductor data sheets and/or specifications can and do 81829 Muenchen, Germany vary in different applications and actual performance may vary over time. All operating +44 1296 380 456 (English) +46 8 52200080 (English) parameters, including “Typicals” must be validated for each customer application by +49 89 92103 559 (German) customer’s technical experts. Freescale Semiconductor does not convey any license +33 1 69 35 48 48 (French) under its patent rights nor the rights of others.
    [Show full text]
  • LTIB Build Host Setup
    LTIB Build Host Setup Setting up a Linux host for LTIB builds We support building using Ubuntu 9.04 (Jaunty) installed from the 32 or 64 bit Desktop Ubuntu install cd. Other versions of Ubuntu are not currently supported and may have build issues. Sudoers Run 'sudo visudo' so you can edit the sudoer's file. Add the following line to the end of the sudoers file. This is needed for people to be able to use LTIB. This assumes that all your developers have administrator priviledges on this host. If that is not the case, a similar line can be added for each user. %admin ALL = NOPASSWD: /usr/bin/rpm, /opt/freescale/ltib/usr/bin/rpm Update to the latest packages Open up System -> Administration -> Update Manager Click on Settings Open the Updates Tab Set 'Release upgrade' to 'Never'. That makes the option to upgrade to Karmic go away. Close the settings dialog box. Click on 'Check' to check for upgraded packages. It will look for packages that are upgraded from the version that is installed on your box. Choose to install the upgrades. This will take a while on a freshly installed box. Install host packages needed by LTIB This document assumes you are using Ubuntu. Not a requirement, but the packages may be named differently and the method of installing them may be different. sudo aptitude -y install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev sudo aptitude -y install libdbus-glib-1-dev liborbit2-dev intltool sudo aptitude -y install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool sudo aptitude -y install uuid-dev liblzo2-dev sudo aptitude -y install tcl Packages required for 64-bit Ubuntu If you don't know whether you have 64-bit Ubuntu installed, do "uname -a" and see if the word "x86_64" shows up.
    [Show full text]
  • Scala Native Documentation Release 0.3.2
    Scala Native Documentation Release 0.3.2 Denys Shabalin Aug 08, 2017 Contents 1 Community 3 2 Documentation 5 2.1 User’s Guide...............................................5 2.2 Libraries................................................. 15 2.3 Contributor’s Guide........................................... 31 2.4 Changelog................................................ 48 2.5 FAQ.................................................... 49 i ii Scala Native Documentation, Release 0.3.2 Scala Native is an optimizing ahead-of-time compiler and lightweight managed runtime designed specifically for Scala. It features: • Low-level primitives. type Vec = CStruct3[Double, Double, Double] val vec = stackalloc[Vec] // allocate c struct on stack !vec._1 = 10.0 // initialize fields !vec._2 = 20.0 !vec._3 = 30.0 length(vec) // pass by reference Pointers, structs, you name it. Low-level primitives let you hand-tune your application to make it work exactly as you want it to. You’re in control. • Seamless interop with native code. @extern object stdlib { def malloc(size: CSize): Ptr[Byte] = extern } val ptr = stdlib.malloc(32) Calling C code has never been easier. With the help of extern objects you can seamlessly call native code without any runtime overhead. • Instant startup time. > time hello-native hello, native! real 0m0.005s user 0m0.002s sys 0m0.002s Scala Native is compiled ahead-of-time via LLVM. This means that there is no sluggish warm-up phase that’s common for just-in-time compilers. Your code is immediately fast and ready for action. Contents 1 Scala Native Documentation, Release 0.3.2 2 Contents CHAPTER 1 Community • Want to follow project updates? Follow us on twitter. • Want to chat? Join our Gitter chat channel.
    [Show full text]
  • PLAN 9 from BELL LABS PROGRAMMER's MANUAL
    PLAN 9 from BELL LABS PROGRAMMER’S MANUAL First Edition Computing Science Research Center AT&T Bell Laboratories Murray Hill, New Jersey -- Copyright © 1993 AT&T Unpublished and not for publication All Rights Reserved PostScript and ThinkJet are registered trademarks. PERMUTED INDEX Manual pages for all sections are accessible on line through m a n(1). To save space, neighboring references to the same page have been collapsed into a single reference. This should cause no difficulty in cases like ‘atan’ and ‘atan2’, but is somewhat obscure in the case of ‘strcat’ and ‘strchr’. Disclabel – / . home, 40meg, 80meg, 100meg, newkernel, personalize, update, . home(8) floyd, halftone, hysteresis – create 1-bit images by dithering . floyd(9.1) hp – emulate an HP 2621 terminal . hp(1) 2a, 6a, 8a, ka, va, za – assemblers . 2a(1) 2c, 6c, 8c, kc, vc, zc – C compilers . 2c(1) 2l, 6l, 8l, kl, vl, zl – loaders . 2l(1) c++/2c, c++/kc, c++/vc, c++/8c, c++/zc, c++/ 2l, c++/kl, c++/vl, c++/8l, c++/zl – C++/ . c++(1) picture color compression . 3to1, mcut, improve, quantize, dither – . quantize(9.1) update, Disclabel – administration for/ . home, 40meg, 80meg, 100meg, newkernel, personalize, . home(8) smiley, life, fsim, clock, catclock,/ . 4s, 5s, ana, gnuchess, juggle, mandel, plumb, quiz, . games(1) 2a, 6a, 8a, ka, va, za – assemblers . 2a(1) 2c, 6c, 8c, kc, vc, zc – C compilers . 2c(1) 2l, 6l, 8l, kl, vl, zl – loaders . 2l(1) 8½ – window system files . 8½(4) 8½, label, window, wloc – window system . 8½(1) Disclabel – administration for/ . home, 40meg, 80meg, 100meg, newkernel, personalize, update, .
    [Show full text]
  • ELC 2008 Agenda
    Embedded Linux Conference, 2008 Program Agenda Mountain View, California, April 15-17 Table of Contents Agenda...............................................................................................................................2 Tuesday...........................................................................................................................2 Wednesday......................................................................................................................3 Thursday.........................................................................................................................4 Keynote List........................................................................................................................5 Keynote Descriptions.........................................................................................................5 Session List........................................................................................................................7 Session Descriptions..........................................................................................................9 BOF List............................................................................................................................30 BOF Descriptions.............................................................................................................30 Agenda Tuesday Session Schedule - Tuesday, April 15 Time Room A - Hahn Room B - Boole Room C - Noyce 8:00 - 900 Registration 9:00 - 9:50 Keynote:
    [Show full text]
  • VAB-800 Linux BSP 1.4
    DEVELOPMENT GUIDE VAB-800 Linux BSP 1.4 1.4-09222014-165700 Copyright Copyright © 2014-VIA Technologies Incorporated. All rights reserved. No part of this document may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual or otherwise without the prior written permission of VIA Technologies, Incorporated. Trademarks All brands, product names, company names, trademarks and service marks are the property of their respective holders. Disclaimer VIA Technologies makes no warranties, implied or otherwise, in regard to this document and to the products described in this document. The information provided in this document is believed to be accurate and reliable as of the publication date of this document. However, VIA Technologies assumes no responsibility for the use or misuse of the information in this document and for any patent infringements that may arise from the use of this document. The information and product specifications within this document are subject to change at any time, without notice and without obligation to notify any person of such change. VIA Technologies, Inc. reserves the right the make changes to the products described in this manual at any time without prior notice. VABVAB----8080808000 Linux BSP V1.V1.4444 Development Guide Revision History Version DateDateDate Remarks 1.0 12/24/2012 Initial external release 1.1 4/2/2013 Added the eMMC evaluation kit process in Appendix A Modified Micro SD/eMMC partition method in Chapter 4 1.2 4/19/2013 Added the ADI ADV7511W in Step 10 of 3.2.2 Run Ltib to build VAB-800 BSP 1.3 8/14/2014 Modified the necessary packages and patch of Ltib for Ubuntu 12.04 64bit host development PC 1.4 9/17/2014 Added Xrandr dual display setting in Appendix.E iii VABVAB----8080808000 Linux BSP V1.V1.4444 Development Guide Table of Contents 1.1.1.
    [Show full text]
  • In the Beginning
    The Embedded Linux Quick Start Guide In the Beginning... Chris Simmonds Embedded Linux Conference Europe 2010 Copyright © 2010, 2net Limited Embedded Linux Quick Start Guide 1 In the beginning Overview ● Genesis of a Linux project ● The four elements ● Tool chain; boot loader; kernel; user space ● Element 1: Tool chain ● Element 2: Boot loader Embedded Linux Quick Start Guide 2 In the beginning “I've just had this great idea...” ● “…our next product will run Linux” ● This workshop will take a look at ● Board bring-up ● Development environment ● Deployment Embedded Linux Quick Start Guide 3 In the beginning The four elements Toolchain (air) Boot loader (earth) Kernel (fire) User space (water) Embedded Linux Quick Start Guide 4 In the beginning First element: the toolchain ● You can't do anything until you can produce code for your platform ● A tool chain consists of at least ● binutils: GNU assembler, linker, etc. ● gcc: GNU C compiler ● C library (libc): the interface to the operating system ● gdb: debugger Embedded Linux Quick Start Guide 5 In the beginning Types of toolchain ● Native: run compiler on target board ● If your target board is not fast enough or doesn't have enough memory or storage, use an emulator e.g. qemu ● Cross: compile on one machine, run on another ● Most common option Embedded Linux Quick Start Guide 6 In the beginning The C library ● Gcc is built along side the C library ● Hence, the C library is part of the tool chain ● Main options are ● GNU glibc – big but fully functional ● GNU eglibc – glibc but more configurable; embedded-friendly ● uClibc – small, lacking up-to-date threads library and other POSIX functions Embedded Linux Quick Start Guide 7 In the beginning Criteria for selecting a toolchain ● Good support for your processor ● e.g.
    [Show full text]
  • Embedded.Linux.Syste
    Embedded Linux system development Embedded Linux system development Free Electrons Gr´egory Cl´ement,Michael Opdenacker, Maxime Ripard, Thomas Petazzoni Embedded Linux Free Electrons Developers c Copyright 2004-2012, Free Electrons. Creative Commons BY-SA 3.0 license. Latest update: October 8, 2012. Document updates and sources: http://free-electrons.com/doc/training/embedded-linux Corrections, suggestions, contributions and translations are welcome! Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 1/528 Rights to copy c Copyright 2004-2012, Free Electrons License: Creative Commons Attribution - Share Alike 3.0 http://creativecommons.org/licenses/by-sa/3.0/legalcode You are free: I to copy, distribute, display, and perform the work I to make derivative works I to make commercial use of the work Under the following conditions: I Attribution. You must give the original author credit. I Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. I For any reuse or distribution, you must make clear to others the license terms of this work. I Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 2/528 Electronic copies of these documents I Electronic copies of your particular version of the materials are available on: http://free-electrons.com/doc/training/embedded- linux I Open the corresponding documents and use them throughout the course to find explanations given earlier by the instructor.
    [Show full text]