DOCSLIB.ORG

[ Team Lib ] Mod Perl Embeds the Popular Programming Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
[ Team Lib ] Mod Perl Embeds the Popular Programming Language [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata Practical mod_perl By Stas Bekman, Eric Cholet Publisher: O'Reilly Date : May 2003 Published ISBN: 0-596-00227-0 Pages: 924 Mod_perl embeds the popular programming language Perl in the Apache web server, giving rise to a fast and powerful web programming environment. Written for Perl web developers and web administrators, Practical mod_perl is an extensive guide to the nuts and bolts of the powerful and popular combination of Apache and mod_perl. From writing and debugging scripts to keeping your server running without failures, the techniques in this book will help you squeeze every ounce of power out of your server. True to its title, this is the practical guide to mod_perl. [ Team LiB ] [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata Practical mod_perl By Stas Bekman, Eric Cholet Publisher: O'Reilly Date : May 2003 Published ISBN: 0-596-00227-0 Pages: 924 Copyright Preface What You Need to Know Who This Book Is For How This Book Is Organized Reference Sections Filesystem Conventions Apache and Perl Versions Typographic Conventions Command Interpreter Program (Shell) Conventions Installing Perl Modules How to Contact Us Acknowledgments Part I: mod_perl Administration Chapter 1. Introducing CGI and mod_perl Section 1.1. A Brief History of CGI Section 1.2. The Apache 1.3 Server Model Section 1.3. The Development of mod_perl 1.0 Section 1.4. Apache 1.3 Request Processing Phases Section 1.5. References Chapter 2. Getting Started Fast Section 2.1. Installing mod_perl 1.0 in Three Steps Section 2.2. Installing mod_perl on Unix Platforms Section 2.3. Configuring and Starting the mod_perl Server Section 2.4. Installing mod_perl for Windows Section 2.5. Preparing the Scripts Directory Section 2.6. A Sample Apache::Registry Script Section 2.7. A Simple mod_perl Content Handler Section 2.8. Is This All We Need to Know About mod_perl? Section 2.9. References Chapter 3. Installing mod_perl Section 3.1. Configuring the Source Section 3.2. Building mod_perl (make) Section 3.3. Testing the Server (make test) Section 3.4. Installation (make install) Section 3.5. Installation Scenarios for Standalone mod_perl Section 3.6. Building mod_perl with Other Components Section 3.7. Installing mod_perl with the CPAN.pm Interactive Shell Section 3.8. Installing mod_perl on Multiple Machines Section 3.9. Installation into a Nonstandard Directory Section 3.10. How Can I Tell if mod_perl Is Running? Section 3.11. General Notes Section 3.12. References Chapter 4. mod_perl Configuration Section 4.1. Apache Configuration Section 4.2. mod_perl Configuration Section 4.3. The Startup File Section 4.4. Apache Configuration in Perl Section 4.5. Validating the Configuration Syntax Section 4.6. The Scope of mod_perl Configuration Directives Section 4.7. Apache Restarts Twice Section 4.8. Enabling Remote Server Configuration Reports Section 4.9. Tips and Tricks Section 4.10. Configuration Security Concerns Section 4.11. General Pitfalls Section 4.12. References Chapter 5. Web Server Control, Monitoring, Upgrade, and Maintenance Section 5.1. Starting the Server in Multi-Process Mode Section 5.2. Starting the Server in Single-Process Mode Section 5.3. Using kill to Control Processes Section 5.4. Using apachectl to Control the Server Section 5.5. Validating Server Configuration Section 5.6. Setuid root Startup Scripts Section 5.7. Preparing for Machine Reboot Section 5.8. Upgrading a Live Server Section 5.9. Three-Tier Server Scheme: Development, Staging, and Production Section 5.10. Web Server Monitoring Section 5.11. Server Maintenance Chores Section 5.12. References Chapter 6. Coding with mod_perl in Mind Section 6.1. Before You Start to Code Section 6.2. Exposing Apache::Registry Secrets Section 6.3. Namespace Issues Section 6.4. Perl Specifics in the mod_perl Environment Section 6.5. CHECK and INIT Blocks Section 6.6. Apache::Registry Specifics Section 6.7. Transition from mod_cgi Scripts to Apache Handlers Section 6.8. Loading and Reloading Modules Section 6.9. Handling the "User Pressed Stop Button" Case Section 6.10. Handling Server Timeout Cases and Working with $SIG{ALRM} Section 6.11. Generating Correct HTTP Headers Section 6.12. Method Handlers: The Browse and See, Browse and View Example Section 6.13. References Part II: mod_perl Performance Chapter 7. Identifying Your Performance Problems Section 7.1. Looking at the Big Picture Section 7.2. Asking the Right Questions Section 7.3. References Chapter 8. Choosing a Platform for the Best Performance Section 8.1. Choosing the Right Operating System Section 8.2. Choosing the Right Hardware Section 8.3. References Chapter 9. Essential Tools for Performance Tuning Section 9.1. Server Benchmarking Section 9.2. Perl Code Benchmarking Section 9.3. Process Memory Measurements Section 9.4. Apache::Status and Measuring Code Memory Usage Section 9.5. Code Profiling Techniques Section 9.6. References Chapter 10. Improving Performance with Shared Memory and Proper Forking Section 10.1. Sharing Memory Section 10.2. Forking and Executing Subprocessesfrom mod_perl Section 10.3. References Chapter 11. Tuning Performance by Tweaking Apache's Configuration Section 11.1. Setting the MaxClients Directive Section 11.2. Setting the MaxRequestsPerChild Directive Section 11.3. Setting MinSpareServers, MaxSpareServers, and StartServers Section 11.4. KeepAlive Section 11.5. PerlSetupEnv Section 11.6. Reducing the Number of stat( ) Calls Made by Apache Section 11.7. Symbolic Links Lookup Section 11.8. Disabling DNS Resolution Section 11.9. Response Compressing Section 11.10. References Chapter 12. Server Setup Strategies Section 12.1. mod_perl Deployment Overview Section 12.2. Standalone mod_perl-Enabled Apache Server Section 12.3. One Plain and One mod_perl-Enabled Apache Server Section 12.4. One Light Non-Apache and One mod_perl-Enabled Apache Server Section 12.5. Adding a Proxy Server in httpd Accelerator Mode Section 12.6. The Squid Server and mod_perl Section 12.7. Apache's mod_proxy Module Section 12.8. mod_rewrite Examples Section 12.9. Getting the Remote Server IP in the Backend Server in the Proxy Setup Section 12.10. Frontend/Backend Proxying with Virtual Hosts Section 12.11. HTTP Authentication with Two Servers and a Proxy Section 12.12. When One Machine Is Not Enough for Your RDBMS DataBase and mod_perl Section 12.13. Running More than One mod_perl Server on the Same Machine Section 12.14. SSL Functionality and a mod_perl Server Section 12.15. Uploading and Downloading Big Files Section 12.16. References Chapter 13. TMTOWTDI: Convenience and Habit Versus Performance Section 13.1. Apache::Registry PerlHandler Versus Custom PerlHandler Section 13.2. Apache::args Versus Apache::Request::param Versus CGI::param Section 13.3. Buffered Printing and Better print( ) Techniques Section 13.4. Interpolation, Concatenation, or List Section 13.5. Keeping a Small Memory Footprint Section 13.6. Object Methods Calls Versus Function Calls Section 13.7. Using the Perl stat( ) Call's Cached Results Section 13.8. time( ) System Call Versus $r->request_time Section 13.9. Printing Unmodified Files Section 13.10. Caching and Pre-Caching Section 13.11. Caching with Memoize Section 13.12. Comparing Runtime Performance of Perl and C Section 13.13. References Chapter 14. Defensive Measures for Performance Enhancement Section 14.1. Controlling Your Memory Usage Section 14.2. Coding for a Smaller Memory Footprint Section 14.3. Conclusion Section 14.4. References Chapter 15. Improving Performance Through Build Options Section 15.1. Server Size as a Function of Compiled-in Features Section 15.2. mod_status and ExtendedStatus On Section 15.3. DYNAMIC_MODULE_LIMIT Apache Build Option Section 15.4. Perl Build Options Section 15.5. Architecture-Specific Compile Options Section 15.6. References Chapter 16. HTTP Headers for Optimal Performance Section 16.1. Date-Related Headers Section 16.2. Content Headers Section 16.3. Content Negotiation Section 16.4. HTTP Requests Section 16.5. Avoiding Dealing with Headers Section 16.6. References Part III: Databases and mod_perl Chapter 17. Databases Overview Section 17.1. Volatile Databases Section 17.2. Non-Volatile Databases Section 17.3. References Chapter 18. mod_perl Data-Sharing Techniques Section 18.1. Sharing the Read-Only Data in and Between Processes Section 18.2. Sharing Data Between Various Handlers Section 18.3. References Chapter 19. DBM and mod_perl Section 19.1. mod_perl and DBM Section 19.2. Resource Locking Section 19.3. Flawed Locking Methods Section 19.4. Locking Wrappers Overview Section 19.5. Tie::DB_Lock Section 19.6. Examples Section 19.7. References Chapter 20. Relational Databases and mod_perl Section 20.1. Persistent Database Connections with Apache::DBI Section 20.2. Improving Performance Section 20.3. DBI Debug Techniques Section 20.4. References Part IV: Debugging and Troubleshooting Chapter 21. Error Handling and Debugging Section 21.1. Warnings and Errors Explained Section 21.2. Debugging Code in Single-Server Mode Section 21.3. Tracing System Calls Section 21.4. Tracing mod_perl-Specific Perl Calls Section 21.5. Debugging Perl Code Section 21.6. Analyzing Dumped core Files Section 21.7. Hanging Processes: Detection and Diagnostics Section 21.8. Useful Debug Modules Section 21.9. Looking Inside the Server Section 21.10. References Chapter 22. Troubleshooting mod_perl Section 22.1. Configuration and Startup Section 22.2. Code Parsing and Compilation Section 22.3. Runtime Section 22.4. Shutdown and Restart Chapter 23. Getting Help and Online Resources Section 23.1. How to Report Problems Section 23.2. Mailing List Etiquette Section 23.3. Resources Part V: mod_perl 2.0 Chapter 24. mod_perl 2.0: Installation and Configuration Section 24.1. What's New in Apache 2.0 Section 24.2. What's New in Perl 5.6.0-5.8.0 Section 24.3. What's New in mod_perl 2.0 Section 24.4.
Load more

  1060
Copy Link
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]