DOCSLIB.ORG

NASM — the Netwide Assembler Version 2.09.10

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
NASM — the Netwide Assembler Version 2.09.10 NASM — The Netwide Assembler version 2.09.10 -~~..~:#;L .-:#;L,.- .~:#:;.T -~~.~:;. .~:;. E8+U *T +U' *T# .97 *L E8+' *;T' *;, D97 `*L .97 '*L "T;E+:, D9 *L *L H7 I# T7 I# "*:. H7 I# I# U: :8 *#+ , :8 T, 79 U: :8 :8 ,#B. .IE, "T;E* .IE, J *+;#:T*" ,#B. .IE, .IE, © 1996−2011 The NASM Development Team — All Rights Reserved This document is redistributable under the license given in the file "LICENSE" distributed in the NASM archive. Contents Chapter 1: Introduction . .15 1.1 What Is NASM? . .15 1.1.1 Why Yet Another Assembler?. .15 1.1.2 License Conditions . .15 1.2 Contact Information . .16 1.3 Installation. .16 1.3.1 Installing NASM under MS−DOS or Windows . .16 1.3.2 Installing NASM under Unix . .17 Chapter 2: Running NASM . .18 2.1 NASM Command−Line Syntax . .18 2.1.1 The −o Option: Specifying the Output File Name . .18 2.1.2 The −f Option: Specifying the Output File Format . .19 2.1.3 The −l Option: Generating a Listing File . .19 2.1.4 The −M Option: Generate Makefile Dependencies . .19 2.1.5 The −MG Option: Generate Makefile Dependencies . .19 2.1.6 The −MF Option: Set Makefile Dependency File . .19 2.1.7 The −MD Option: Assemble and Generate Dependencies. .19 2.1.8 The −MT Option: Dependency Target Name. .20 2.1.9 The −MQ Option: Dependency Target Name (Quoted) . .20 2.1.10 The −MP Option: Emit phony targets. .20 2.1.11 The −F Option: Selecting a Debug Information Format . .20 2.1.12 The −g Option: Enabling Debug Information. .20 2.1.13 The −X Option: Selecting an Error Reporting Format. .20 2.1.14 The −Z Option: Send Errors to a File. .21 2.1.15 The −s Option: Send Errors to stdout ............................21 2.1.16 The −i Option: Include File Search Directories . .21 2.1.17 The −p Option: Pre−Include a File. .21 2.1.18 The −d Option: Pre−Define a Macro. .21 2.1.19 The −u Option: Undefine a Macro . .22 2.1.20 The −E Option: Preprocess Only. .22 3 2.1.21 The −a Option: Don’t Preprocess At All . .22 2.1.22 The −O Option: Specifying Multipass Optimization . .22 2.1.23 The −t Option: Enable TASM Compatibility Mode . .23 2.1.24 The −w and −W Options: Enable or Disable Assembly Warnings . .23 2.1.25 The −v Option: Display Version Info . .24 2.1.26 The −y Option: Display Available Debug Info Formats . .24 2.1.27 The −−prefix and −−postfix Options. .24 2.1.28 The NASMENV Environment Variable . .24 2.2 Quick Start for MASM Users . .25 2.2.1 NASM Is Case−Sensitive . .25 2.2.2 NASM Requires Square Brackets For Memory References . .25 2.2.3 NASM Doesn’t Store Variable Types . .25 2.2.4 NASM Doesn’t ASSUME ....................................26 2.2.5 NASM Doesn’t Support Memory Models . .26 2.2.6 Floating−Point Differences . .26 2.2.7 Other Differences . .26 Chapter 3: The NASM Language . .27 3.1 Layout of a NASM Source Line . .27 3.2 Pseudo−Instructions . .28 3.2.1 DB and Friends: Declaring Initialized Data . .28 3.2.2 RESB and Friends: Declaring Uninitialized Data . .28 3.2.3 INCBIN: Including External Binary Files . .28 3.2.4 EQU: Defining Constants . .29 3.2.5 TIMES: Repeating Instructions or Data . .29 3.3 Effective Addresses . .29 3.4 Constants . .30 3.4.1 Numeric Constants . .30 3.4.2 Character Strings . .31 3.4.3 Character Constants. .32 3.4.4 String Constants . .32 3.4.5 Unicode Strings. .32 3.4.6 Floating−Point Constants . .33 3.4.7 Packed BCD Constants . .34 3.5 Expressions . .34 3.5.1 |: Bitwise OR Operator. .34 4 3.5.2 ^: Bitwise XOR Operator . .34 3.5.3 &: Bitwise AND Operator . .34 3.5.4 << and >>: Bit Shift Operators . .34 3.5.5 + and −: Addition and Subtraction Operators . .34 3.5.6 *, /, //, % and %%: Multiplication and Division. .34 3.5.7 Unary Operators: +, −, ~, ! and SEG ..............................35 3.6 SEG and WRT ............................................35 3.7 STRICT: Inhibiting Optimization . .35 3.8 Critical Expressions . .36 3.9 Local Labels. .36 Chapter 4: The NASM Preprocessor . .38 4.1 Single−Line Macros . .38 4.1.1 The Normal Way: %define ..................................38 4.1.2 Resolving %define: %xdefine ...............................39 4.1.3 Macro Indirection: %[...] ..................................40 4.1.4 Concatenating Single Line Macro Tokens: %+..........................40 4.1.5 The Macro Name Itself: %? and %?? ..............................40 4.1.6 Undefining Single−Line Macros: %undef ...........................41 4.1.7 Preprocessor Variables: %assign ...............................41 4.1.8 Defining Strings: %defstr ..................................42 4.1.9 Defining Tokens: %deftok ..................................42 4.2 String Manipulation in Macros . .42 4.2.1 Concatenating Strings: %strcat ................................42 4.2.2 String Length: %strlen ....................................42 4.2.3 Extracting Substrings: %substr ................................43 4.3 Multi−Line Macros: %macro ....................................43 4.3.1 Overloading Multi−Line Macros . .44 4.3.2 Macro−Local Labels . .44 4.3.3 Greedy Macro Parameters. .45 4.3.4 Macro Parameters Range . .45 4.3.5 Default Macro Parameters . .46 4.3.6 %0: Macro Parameter Counter. .47 4.3.7 %00: Label Preceeding Macro . .47 4.3.8 %rotate: Rotating Macro Parameters . .47 4.3.9 Concatenating Macro Parameters . .48 5 4.3.10 Condition Codes as Macro Parameters . .49 4.3.11 Disabling Listing Expansion . .49 4.3.12 Undefining Multi−Line Macros: %unmacro..........................50 4.4 Conditional Assembly . .50 4.4.1 %ifdef: Testing Single−Line Macro Existence. .50 4.4.2 %ifmacro: Testing Multi−Line Macro Existence . .51 4.4.3 %ifctx: Testing the Context Stack. .51 4.4.4 %if: Testing Arbitrary Numeric Expressions . .51 4.4.5 %ifidn and %ifidni: Testing Exact Text Identity . .52 4.4.6 %ifid, %ifnum, %ifstr: Testing Token Types . ..
Load more

Recommended publications
  • Memory Layout and Access Chapter Four
    Memory Layout and Access Chapter Four Chapter One discussed the basic format for data in memory. Chapter Three covered how a computer system physically organizes that data. This chapter discusses how the 80x86 CPUs access data in memory. 4.0 Chapter Overview This chapter forms an important bridge between sections one and two (Machine Organization and Basic Assembly Language, respectively). From the point of view of machine organization, this chapter discusses memory addressing, memory organization, CPU addressing modes, and data representation in memory. From the assembly language programming point of view, this chapter discusses the 80x86 register sets, the 80x86 mem- ory addressing modes, and composite data types. This is a pivotal chapter. If you do not understand the material in this chapter, you will have difficulty understanding the chap- ters that follow. Therefore, you should study this chapter carefully before proceeding. This chapter begins by discussing the registers on the 80x86 processors. These proces- sors provide a set of general purpose registers, segment registers, and some special pur- pose registers. Certain members of the family provide additional registers, although typical application do not use them. After presenting the registers, this chapter describes memory organization and seg- mentation on the 80x86. Segmentation is a difficult concept to many beginning 80x86 assembly language programmers. Indeed, this text tends to avoid using segmented addressing throughout the introductory chapters. Nevertheless, segmentation is a power- ful concept that you must become comfortable with if you intend to write non-trivial 80x86 programs. 80x86 memory addressing modes are, perhaps, the most important topic in this chap- ter.
    [Show full text]
  • Advanced Practical Programming for Scientists
    Advanced practical Programming for Scientists Thorsten Koch Zuse Institute Berlin TU Berlin SS2017 The Zen of Python, by Tim Peters (part 1) ▶︎ Beautiful is better than ugly. ▶︎ Explicit is better than implicit. ▶︎ Simple is better than complex. ▶︎ Complex is better than complicated. ▶︎ Flat is better than nested. ▶︎ Sparse is better than dense. ▶︎ Readability counts. ▶︎ Special cases aren't special enough to break the rules. ▶︎ Although practicality beats purity. ▶︎ Errors should never pass silently. ▶︎ Unless explicitly silenced. ▶︎ In the face of ambiguity, refuse the temptation to guess. Advanced Programming 78 Ex1 again • Remember: store the data and compute the geometric mean on this stored data. • If it is not obvious how to compile your program, add a REAME file or a comment at the beginning • It should run as ex1 filenname • If you need to start something (python, python3, ...) provide an executable script named ex1 which calls your program, e.g. #/bin/bash python3 ex1.py $1 • Compare the number of valid values. If you have a lower number, you are missing something. If you have a higher number, send me the wrong line I am missing. File: ex1-100.dat with 100001235 lines Valid values Loc0: 50004466 with GeoMean: 36.781736 Valid values Loc1: 49994581 with GeoMean: 36.782583 Advanced Programming 79 Exercise 1: File Format (more detail) Each line should consists of • a sequence-number, • a location (1 or 2), and • a floating point value > 0. Empty lines are allowed. Comments can start a ”#”. Anything including and after “#” on a line should be ignored.
    [Show full text]
  • Virtual Memory Basics
    Operating Systems Virtual Memory Basics Peter Lipp, Daniel Gruss 2021-03-04 Table of contents 1. Address Translation First Idea: Base and Bound Segmentation Simple Paging Multi-level Paging 2. Address Translation on x86 processors Address Translation pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data enables number of advanced features programmers perspective: Address Translation OS in control of address translation pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data programmers perspective: Address Translation OS in control of address translation enables number of advanced features pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data Address Translation OS in control of address translation enables number of advanced features programmers perspective: transparent: it is not necessary to know how memory reference is converted to data Address Translation OS in control of address translation enables number of advanced features programmers perspective: pointers point to objects etc. Address Translation OS in control of address translation enables number of advanced features programmers perspective: pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data Address Translation - Idea / Overview Shared libraries, interprocess communication Multiple regions for dynamic allocation
    [Show full text]
  • Memory Management
    Memory management Virtual address space ● Each process in a multi-tasking OS runs in its own memory sandbox called the virtual address space. ● In 32-bit mode this is a 4GB block of memory addresses. ● These virtual addresses are mapped to physical memory by page tables, which are maintained by the operating system kernel and consulted by the processor. ● Each process has its own set of page tables. ● Once virtual addresses are enabled, they apply to all software running in the machine, including the kernel itself. ● Thus a portion of the virtual address space must be reserved to the kernel Kernel and user space ● Kernel might not use 1 GB much physical memory. ● It has that portion of address space available to map whatever physical memory it wishes. ● Kernel space is flagged in the page tables as exclusive to privileged code (ring 2 or lower), hence a page fault is triggered if user-mode programs try to touch it. ● In Linux, kernel space is constantly present and maps the same physical memory in all processes. ● Kernel code and data are always addressable, ready to handle interrupts or system calls at any time. ● By contrast, the mapping for the user-mode portion of the address space changes whenever a process switch happens Kernel virtual address space ● Kernel address space is the area above CONFIG_PAGE_OFFSET. ● For 32-bit, this is configurable at kernel build time. The kernel can be given a different amount of address space as desired. ● Two kinds of addresses in kernel virtual address space – Kernel logical address – Kernel virtual address Kernel logical address ● Allocated with kmalloc() ● Holds all the kernel data structures ● Can never be swapped out ● Virtual addresses are a fixed offset from their physical addresses.
    [Show full text]
  • Smashing the Stack in 2011 | My
    my 20% hacking, breaking things, malware, free time, etc. Home About Me Undergraduate Thesis (TRECC) Type text to search here... Home > Uncategorized > Smashing the Stack in 2011 Smashing the Stack in 2011 January 25, 2011 Recently, as part of Professor Brumley‘s Vulnerability, Defense Systems, and Malware Analysis class at Carnegie Mellon, I took another look at Aleph One (Elias Levy)’s Smashing the Stack for Fun and Profit article which had originally appeared in Phrack and on Bugtraq in November of 1996. Newcomers to exploit development are often still referred (and rightly so) to Aleph’s paper. Smashing the Stack was the first lucid tutorial on the topic of exploiting stack based buffer overflow vulnerabilities. Perhaps even more important was Smashing the Stack‘s ability to force the reader to think like an attacker. While the specifics mentioned in the paper apply only to stack based buffer overflows, the thought process that Aleph suggested to the reader is one that will yield success in any type of exploit development. (Un)fortunately for today’s would be exploit developer, much has changed since 1996, and unless Aleph’s tutorial is carried out with additional instructions or on a particularly old machine, some of the exercises presented in Smashing the Stack will no longer work. There are a number of reasons for this, some incidental, some intentional. I attempt to enumerate the intentional hurdles here and provide instruction for overcoming some of the challenges that fifteen years of exploit defense research has presented to the attacker. An effort is made to maintain the tutorial feel of Aleph’s article.
    [Show full text]
  • UNIVERSITY of CAMBRIDGE Computer Laboratory
    UNIVERSITY OF CAMBRIDGE Computer Laboratory Computer Science Tripos Part Ib Compiler Construction http://www.cl.cam.ac.uk/Teaching/1112/CompConstr/ David J Greaves [email protected] 2011–2012 (Lent Term) Notes and slides: thanks due to Prof Alan Mycroft and his predecessors. Summary The first part of this course covers the design of the various parts of a fairly basic compiler for a pretty minimal language. The second part of the course considers various language features and concepts common to many programming languages, together with an outline of the kind of run-time data structures and operations they require. The course is intended to study compilation of a range of languages and accordingly syntax for example constructs will be taken from various languages (with the intention that the particular choice of syntax is reasonably clear). The target language of a compiler is generally machine code for some processor; this course will only use instructions common (modulo spelling) to x86, ARM and MIPS—with MIPS being favoured because of its use in the Part Ib course “Computer Design”. In terms of programming languages in which parts of compilers themselves are to be written, the preference varies between pseudo-code (as per the ‘Data Structures and Algorithms’ course) and language features (essentially) common to C/C++/Java/ML. The following books contain material relevant to the course. Compilers—Principles, Techniques, and Tools A.V.Aho, R.Sethi and J.D.Ullman Addison-Wesley (1986) Ellis Horwood (1982) Compiler Design in Java/C/ML (3
    [Show full text]
  • Code Optimization & Linking
    Code optimization & linking Jinyang Li Slides adapted from Bryant and O’Hallaron What we’ve learnt so far • C program x86 instructions – Memory layout – control flows: sequential, jumps, call/ret • Buffer overflow – Hijack control flow by overwriting a return address – Execute code intended by the attacker Today’s lesson plan • Code optimization (done by the compiler) – common optimization techniques – what prevents optimization • C linker Optimizing Compilers • Goal: generate efficient, correct machine code – allocate registers, choose instructions, ... Generated code must have the same behavior as the original C program under all scenarios gcc’s optimization levels: -O1, -O2, -O3 Common optimization: code motion • Move computation outside loop if possible. void set_arr(long *arr, long n) { for (long i = 0; i < n; i++) arr[i] = n*n; done inside loop } testq %rsi, %rsi # Test n jle .L1 # If 0, goto done movq %rsi, %rdx leaq (%rdi, %rsi, 8), %rax # rax = &arr[n] void set_arr(long *arr, long n) # rdx = n*n imulq %rsi, %rdx { .L3: long t = n*n; movq %rdx, (%rdi) # (*p) =rdx for (long i = 0; i < n; i++) addq $8, %rdi # p++; arr[i] = t; cmpq %rax, %rdi # cmp &arr[n]) vs. p } jne .L3 # if !=, goto Loop .L3 Equivalent C code .L1: ret Common Optimization: use simpler instructions • Replace costly operation with simpler one – Shift, add instead of multiply or divide 16*x --> x << 4 – Recognize sequence of products long ni = 0; for (long i=0; i<n; i++ { for (long i = 0; i < n; i++) arr[i] = n*i; { } arr[i] = ni; ni += n; } assembly not shown this
    [Show full text]
  • Ucb Cs61c : Great Ideas in Computer Architecture
    inst.eecs.berkeley.edu/~cs61c Running a Program (Compiling, Assembling, Linking, Loading) UCB CS61C : GREAT IDEAS IN COMPUTER ARCHITECTURE Language Execution Continuum § An Interpreter is a program that executes other programs. Java bytecode Scheme Java C++ C Assembly Machine code Easy to program Difficult to program Inefficient to interpret Efficient to interpret § Language translation gives us another option. § In general, we interpret a high-level language when efficiency is not critical and translate to a lower-level language to up performance Interpretation vs Translation § How do we run a program written in a source language? ú Interpreter: Directly executes a program in the source language ú Translator: Converts a program from the source language to an equivalent program in another language § For example, consider a Python program foo.py! Interpretation § Python interpreter is just a program that reads a python program and performs the functions of that python program. Interpretation § Any good reason to interpret machine language in software? § MARS– useful for learning / debugging § Apple Macintosh conversion ú Switched from Motorola 680x0 instruction architecture to PowerPC. Similar issue with switch to x86. ú Could require all programs to be re-translated from high level language ú Instead, let executables contain old and/or new machine code, interpret old code in software if necessary (emulation) Interpretation vs. Translation? (1/2) § Generally easier to write interpreter § Interpreter closer to high-level, so can give better error messages (e.g., MARS, stk) ú Translator reaction: add extra information to help debugging (line numbers, names) § Interpreter slower (10x?), code smaller (2x?) § Interpreter provides instruction set independence: run on any machine Interpretation vs.
    [Show full text]
  • Download It to a Target System Where It Is Executed As the Local OS
    ENABLING USER-MODE PROCESSES IN THE TARGET OS FOR CSC 159 OPERATING SYSTEM PRAGMATICS A Project Presented to the faculty of the Department of Computer Science California State University, Sacramento Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in Computer Science by Michael Bradley Colson SPRING 2018 © 2018 Michael Bradley Colson ALL RIGHTS RESERVED ii ENABLING USER-MODE PROCESSES IN THE TARGET OS FOR CSC 159 OPERATING SYSTEM PRAGMATICS A Project by Michael Bradley Colson Approved by: __________________________________, Committee Chair Dr. Weide Chang __________________________________, Second Reader Dr. Yuan Cheng ____________________________ Date iii Student: Michael Bradley Colson I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the project. __________________________, Graduate Coordinator ___________________ Dr. Jinsong Ouyang Date Department of Computer Science iv Abstract of ENABLING USER-MODE PROCESSES IN THE TARGET OS FOR CSC 159 OPERATING SYSTEM PRAGMATICS by Michael Bradley Colson One of the main responsibilities of an Operating System (OS) is to ensure system stability and security. Most OSes utilize mechanisms built into the CPU hardware to prevent user-mode processes from altering the state of the system or accessing protected spaces and hardware I/O ports. A process should only read from or write to memory addresses in its address space. In order to accomplish the above, the CPU is typically designed to operate in two or more modes with different privilege levels. The OS typically runs in the mode with highest privilege level, which enables it to execute any instruction and gives it access to all the memory in the system.
    [Show full text]
  • A Compiler Error Messages Parser (Cp6812) Error Messages
    >B<82 Version 4.5 Software C Cross Compiler User’s Guide for Motorola MC68HC12 Copyright © COSMIC Software 1995, 2001 All Trademarks are the property of their respective owners Table of Contents Preface Organization of this Manual ....................................................... 1 Chapter 1 Introduction Introduction.................................................................................4 Document Conventions............................................................... 4 Typewriter font..................................................................... 4 Italics .................................................................................... 5 [ Brackets ] ........................................................................... 5 Conventions..........................................................................6 Command Line ..................................................................... 6 Flags ..................................................................................... 6 Compiler Architecture ................................................................ 8 Predefined Symbol...................................................................... 9 Linking........................................................................................ 9 Programming Support Utilities................................................... 9 Listings...................................................................................... 10 Optimizations...........................................................................
    [Show full text]
  • Hacking in C Memory Layout
    Hacking in C Memory layout Radboud University, Nijmegen, The Netherlands Spring 2018 A short recap ◮ The & operator gives us the address of data ◮ Inverse of & is the * operator (dereferencing) ◮ Aligning data to word (or larger) limits makes access more efficient ◮ Compilers may introduce padding to align data ◮ Arrays are passed by reference (decay to pointer to the first element) ◮ Can do “pointer arithmetic”, i.e., increase and decrease pointers ◮ x++ for type *x increases address by sizeof(type) ◮ Strings are null-terminated arrays of bytes ◮ Array access can be expressed as pointers: a[i] is the same as *(a+i) ◮ . is the same as i[a]! (try it out ;-)) ◮ Can use pointers ot inspect raw memory content This lecture: look at the systematics of what is stored where 2 Memory segments high addresses Command-line arguments The OS allocates memory for data and code of each running process Stack ◮ stack: for local variables (grows downwards) (including command-line arguments) unused space ◮ heap: For dynamic memory ◮ data segment: ◮ global and static uninitialized Heap variables (.bss) (grows upwards) ◮ global and static initialized variables (.data) .bss ◮ code segment: code (and .data possibly constants) code (.text) low addresses 3 /proc/<pid>/maps, ps, and size ◮ Find information about memory allocation for process with PID <pid> in /proc/<pid>/maps ◮ For example: 008e6000-00b11000 rw-p 00000000 00:00 0 [heap] 7ffd739cb000-7ffd739ec000 rw-p 00000000 00:00 0 [stack] ◮ Also information about dynamic libraries used by process ◮ List all processes
    [Show full text]
  • Courses Write an Article
    Memory Layout of C Programs - GeeksforGeeks https://www.geeksforgeeks.org/memory-layout-of-... Courses Write an Article G-Fact 1 | (Sizeof is an operator) G-Fact 2 G-Fact 3 G-Fact 4 G-Fact 5 G-Fact 6 G-Fact 7 G-Fact 8 How are variables scoped in C – Static or Dynamic? Scope rules in C How Linkers Resolve Global Symbols Defined at Multiple Places? 1 de 10 24/1/19 19:39 Memory Layout of C Programs - GeeksforGeeks https://www.geeksforgeeks.org/memory-layout-of-... Complicated declarations in C Redeclaration of global variable in C Data Types in C Use of bool in C Integer Promotions in C Comparison of a float with a value in C Storage Classes in C Static Variables in C How to deallocate memory without using free() in C? calloc() versus malloc() How does 2 de 10 24/1/19 19:39 Memory Layout of C Programs - GeeksforGeeks https://www.geeksforgeeks.org/memory-layout-of-... free() know the size of memory to be deallocated? Use of realloc() int (1 sign bit + 31 data bits) keyword in C Program error signals Why array index starts from zero ? TCP Server- Client implementation in C How to return multiple values from a function in C or C++? Dynamic Memory Allocation in C using malloc(), calloc(), free() and realloc() Commonly 3 de 10 24/1/19 19:39 Memory Layout of C Programs - GeeksforGeeks https://www.geeksforgeeks.org/memory-layout-of-... Asked C Programming Interview Questions | Set 3 Memory Layout of C Programs A typical memory representation of C program consists of following sections.
    [Show full text]