DOCSLIB.ORG

Who's Debugging the Debuggers? Exposing Debug Information Bugs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Who's Debugging the Debuggers? Exposing Debug Information Bugs Who’s Debugging the Debuggers? Exposing Debug Information Bugs in Optimized Binaries Giuseppe Antonio Di Luna Davide Italiano Luca Massarelli [email protected] [email protected] [email protected] Sapienza - University of Rome - DIAG Apple Sapienza - University of Rome - DIAG Roma, Italy Cupertino, California, USA Roma, Italy Sebastian Österlund Cristiano Giuffrida Leonardo Querzoni [email protected] [email protected] [email protected] Department of Computer Science Department of Computer Science Sapienza - University of Rome - DIAG Vrije Universiteit Amsterdam Vrije Universiteit Amsterdam Roma, Italy Amsterdam, Netherlands Amsterdam, Netherlands ABSTRACT KEYWORDS Despite the advancements in software testing, bugs still plague de- Debug Information, Optimized Binaries, Verification ployed software and result in crashes in production. When debugging issues —sometimes caused by “heisenbugs”— there is the need to ACM Reference Format: Giuseppe Antonio Di Luna, Davide Italiano, Luca Massarelli, Sebastian interpret core dumps and reproduce the issue offline on the same Österlund, Cristiano Giuffrida, and Leonardo Querzoni. 2021. Who’s De- binary deployed. This requires the entire toolchain (compiler, linker, bugging the Debuggers? Exposing Debug Information Bugs in Optimized debugger) to correctly generate and use debug information. Little Binaries. In Proceedings of the 26th ACM International Conference on Ar- attention has been devoted to checking that such information is cor- chitectural Support for Programming Languages and Operating Systems rectly preserved by modern toolchains’ optimization stages. This is (ASPLOS ’21), April 19–23, 2021, Virtual, USA. ACM, New York, NY, USA, particularly important as managing debug information in optimized 11 pages. https://doi.org/10.1145/3445814.3446695 production binaries is non-trivial, often leading to toolchain bugs that may hinder post-deployment debugging efforts. 1 INTRODUCTION In this paper, we present Debug2, a framework to find debug in- formation bugs in modern toolchains. Our framework feeds random Production binaries need to be heavily optimized to maximize met- source programs to the target toolchain and surgically compares the rics such as speed, size, and energy consumption [22]. For this pur- debugging behavior of their optimized/unoptimized binary variants. pose, modern compilers feature optimization stages where several Such differential analysis allows Debug2 to check invariants at each sophisticated transformation passes cooperate to produce the final debugging step and detect bugs from invariant violations. Our in- binary. Preserving debug information in this process is important for variants are based on the (in)consistency of common debug entities, several reasons. such as source lines, stack frames, and function arguments. We show First, correct debug information helps the interpretation of core that, while simple, this strategy yields powerful cross-toolchain and dumps collected in production (e.g., to provide line information in cross-language invariants, which can pinpoint several bugs in mod- stacks leading to a crash). More importantly, correct debug informa- ern toolchains. We have used Debug2 to find 23 bugs in the LLVM tion is crucial when reproducing and debugging production issues toolchain (clang/lldb), 8 bugs in the GNU toolchain (GCC/gdb), and offline on the same optimized binary. This is often necessary since 3 in the Rust toolchain (rustc/lldb)—with 14 bugs already fixed by compiler optimizations also alter the observability of unwanted be- the developers. haviors compared to the unoptimized case. In other words, common issues such as race conditions [12], memory errors [9], and other CCS CONCEPTS classes of “heisenbugs” [28] may not even be reproducible without a reliable debugging process for optimized binaries [10]. • Software and its engineering → Compilers; Formal software However, preserving debug information for optimized production verification; Correctness. binaries is a daunting task, with no obvious mapping between source and assembly statements [7, 10] and the potential to introduce bugs at each of the several layers of modern toolchains. As we will show, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed efforts to provide debug-friendly optimization levels (such as -Oд for profit or commercial advantage and that copies bear this notice and the full citation in modern compilers) fall short on providing a bug-free debugging on the first page. Copyrights for components of this work owned by others than ACM experience. must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a Yet, despite the challenges and relevance of this task, as well fee. Request permissions from [email protected]. as toolchain developers’ efforts to improve the debuggability of ASPLOS ’21, April 19–23, 2021, Virtual, USA optimized binaries, little attention has been devoted to scrutinizing © 2021 Association for Computing Machinery. ACM ISBN 978-1-4503-8317-2/21/04. $15.00 the full debug information lifecycle for bugs. Prior work largely https://doi.org/10.1145/3445814.3446695 focused on debugger testing [16, 25], with one recent exception 81 ASPLOS ’21, April 19–23, 2021, Virtual, USA Di Luna et al. focusing on the ability to retrieve correct variable values in optimized guidelines defining how to preserve debug information during op- binaries [18]. We stress that the entire toolchain (compiler, linker, timization passes. This forces developers to find the best course of debugger) must be free of debug information bugs to provide a action on an issue-by-issue basis, slowing down the rate at which reliable debugging experience. bugs can be fixed. Interestingly, our bug reports influenced an initial In this paper, we introduce Debug2, a framework to expose debug document published by LLVM developers on how to handle debug information bugs in production toolchains. The key idea is to feed information during optimization passes [14]. random source programs to a target toolchain and compare the We hope our work will serve as an inspiration to evolve the debugging behavior of their optimized/unoptimized binary variants standard UNIX debugging format (DWARF), which currently lacks to expose bugs. To achieve this, Debug2 first extracts debugging proper support to represent the effect of transformations on the traces of each binary by single-stepping its execution in the target source-to-binary mapping. Even simple optimizations (e.g., com- debugger. Next, Debug2 performs differential analysis of each pair of mon subexpression elimination) struggle to correctly preserve debug optimized/unoptimized traces to check for unexpected differences at information due to DWARF’s inability to map a single address to each step. To check for (un)expected behavioral differences, Debug2 multiple source locations. relies on trace invariants empirically based on the (in)consistency Contributions – We make the following contributions: of common debug elements, such as source lines, stack frames, and • 2 function arguments. Our trace invariants are explicitly designed to be Debug , a framework to scrutinize the debug information generic (i.e., toolchain- and programming language-agnostic) and, lifecycle for optimized binaries using trace invariants (§2). • while simple, can effectively pinpoint inconsistencies in the entire Four trace invariants to pinpoint debugging behavioral differ- ences in optimized/unoptimized binaries and expose toolchain debug information lifecycle. As we will show, these inconsistencies 2 can then be traced back to the underlying issue, exposing bugs in bugs. Debug ’s invariants are empirically derived and de- the entire toolchain; including all components of the compiler (from signed to expose bugs across different toolchains and pro- backend until the optimization stages) and the debugger. gramming languages (§3). • 2 Our analysis shows that after decades of development, mature An extensive experimental evaluation of Debug on the LLVM toolchains still suffer from a conspicuous amount of bugs that toolchain. We also present experiments on the GNU and 2 Rust toolchains to confirm the generality of our approach. Debug can automatically find. Surprisingly enough, many of these 2 bugs plague the optimization levels specifically created for a smooth Debug exposed bugs in all such toolchains (§5), specifi- cally 23 bugs in the LLVM toolchain (clang/lldb), 8 bugs in debug experience (i.e., -Oд). the GNU toolchain (GCC/gdb), and 3 in the Rust toolchain 2 A motivating example – Snippet 1 shows a bug Debug exposed in (rustc/lldb). The developers have already confirmed 22 of the LLVM toolchain when compiling with -Oд. these bugs, and 14 of these have been fixed. 2 Debug can expose this bug with a simple source line invariant: • Lessons learned from our interactions with the toolchain de- a line containing dead code for a given binary should be absent from velopers, egregious bugs found, and current shortcomings in 2 its debugging trace. However, while analyzing the trace, Debug the DWARF debugging format (§7 and §6). detects the debugger eventually pointing to the dead line 8 — which is never executed, as opposed to line 7 — and flags an invariant 2 THE DEBUG2 FRAMEWORK 2 violation. While Debug detects this issue by line stepping
Load more

Recommended publications
  • E2 Studio Integrated Development Environment User's Manual: Getting
    User’s Manual e2 studio Integrated Development Environment User’s Manual: Getting Started Guide Target Device RX, RL78, RH850 and RZ Family Rev.4.00 May 2016 www.renesas.com Notice 1. Descriptions of circuits, software and other related information in this document are provided only to illustrate the operation of semiconductor products and application examples. You are fully responsible for the incorporation of these circuits, software, and information in the design of your equipment. Renesas Electronics assumes no responsibility for any losses incurred by you or third parties arising from the use of these circuits, software, or information. 2. Renesas Electronics has used reasonable care in preparing the information included in this document, but Renesas Electronics does not warrant that such information is error free. Renesas Electronics assumes no liability whatsoever for any damages incurred by you resulting from errors in or omissions from the information included herein. 3. Renesas Electronics does not assume any liability for infringement of patents, copyrights, or other intellectual property rights of third parties by or arising from the use of Renesas Electronics products or technical information described in this document. No license, express, implied or otherwise, is granted hereby under any patents, copyrights or other intellectual property rights of Renesas Electronics or others. 4. You should not alter, modify, copy, or otherwise misappropriate any Renesas Electronics product, whether in whole or in part. Renesas Electronics assumes no responsibility for any losses incurred by you or third parties arising from such alteration, modification, copy or otherwise misappropriation of Renesas Electronics product. 5. Renesas Electronics products are classified according to the following two quality grades: “Standard” and “High Quality”.
    [Show full text]
  • SAS® Debugging 101 Kirk Paul Lafler, Software Intelligence Corporation, Spring Valley, California
    PharmaSUG 2017 - Paper TT03 SAS® Debugging 101 Kirk Paul Lafler, Software Intelligence Corporation, Spring Valley, California Abstract SAS® users are almost always surprised to discover their programs contain bugs. In fact, when asked users will emphatically stand by their programs and logic by saying they are bug free. But, the vast number of experiences along with the realities of writing code says otherwise. Bugs in software can appear anywhere; whether accidentally built into the software by developers, or introduced by programmers when writing code. No matter where the origins of bugs occur, the one thing that all SAS users know is that debugging SAS program errors and warnings can be a daunting, and humbling, task. This presentation explores the world of SAS bugs, providing essential information about the types of bugs, how bugs are created, the symptoms of bugs, and how to locate bugs. Attendees learn how to apply effective techniques to better understand, identify, and repair bugs and enable program code to work as intended. Introduction From the very beginning of computing history, program code, or the instructions used to tell a computer how and when to do something, has been plagued with errors, or bugs. Even if your own program code is determined to be error-free, there is a high probability that the operating system and/or software being used, such as the SAS software, have embedded program errors in them. As a result, program code should be written to assume the unexpected and, as much as possible, be able to handle unforeseen events using acceptable strategies and programming methodologies.
    [Show full text]
  • Agile Playbook V2.1—What’S New?
    AGILE P L AY B O OK TABLE OF CONTENTS INTRODUCTION ..........................................................................................................4 Who should use this playbook? ................................................................................6 How should you use this playbook? .........................................................................6 Agile Playbook v2.1—What’s new? ...........................................................................6 How and where can you contribute to this playbook?.............................................7 MEET YOUR GUIDES ...................................................................................................8 AN AGILE DELIVERY MODEL ....................................................................................10 GETTING STARTED.....................................................................................................12 THE PLAYS ...................................................................................................................14 Delivery ......................................................................................................................15 Play: Start with Scrum ...........................................................................................15 Play: Seeing success but need more fexibility? Move on to Scrumban ............17 Play: If you are ready to kick of the training wheels, try Kanban .......................18 Value ......................................................................................................................19
    [Show full text]
  • Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK
    1 From Start-ups to Scale-ups: Opportunities and Open Problems for Static and Dynamic Program Analysis Mark Harman∗, Peter O’Hearn∗ ∗Facebook London and University College London, UK Abstract—This paper1 describes some of the challenges and research questions that target the most productive intersection opportunities when deploying static and dynamic analysis at we have yet witnessed: that between exciting, intellectually scale, drawing on the authors’ experience with the Infer and challenging science, and real-world deployment impact. Sapienz Technologies at Facebook, each of which started life as a research-led start-up that was subsequently deployed at scale, Many industrialists have perhaps tended to regard it unlikely impacting billions of people worldwide. that much academic work will prove relevant to their most The paper identifies open problems that have yet to receive pressing industrial concerns. On the other hand, it is not significant attention from the scientific community, yet which uncommon for academic and scientific researchers to believe have potential for profound real world impact, formulating these that most of the problems faced by industrialists are either as research questions that, we believe, are ripe for exploration and that would make excellent topics for research projects. boring, tedious or scientifically uninteresting. This sociological phenomenon has led to a great deal of miscommunication between the academic and industrial sectors. I. INTRODUCTION We hope that we can make a small contribution by focusing on the intersection of challenging and interesting scientific How do we transition research on static and dynamic problems with pressing industrial deployment needs. Our aim analysis techniques from the testing and verification research is to move the debate beyond relatively unhelpful observations communities to industrial practice? Many have asked this we have typically encountered in, for example, conference question, and others related to it.
    [Show full text]
  • Toolchains Instructor: Prabal Dutta Date: October 2, 2012
    EECS 373: Design of Microprocessor-Based Systems Fall 2012 Lecture 3: Toolchains Instructor: Prabal Dutta Date: October 2, 2012 Note: Unless otherwise specified, these notes assume: (i) an ARM Cortex-M3 processor operating in little endian mode; (ii) the ARM EABI application binary interface; and (iii) the GNU GCC toolchain. Toolchains A complete software toolchain includes programs to convert source code into binary machine code, link together separately assembled/compiled code modules, disassemble the binaries, and convert their formats. Binary program file (.bin) Assembly Object Executable files (.s) files (.o) image file objcopy ld (linker) as objdump (assembler) Memory layout Disassembled Linker code (.lst) script (.ld) Figure 0.1: Assembler Toolchain. A typical GNU (GNU's Not Unix) assembler toolchain includes several programs that interact as shown in Figure 0.1 and perform the following functions: • as is the assembler and it converts human-readable assembly language programs into binary machine language code. It typically takes as input .s assembly files and outputs .o object files. • ld is the linker and it is used to combine multiple object files by resolving their external symbol references and relocating their data sections, and outputting a single executable file. It typically takes as input .o object files and .ld linker scripts and outputs .out executable files. • objcopy is a translation utility that copies and converts the contents of an object file from one format (e.g. .out) another (e.g. .bin). • objdump is a disassembler but it can also display various other information about object files. It is often used to disassemble binary files (e.g.
    [Show full text]
  • Linux from Scratch Version 6.2
    Linux From Scratch Version 6.2 Gerard Beekmans Linux From Scratch: Version 6.2 by Gerard Beekmans Copyright © 1999–2006 Gerard Beekmans Copyright (c) 1999–2006, Gerard Beekmans All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: • Redistributions in any form must retain the above copyright notice, this list of conditions and the following disclaimer • Neither the name of “Linux From Scratch” nor the names of its contributors may be used to endorse or promote products derived from this material without specific prior written permission • Any material derived from Linux From Scratch must contain a reference to the “Linux From Scratch” project THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Linux From Scratch - Version 6.2 Table of Contents Preface
    [Show full text]
  • Anatomy of Cross-Compilation Toolchains
    Embedded Linux Conference Europe 2016 Anatomy of cross-compilation toolchains Thomas Petazzoni free electrons [email protected] Artwork and Photography by Jason Freeny free electrons - Embedded Linux, kernel, drivers - Development, consulting, training and support. http://free-electrons.com 1/1 Thomas Petazzoni I CTO and Embedded Linux engineer at Free Electrons I Embedded Linux specialists. I Development, consulting and training. I http://free-electrons.com I Contributions I Kernel support for the Marvell Armada ARM SoCs from Marvell I Major contributor to Buildroot, an open-source, simple and fast embedded Linux build system I Living in Toulouse, south west of France Drawing from Frank Tizzoni, at Kernel Recipes 2016 free electrons - Embedded Linux, kernel, drivers - Development, consulting, training and support. http://free-electrons.com 2/1 Disclaimer I I am not a toolchain developer. Not pretending to know everything about toolchains. I Experience gained from building simple toolchains in the context of Buildroot I Purpose of the talk is to give an introduction, not in-depth information. I Focused on simple gcc-based toolchains, and for a number of examples, on ARM specific details. I Will not cover advanced use cases, such as LTO, GRAPHITE optimizations, etc. I Will not cover LLVM free electrons - Embedded Linux, kernel, drivers - Development, consulting, training and support. http://free-electrons.com 3/1 What is a cross-compiling toolchain? I A set of tools that allows to build source code into binary code for
    [Show full text]
  • GCC Toolchain Eclipse Setup Guide
    !"#$ % '#((#()*!+,-.#)/$01234 GCC Toolchain Eclipse Setup Guide WP0001 Version 5 September 23, 2020 Copyright © 2017-2020 JBLopen Inc. All rights reserved. No part of this document and any associated software may be reproduced, distributed or transmitted in any form or by any means without the prior written consent of JBLopen Inc. Disclaimer While JBLopen Inc. has made every attempt to ensure the accuracy of the information contained in this publication, JBLopen Inc. cannot warrant the accuracy of completeness of such information. JBLopen Inc. may change, add or remove any content in this publication at any time without notice. All the information contained in this publication as well as any associated material, including software, scripts, and examples are provided “as is”. JBLopen Inc. makes no express or implied warranty of any kind, including warranty of merchantability, noninfringement of intellectual property, or fitness for a particular purpose. In no event shall JBLopen Inc. be held liable for any damage resulting from the use or inability to use the information contained therein or any other associated material. Trademark JBLopen, the JBLopen logo, TREEspanTM and BASEplatformTM are trademarks of JBLopen Inc. All other trademarks are trademarks or registered trademarks of their respective owners. Contents 1 Overview 1 1.1 About Eclipse ............................................. 1 2 Eclipse Setup Guide (Windows) 2 2.1 MSYS2 Installation .......................................... 2 2.2 Eclipse Installation .......................................... 11 2.3 Toolchain Installation ......................................... 16 2.4 Environment Variable Setup ..................................... 17 2.4.1 PATH Environnement Variable Setup ........................... 17 3 Eclipse Setup Guide (Linux) 22 3.1 Eclipse Installation .......................................... 22 3.2 Toolchain Installation ......................................... 27 3.3 GNU Make Installation .......................................
    [Show full text]
  • The GNU Toolchain for ARM Targets HOWTO Wookey Chris Rutter Jeff Sutherland Paul Webb
    This chapter contains information on building a GNU toolchain for ARM targets. The GNU Toolchain for ARM targets HOWTO Wookey Chris Rutter Jeff Sutherland Paul Webb This document contains information on setting up a GNU toolchain for ARM targets. It details both some pre-compiled toolchains which you can install, and how to compile your own toolchain, as either a native or a cross-compiler. 1. Credits This document is based on the work of Chris Rutter (now, sadly, deceased) who’s ’Building the GNU toolchain for ARM targets’ document was gospel for some time. It eventually became out of date so Wookey (<[email protected]>) updated it and gave it a substantion rewrite, adding the pre-built toolchain info at the same time. Paul Webb (<[email protected]>) did the initial conversion to DocBook, Phil 1 The GNU Toolchain for ARM targets HOWTO Blundell (<[email protected]>) provided info on the current state of the art and comments on the draft. Jeff Sutherland (<[email protected]>) then fixed the bits that were still wrong, and now maintains the doc, along with Wookey. Thanx to all. As well as being on-line as a stand-alone HOWTO, this document is also available as a chapter of the book: A ’Guide to ARMLinux for Developers’ (http://www.aleph1.co.uk/armlinux/thebook.html) 2 This chapter contains information on building a GNU toolchain for ARM targets. 1. Toolchain overview The toolchain actually consists of a number of components. The main one is the compiler itself gcc, which can be native to the host or a cross-compiler.
    [Show full text]
  • Exploring the Construction of a Domain-Aware Toolchain for High-Performance Computing
    Exploring the Construction of a Domain-Aware Toolchain for High-Performance Computing Patrick McCormick, Christine Sweeney, Nick Moss, Dean Prichard, Samuel K. Gutierrez, Kei Davis, Jamaludin Mohd-Yusof Los Alamos National Laboratory Los Alamos, NM, USA Abstract—The push towards exascale computing has sparked in such a way that we can maintain the benefits of a general- a new set of explorations for providing new productive pro- purpose toolchain but also maintain a domain awareness within gramming environments. While many efforts are focusing on the entire toolchain. Scout is a strict superset of the C and the design and development of domain-specific languages (DSLs), C++ languages and extends the general-purpose toolchain few have addressed the need for providing a fully domain-aware to maintain this domain context throughout the compilation toolchain. Without such domain awareness critical features for process. This step is critical to enable support for a produc- achieving acceptance and adoption, such as debugger support, pose a long-term risk to the overall success of the DSL approach. tive and complete, domain-aware environment for developing, In this paper we explore the use of language extensions to debugging, and profiling applications. design and implement the Scout DSL and a supporting toolchain infrastructure. We highlight how language features and the A. Domain-Specific Languages software design methodologies used within the toolchain play a significant role in providing a suitable environment for DSL Although domain-specific languages have only recently development. become popular in the high-performance computing (HPC) research community, they have been a common part of com- Keywords—Domain Specific Language, Compiler, Debugging, puting for decades [2].
    [Show full text]
  • 5 Key Considerations Towards the Adoption of a Mainframe Inclusive Devops Strategy
    5 Key Considerations Towards the Adoption of a Mainframe Inclusive DevOps Strategy Key considaetrations towards the adoption of a mainframe inclusive devops strategy PLANNING FOR DEVOPS IN MAINFRAME ENVIRONMENTS – KEY CONSIDERATIONS – A mountain of information is available around the implementation and practice of DevOps, collectively encompassing people, processes and technology. This ranges significantly from the implementation of tool chains to discussions around DevOps principles, devoid of technology. While technology itself does not guarantee a successful DevOps implementation, the right tools and solutions can help companies better enable a DevOps culture. Unfortunately, the majority of conversations regarding DevOps center around distributed environments, neglecting the platform that still runs more than 70% of the business and transaction systems in the world; the mainframe. It is estimated that 5 billion lines of new COBOL code are added to live systems every year. Furthermore, 55% of enterprise apps and an estimated 80% of mobile transactions touch the mainframe at some point. Like their distributed brethren, mainframe applications benefit from DevOps practices, boosting speed and lowering risk. Instead of continuing to silo mainframe and distributed development, it behooves practitioners to increase communication and coordination between these environments to help address the pressure of delivering release cycles at an accelerated pace, while improving product and service quality. And some vendors are doing just that. Today, vendors are increasing their focus as it relates to the modernization of the mainframe, to not only better navigate the unavoidable generation shift in mainframe staffing, but to also better bridge mainframe and distributed DevOps cultures. DevOps is a significant topic incorporating community and culture, application and infrastructure development, operations and orchestration, and many more supporting concepts.
    [Show full text]
  • Migrating to Swift from Flash and Actionscript
    ©Radoslava Leseva Adams & Hristo Lesev Migrating to Swift from Flash and ActionScript Radoslava Leseva Adams Hristo Lesev ©Radoslava Leseva Adams & Hristo Lesev Contents at a Glance About the Authors ...................................................................................................xxi About the Technical Reviewer ..............................................................................xxiii Acknowledgments .................................................................................................xxv Preface ................................................................................................................xxvii ■ Part I: Tool Migration ..........................................................................1 ■ Chapter 1: Setting Up Your Environment ............................................................... 3 ■ Chapter 2: Hello, Xcode! ...................................................................................... 15 ■ Chapter 3: Introducing the Xcode Debugger ....................................................... 39 ■ Chapter 4: Additional Development Tools ............................................................51 ■ Part II: Workfl ow Migration .............................................................. 69 ■ Chapter 5: “Hello, Swift!”—A Tutorial for Building an iOS App ...........................71 ■ Chapter 6: Adding a More Complex UI ...............................................................105 ■ Chapter 7: Concurrency .....................................................................................171
    [Show full text]