DOCSLIB.ORG

Complete Spatial Safety for C and C++ Using CHERI Capabilities

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Complete Spatial Safety for C and C++ Using CHERI Capabilities UCAM-CL-TR-949 Technical Report ISSN 1476-2986 Number 949 Computer Laboratory Complete spatial safety for C and C++ using CHERI capabilities Alexander Richardson June 2020 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 https://www.cl.cam.ac.uk/ c 2020 Alexander Richardson This technical report is based on a dissertation submitted October 2019 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Emmanuel College. This work was supported by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (“CTSRD”) and HR0011-18-C-0016 (“ECATS”) as part of the DARPA CRASH and SSITH research programs. The views, opinions, and/or findings contained in this report are those of the author and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government. This work was supported in part by HP Enterprise, Arm Limited and Google, Inc. Approved for Public Release, Distribution Unlimited. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: https://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract Lack of memory safety in commonly used systems-level languages such as C and C++ results in a constant stream of new exploitable software vulnerabilities and exploit techniques. Many exploit mitigations have been proposed and deployed over the years, yet none address the root issue: lack of memory safety. Most C and C++ implementations assume a memory model based on a linear array of bytes rather than an object-centric view. Whilst more efficient on contemporary CPU architectures, linear addresses cannot encode the target object, thus permitting memory errors such as spatial safety violations (ignoring the bounds of an object). One promising mechanism to provide memory safety is CHERI (Capability Hardware Enhanced RISC Instructions), which extends existing processor architectures with capabilities that provide hardware-enforced checks for all accesses and can be used to prevent spatial memory violations. This dissertation prototypes and evaluates a pure-capability programming model (using CHERI capabilities for all pointers) to provide complete spatial memory protection for traditionally unsafe languages. As the first step towards memory safety, all language-visible pointers can beimple- mented as capabilities. I analyse the programmer-visible impact of this change and refine the pure-capability programming model to provide strong source-level compatibility with existing code. Second, to provide robust spatial safety, language-invisible pointers (mostly arising from program linkage) such as those used for functions calls and global variable accesses must also be protected. In doing so, I highlight trade-offs between performance and privilege minimization for implicit and programmer-visible pointers. Finally, I present CheriSH, a novel and highly compatible technique that protects against buffer overflows between fields of the same object, hereby ensuring that the CHERI spatial memory protection is complete. I find that the byte-granular spatial safety provided by CHERI pure-capability codeis not only stronger than most other approaches, but also incurs almost negligible perform- ance overheads in common cases (0.1% geometric mean) and a worst-case overhead of only 23.3% compared to the insecure MIPS baseline. Moreover, I show that the pure-capability programming model provides near-complete source-level compatibility with existing pro- grams. I evaluate this based on porting large widely used open-source applications such as PostgreSQL and WebKit with only minimal changes: fewer than 0.1% of source lines. I conclude that pure-capability CHERI C/C++ is an eminently viable programming environment offering strong memory protection, good source-level compatibility andlow performance overheads. Acknowledgements I would like to take this opportunity to thank the following people for their invaluable help and contribution to this project without whom this research would have not been possible: First of all, I would like to thank my supervisor, Robert Watson, for giving me the opportunity to work on the immensely interesting CHERI project. I cannot thank him enough for the guidance and help he has provided over the past years since I started my MPhil in 2014. I am very grateful for his encouragement and useful critiques of this research work as well as his willingness to answer all the questions I had. I would like to thank David Chisnall for teaching me about the internal workings of the CHERI compiler at the start of my PhD. I would also like to extend my thanks to Khilan Gudka for all his work on the tools that I relied on for my PhD (and for my MPhil before), in particular for making WebKit and libc++ run on CHERI. I would like to thank Nathaniel Filardo for his extremely helpful and detailed feedback on hundreds of pages of my dissertation draft as well as providing assistance with his LaTeX and TikZ skills. Thank you also for the many useful discussions around new CHERI ideas, some of which have made it into this dissertation. I would also like to thank the wider CHERI project members, including Simon Moore, Brooks Davis, Lawrence Esswood, John Baldwin, Alfredo Mazzinghi, Edward Napierała, Jessica Clarke, Alexandre Joannou and Jonathan Woodruff. The CHERI project is a truly collaborative effort that would not be possible without the specific skill-set brought by each individual member. I have learnt so much from every one of you. I would furthermore like to thank my examiners, Alan Mycroft and Howard Shrobe for their invaluable feedback and suggested corrections. I could not have undertaken this research without the funding provided by Hewlett-Packard Enterprise and DARPA. I would like to thank Hewlett-Packard Labs, and particularly Dejan Milojicic, for the internship in Palo Alto that sparked many further research ideas. I would like to thank my family for their constant support and for giving me the opportunity to study and do research at Cambridge. Thank you also for proofreading my entire dissertation (multiple times!). Finally, I would like to thank Claire for her patience and amazing support over the past four years. Thank you also for many hours proofreading of my thesis. I could not have done this without you! Contents 1 Introduction 11 1.1 Contributions . 13 1.2 Publications . 14 1.2.1 Publications directly contributing to this dissertation . 14 1.2.2 Other publications . 15 1.3 Work performed in collaboration with others . 16 1.4 Outline . 17 2 Background 19 2.1 Memory-corruption attacks . 19 2.1.1 Code-injection attacks . 19 2.1.2 Code-reuse attacks . 20 2.1.3 Data-only attacks . 21 2.1.4 Information leakage . 22 2.1.5 Multi-purpose mitigation techniques . 22 2.2 CHERI . 23 2.3 Linkage . 25 2.3.1 Relocation processing . 25 2.3.2 GOT and PLT . 26 3 Pure-capability CHERI C/C++ 29 3.1 The pure-capability programming model . 30 3.2 Pointer representation . 32 3.2.1 Pointer size . 32 3.2.2 Bounded pointers . 33 3.2.3 Alignment of capabilities . 34 3.2.4 Preserving tags when copying memory . 35 3.2.5 Pointer comparison . 37 3.2.6 Pointer permissions . 38 3.3 CHERI capability registers . 39 3.3.1 Function prototypes and calling conventions . 39 3.3.1.1 Unprototyped (K&R) functions . 39 3.3.1.2 Variadic argument handling . 39 3.3.2 Recommended approach . 40 3.4 CHERI capability precision . 41 3.4.1 Choosing the precision for CHERI-128 . 41 3.4.2 Out-of-bounds pointers . 41 3.4.3 Compatibility concerns due to precision . 43 3.4.4 ISA extensions related to precision . 43 3.4.5 Compiler changes due to reduced precision . 44 3.5 Conversions between capabilities and integers . 45 3.5.1 Conversions in hybrid CHERI C . 45 3.5.2 Integer-to-pointer casts in pure-capability C . 45 3.6 Offset and address interpretation of capabilities . 46 3.6.1 Bitwise operations on capabilities . 47 3.6.1.1 Changing and checking pointer alignment . 47 3.6.1.2 Storing additional data in pointers . 48 3.6.1.3 Computing hash values . 49 3.6.2 Implicit conversions between uintptr_t and integers . 49 3.6.3 Other compatibility concerns . 50 3.6.4 Introducing an address interpretation of capabilities . 51 3.7 Adding C++ support . 51 3.8 Optimizations for pure-capability code . 52 3.8.1 ISA changes . 52 3.8.2 Optimizing bounds on stack variables . 54 3.9 Unsupported C/C++ programming idioms . 55 3.9.1 XOR-linked lists . 56 3.9.2 Offsets relative to the current structure . 56 3.9.3 Updating pointers after realloc() .................. 56 3.9.4 Byte-wise copying of data . 57 3.9.5 Using high pointer bits . 57 3.9.6 Yet to be discovered issues . 57 3.10 Future changes to pure-capability C/C++ .................. 57 3.10.1 True offset semantics . 58 3.10.2 Explicit provenance source for uintptr_t .............. 58 3.10.3 Strict compilation mode (CHERI sanitizer) . 58 3.11 Summary . 58 4 Pure-capability CHERI linkage 61 4.1 Introduction . 62 4.2 CHERI pure-capability linkage models . 63 4.2.1 MIPS n64 baseline . 65 4.2.2 Original CHERI static linkage model . 66 4.2.3 Function-descriptor prototype . 67 4.2.4 PC-relative ABI . 68 4.2.5 PLT ABI . 70 4.2.6 Overview . 72 4.3 PLT stubs and lazy binding . 72 4.3.1 Dynamic allocation of PLT stubs . 72 4.3.2 Run-time configurable policy . 73 4.3.3 Lazy binding .
Load more

Recommended publications
  • Lecture 04 Linear Structures Sort
    Algorithmics (6EAP) MTAT.03.238 Linear structures, sorting, searching, etc Jaak Vilo 2018 Fall Jaak Vilo 1 Big-Oh notation classes Class Informal Intuition Analogy f(n) ∈ ο ( g(n) ) f is dominated by g Strictly below < f(n) ∈ O( g(n) ) Bounded from above Upper bound ≤ f(n) ∈ Θ( g(n) ) Bounded from “equal to” = above and below f(n) ∈ Ω( g(n) ) Bounded from below Lower bound ≥ f(n) ∈ ω( g(n) ) f dominates g Strictly above > Conclusions • Algorithm complexity deals with the behavior in the long-term – worst case -- typical – average case -- quite hard – best case -- bogus, cheating • In practice, long-term sometimes not necessary – E.g. for sorting 20 elements, you dont need fancy algorithms… Linear, sequential, ordered, list … Memory, disk, tape etc – is an ordered sequentially addressed media. Physical ordered list ~ array • Memory /address/ – Garbage collection • Files (character/byte list/lines in text file,…) • Disk – Disk fragmentation Linear data structures: Arrays • Array • Hashed array tree • Bidirectional map • Heightmap • Bit array • Lookup table • Bit field • Matrix • Bitboard • Parallel array • Bitmap • Sorted array • Circular buffer • Sparse array • Control table • Sparse matrix • Image • Iliffe vector • Dynamic array • Variable-length array • Gap buffer Linear data structures: Lists • Doubly linked list • Array list • Xor linked list • Linked list • Zipper • Self-organizing list • Doubly connected edge • Skip list list • Unrolled linked list • Difference list • VList Lists: Array 0 1 size MAX_SIZE-1 3 6 7 5 2 L = int[MAX_SIZE]
    [Show full text]
  • Javascript • Data Types • Operators • Control Statement • Popup Boxes • Functions • Arrays
    LECTURE-2 Javascript • Data types • Operators • Control Statement • Popup Boxes • Functions • Arrays CS3101: Programming Languages: Javascript Ramana Isukapalli 1 JAVASCRIPT – OVERVIEW • This course is concerned with client side JS • Executes on client (browser) • Scripting – NOT compile/link. • Helps provide dynamic nature of HTML pages. • Included as part of HTML pages as • Regular code (viewable by user) • A file present in some location. • NOTE: Javascript is NOT the same as JAVA CS3101: Programming Languages: Javascript Ramana Isukapalli 2 A SIMPLE JAVASCRIPT PROGRAM <html> <head> <title> A simple Javascript program </title> </head> <body> <! --The code below in “script” is Javascript code. --> <script> document.write (“A Simple Javascript program”); </script> </body> </html> CS3101: Programming Languages: Javascript Ramana Isukapalli 3 JAVASCRIPT CODE • Javascript code in HTML • Javascript code can be placed in • <head> part of HTML file • Code is NOT executed unless called in <body> part of the file. • <body> part of HTML file – executed along with the rest of body part. • Outside HTML file, location is specified. • Executed when called in <body> CS3101: Programming Languages: Javascript Ramana Isukapalli 4 WAYS OF DEFINING JAVASCRIPT CODE. First: Second: <head> <head> <script type=“text/javascript”> … function foo(…) // defined here </head> <body> </script> <script> </head> function foo(…) // defined here { <body> .. } <script type=“text/javascript”> foo( ) // Called here foo(…) // called here </script> </script> </body> </body>
    [Show full text]
  • Truffle/C Interpreter
    JOHANNES KEPLER UNIVERSITAT¨ LINZ JKU Faculty of Engineering and Natural Sciences Truffle/C Interpreter Master’s Thesis submitted in partial fulfillment of the requirements for the academic degree Diplom-Ingenieur in the Master’s Program Computer Science Submitted by Manuel Rigger, BSc. At the Institut f¨urSystemsoftware Advisor o.Univ.-Prof. Dipl.-Ing. Dr.Dr.h.c. Hanspeter M¨ossenb¨ock Co-advisor Dipl.-Ing. Lukas Stadler Dipl.-Ing. Dr. Thomas W¨urthinger Xiamen, April 2014 Contents I Contents 1 Introduction 3 1.1 Motivation . .3 1.2 Goals and Scope . .4 1.3 From C to Java . .4 1.4 Structure of the Thesis . .6 2 State of the Art 9 2.1 Graal . .9 2.2 Truffle . 10 2.2.1 Rewriting and Specialization . 10 2.2.2 Truffle DSL . 11 2.2.3 Control Flow . 12 2.2.4 Profiling and Inlining . 12 2.2.5 Partial Evaluation and Compilation . 12 2.3 Clang . 13 3 Architecture 14 3.1 From Clang to Java . 15 3.2 Node Construction . 16 3.3 Runtime . 16 4 The Truffle/C File 17 4.1 Truffle/C File Format Goals . 17 4.2 Truffle/C File Format 1 . 19 4.2.1 Constant Pool . 19 4.2.2 Function Table . 20 4.2.3 Functions and Attributes . 20 4.3 Truffle/C File Considerations and Comparison . 21 4.3.1 Java Class File and Truffle/C File . 21 4.3.2 ELF and Truffle/C File . 22 4.4 Clang Modification Truffle/C File . 23 Contents II 5 Truffle/C Data Types 25 5.1 Data Type Hierarchy: Boxing, Upcasts and Downcasts .
    [Show full text]
  • Optimizing Systems for Byte-Addressable NVM by Reducing Bit Flipping
    Optimizing Systems for Byte-Addressable NVM by Reducing Bit Flipping Daniel Bittman Peter Alvaro Darrell D. E. Long Ethan L. Miller FAST ‘19 2019-02-26 1 Byte-addressable Non-volatile Memory BNVM is coming, and with it, new optimization targets CRSS Confidential 2 Byte-addressable Non-volatile Memory 0 1 0 1 0 0 0 1 It’s not just writes... ...it’s the bits flipped by those writes 0 1 1 0 0 1 0 1 CRSS Confidential 3 BNVM power usage 4 Can we take advantage of this? Software vs. hardware? 5 Can we take advantage of this? Software vs. hardware? How hard is it to reason about bit flips? 6 Can we take advantage of this? Software vs. hardware? How hard is it to reason about bit flips? How do we design data structures to reduce bit flips? 7 8 Reducing Bit ● Flips in Software ● ● 9 XOR linked lists Traditional doubly linked list value value value next next next prev prev prev XOR linked list value value value xptr xptr xptr xptr = next ⊕ prev 10 Pointers! Some actual pointers A = 0x000055b7bda8f260 B = 0x000055b7bda8f6a0 A ⊕ B = 0x4C0 = 0b10011000000 11 Using XOR in hash tables key value xnext ... key key value value xnext xnext ... key value xnext 12 Using XOR in hash tables key value xnext D key key value value 00000 0 xxxxx 1 Both indicate “entry is empty” 13 From XOR linked lists to Red Black Trees L P R Standard 3-pointer red-black tree design 14 From XOR linked lists to Red Black Trees ⊕ RX = R P L P R LX RX ⊕ LX = L P Now 2-pointer, and XOR pointers 15 Evaluation ● ● 16 Experimental framework , at the memory controller Test different data
    [Show full text]
  • Contents of Lecture 4: Declarations
    Contents of Lecture 4: Declarations Implicint int Storage class specifiers Type specifiers Enumeration specifiers Type qualifiers Jonas Skeppstedt ([email protected]) Lecture 4 2014 1 / 39 Now obsolete: implicit int Sometimes you can see code such as: main() // invalid { } or even: #include <stdio.h> count; // invalid float x; In earlier versions of C one could skip the type, which then became int, and is called implicit int. Calling a function before its declaration also set its return type to int. It’s invalid C so don’t use it — but compilers often allow it... Jonas Skeppstedt ([email protected]) Lecture 4 2014 2 / 39 Storage class specifiers Last lecture we discussed the different kinds of storage durations. Now we will see how to specify some of them explicitly. Dynamic (important) and temporary (less important) storage duration are not specified by the programmer using any particular syntax but defined by the standard. The storage class specifiers are: typedef extern static _Thread_local auto register Of these typedef does not refer to any kind of storage duration — instead it introduces another name of a type and not a new type: typedef int num_t; int* p; num_t* q; p = q; // valid since p and q have the same type. Jonas Skeppstedt ([email protected]) Lecture 4 2014 3 / 39 Storage class specifiers: static at file scope static int count; /∗ initialized to zero. ∗/ static void init(void) { /∗ Do some initializations ... ∗/ } Used to make an identifier invisible outside the source file With static at file scope, there is no risk of name conflicts with other files.
    [Show full text]
  • Typescript-Handbook.Pdf
    This copy of the TypeScript handbook was created on Monday, September 27, 2021 against commit 519269 with TypeScript 4.4. Table of Contents The TypeScript Handbook Your first step to learn TypeScript The Basics Step one in learning TypeScript: The basic types. Everyday Types The language primitives. Understand how TypeScript uses JavaScript knowledge Narrowing to reduce the amount of type syntax in your projects. More on Functions Learn about how Functions work in TypeScript. How TypeScript describes the shapes of JavaScript Object Types objects. An overview of the ways in which you can create more Creating Types from Types types from existing types. Generics Types which take parameters Keyof Type Operator Using the keyof operator in type contexts. Typeof Type Operator Using the typeof operator in type contexts. Indexed Access Types Using Type['a'] syntax to access a subset of a type. Create types which act like if statements in the type Conditional Types system. Mapped Types Generating types by re-using an existing type. Generating mapping types which change properties via Template Literal Types template literal strings. Classes How classes work in TypeScript How JavaScript handles communicating across file Modules boundaries. The TypeScript Handbook About this Handbook Over 20 years after its introduction to the programming community, JavaScript is now one of the most widespread cross-platform languages ever created. Starting as a small scripting language for adding trivial interactivity to webpages, JavaScript has grown to be a language of choice for both frontend and backend applications of every size. While the size, scope, and complexity of programs written in JavaScript has grown exponentially, the ability of the JavaScript language to express the relationships between different units of code has not.
    [Show full text]
  • ACCU 2015 “New” Features in C
    "New" Features in C ACCU 2015 “New” Features in C Dan Saks Saks & Associates www.dansaks.com 1 Abstract The first international standard for the C programming language was C90. Since then, two newer standards have been published, C99 and C11. C99 introduced a significant number of new features. C11 introduced a few more, some of which have been available in compilers for some time. Curiously, many of these added features don’t seem to have caught on. Many C programmers still program in C90. This session explains many of these “new” features, including declarations in for-statements, typedef redefinitions, inline functions, complex arithmetic, extended integer types, variable- length arrays, flexible array members, compound literals, designated initializers, restricted pointers, type-qualified array parameters, anonymous structures and unions, alignment support, non-returning functions, and static assertions. 2 Copyright © 2015 by Daniel Saks 1 "New" Features in C About Dan Saks Dan Saks is the president of Saks & Associates, which offers training and consulting in C and C++ and their use in developing embedded systems. Dan has written columns for numerous print publications including The C/C++ Users Journal , The C++ Report , Software Development , and Embedded Systems Design . He currently writes the online “Programming Pointers” column for embedded.com . With Thomas Plum, he wrote C++ Programming Guidelines , which won a 1992 Computer Language Magazine Productivity Award . He has also been a Microsoft MVP. Dan has taught thousands of programmers around the world. He has presented at conferences such as Software Development and Embedded Systems , and served on the advisory boards for those conferences.
    [Show full text]
  • XL C/C++: Language Reference About This Document
    IBM XL C/C++ for Linux, V16.1.1 IBM Language Reference Version 16.1.1 SC27-8045-01 IBM XL C/C++ for Linux, V16.1.1 IBM Language Reference Version 16.1.1 SC27-8045-01 Note Before using this information and the product it supports, read the information in “Notices” on page 63. First edition This edition applies to IBM XL C/C++ for Linux, V16.1.1 (Program 5765-J13, 5725-C73) and to all subsequent releases and modifications until otherwise indicated in new editions. Make sure you are using the correct edition for the level of the product. © Copyright IBM Corporation 1998, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document ......... v Chapter 4. IBM extension features ... 11 Who should read this document........ v IBM extension features for both C and C++.... 11 How to use this document.......... v General IBM extensions ......... 11 How this document is organized ....... v Extensions for GNU C compatibility ..... 15 Conventions .............. v Extensions for vector processing support ... 47 Related information ........... viii IBM extension features for C only ....... 56 Available help information ........ ix Extensions for GNU C compatibility ..... 56 Standards and specifications ........ x Extensions for vector processing support ... 58 Technical support ............ xi IBM extension features for C++ only ...... 59 How to send your comments ........ xi Extensions for C99 compatibility ...... 59 Extensions for C11 compatibility ...... 59 Chapter 1. Standards and specifications 1 Extensions for GNU C++ compatibility .... 60 Chapter 2. Language levels and Notices .............. 63 language extensions ......... 3 Trademarks .............
    [Show full text]
  • Qa·C Release Notes
    RELEASE NOTES QA·C 9.4.1 February, 2018 Documentation Version 1.3 IMPORTANT NOTICE DISCLAIMER OF WARRANTY This document should only be used in conjunction with QA·C 9.4.1. Programming Research Ltd. have taken due care in preparing this document which it has endeavored to ensure is accurate at the time of printing. However, no liability can be accepted for errors or omissions; nor should the document be considered as an expressed or implied warranty of accuracy or completeness, fitness for a particular purpose, or that the products described perform as specified within. COPYRIGHT NOTICE All rights reserved. No part of this document may be reproduced, stored in a retrieval system of any nature, or transmitted in any form or by any means, including photocopying and recording, without the prior written permission of Programming Research Ltd., the copyright owner. If any unauthorized acts are carried out in relation to this copyrighted work, a civil claim for damages may be made and/or a criminal prosecution may result. Copyright ©Programming Research Ltd. 2018 TRADEMARKS PRQA, the PRQA logo, QA·C, QA·C++ and High Integrity C++ (HIC++) are trademarks of Programming Research Ltd. "MISRA", "MISRA C" and "MISRA C++" are registered trademarks of HORIBA MIRA Lim- ited, held on behalf of the MISRA Consortium. "AUTOSAR" is a registered trademark of AUTOSAR GBR, held on behalf of the AU- TOSAR Development Partnership. Yices is a registered trademark of SRI International. Windows is a registered trademark of Microsoft Corporation. RELEASE NOTES : QA·C 9.4.1 Page i Programming Research Ltd.
    [Show full text]
  • Section “Common Predefined Macros” in the C Preprocessor
    The C Preprocessor For gcc version 12.0.0 (pre-release) (GCC) Richard M. Stallman, Zachary Weinberg Copyright c 1987-2021 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation. A copy of the license is included in the section entitled \GNU Free Documentation License". This manual contains no Invariant Sections. The Front-Cover Texts are (a) (see below), and the Back-Cover Texts are (b) (see below). (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Table of Contents 1 Overview :::::::::::::::::::::::::::::::::::::::: 1 1.1 Character sets:::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Initial processing ::::::::::::::::::::::::::::::::::::::::::::::: 2 1.3 Tokenization ::::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.4 The preprocessing language :::::::::::::::::::::::::::::::::::: 6 2 Header Files::::::::::::::::::::::::::::::::::::: 7 2.1 Include Syntax ::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Include Operation :::::::::::::::::::::::::::::::::::::::::::::: 8 2.3 Search Path :::::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.4 Once-Only Headers::::::::::::::::::::::::::::::::::::::::::::: 9 2.5 Alternatives to Wrapper #ifndef ::::::::::::::::::::::::::::::
    [Show full text]
  • Getting Started with Nxopen
    Getting Started with NX Open Update January 2019 © 2019 Siemens Product Lifecycle Management Software Inc. All rights reserved. Unrestricted Table of Contents Chapter 1: Introduction ....................................... 1 Chapter 8: Simple Solids and Sheets ............... 64 What Is NX Open .............................................................................................. 1 Creating Primitive Solids ........................................................................... 64 Purpose of this Guide ..................................................................................... 1 Sections ............................................................................................................. 65 Where To Go From Here ............................................................................... 1 Extruded Bodies ............................................................................................ 67 Other Documentation .................................................................................... 2 Revolved Bodies ............................................................................................ 68 Example Code .................................................................................................... 3 Chapter 9: Object Properties & Methods .......... 69 Chapter 2: Using the NX Journal Editor ............. 4 NXObject Properties .................................................................................... 69 System Requirement — The .NET Framework ..................................
    [Show full text]
  • Optimizing Subroutines in Assembly Language an Optimization Guide for X86 Platforms
    2. Optimizing subroutines in assembly language An optimization guide for x86 platforms By Agner Fog. Copenhagen University College of Engineering. Copyright © 1996 - 2012. Last updated 2012-02-29. Contents 1 Introduction ....................................................................................................................... 4 1.1 Reasons for using assembly code .............................................................................. 5 1.2 Reasons for not using assembly code ........................................................................ 5 1.3 Microprocessors covered by this manual .................................................................... 6 1.4 Operating systems covered by this manual................................................................. 7 2 Before you start................................................................................................................. 7 2.1 Things to decide before you start programming .......................................................... 7 2.2 Make a test strategy.................................................................................................... 9 2.3 Common coding pitfalls............................................................................................. 10 3 The basics of assembly coding........................................................................................ 12 3.1 Assemblers available ................................................................................................ 12 3.2 Register set
    [Show full text]