In computing, a data segment (often denoted .data) is a portion of an object file or the corresponding virtual address space of a program that contains initialized static variables, that is, global variables and static local variables. The size of this segment is determined by the size of the values in the program's source code, and does not change at run time.

The data segment is read-write, since the values of variables can be altered at run time. This is in contrast to the read-only data segment (rodata segment or .rodata), which contains static constants rather than variables; it also contrasts to the code segment, also known as the text segment, which is read-only on many architectures. Uninitialized data, both variables and constants, is instead in the BSS segment.

The PC architecture supports a few basic read-write memory regions in a program: stack, data and code. The heap is another region of address space available to a program, from which memory can be dynamically allocated or freed by the operating system in response to system calls such as malloc and free.

Program memory[edit]

The computer program memory is organized into the data segment (data and BSS), heap, stack, and code segment, as further explained below.

Data[edit]

The data area contains global and static variables used by the program that are explicitly initialized with a non-zero (or non-NULL) value. This segment can be further classified into a read-only area and read-write area. For instance, the string defined by char s[] = "hello world" in C, or a C statement like int debug = 1 outside the main function, would be stored in initialized read-write area. Also, a C statement like const char* string = "hello world", placed outside the main function, stores the string literal "hello world" in the read-only area (however, some C implementations may store it in the code segment instead), and the character pointer variable string in initialized read-write area.

The BSS segment, also known as uninitialized data, is usually adjacent to the data segment. The BSS segment contains all global variables and static variables that are initialized to zero or do not have explicit initialization in source code. For instance, a variable defined as static int i; would be contained in the BSS segment.

Heap[edit]

The heap area commonly begins at the end of the .bss and .data segments and grows to larger addresses from there. The heap area is managed by malloc, realloc, and free, which may use the brk and sbrk system calls to adjust its size (note that the use of brk/sbrk and a single "heap area" is not required to fulfill the contract of malloc/realloc/free; they may also be implemented using mmap to reserve potentially non-contiguous regions of virtual memory into the process' virtual address space). The heap area is shared by all threads, shared libraries, and dynamically loaded modules in a process.

Stack[edit]

Main article: Call stack

The stack area contains the program stack, a LIFO structure, typically located in the higher parts of memory. A "stack pointer" register tracks the top of the stack; it is adjusted each time a value is "pushed" onto the stack. The set of values pushed for one function call is termed a "stack frame". A stack frame consists at minimum of a return address. Automatic variables are also allocated on the stack.

The stack area traditionally adjoined the heap area and they grew towards each other; when the stack pointer met the heap pointer, free memory was exhausted. With large address spaces and virtual memory techniques they tend to be placed more freely, but they still typically grow in opposite directions. On the standard PC x86 architecture the stack grows toward address zero, meaning that more recent items, deeper in the call chain, are at numerically lower addresses and closer to the heap. On some other architectures it grows the opposite direction.

Interpreted languages[edit]

Some interpreted languages offer a similar facility to the data segment, notably Perl[1] and Ruby.[2] In these languages, including the line __DATA__ (Perl) or __END__ (Ruby, old Perl) marks the end of the code segment and the start of the data segment. Only the contents prior to this line are executed, and the contents of the source file after this line are available as a file object: PACKAGE::DATA in Perl (e.g., main::DATA) andDATA in Ruby. This can be considered a form of here document (a file literal).

See also[edit]

References[edit]

External links[edit]






In computing, a code segment, also known as a text segment or simply as text, is a portion of an object file or the corresponding section of the program's virtual address space that contains executable instructions.[1] The term "segment" comes from the memory segment, which is a historical approach to memory management now known as paging. When a program is stored in an object file, the code segment is a part of this file; when the loader places a program into memory so that it may be executed, various memory regions are allocated (in particular, as pages), corresponding to both the segments in the object files and to segments only needed at run time. For example, the code segment of an object file is loaded into a corresponding code segment in memory.

The code segment in memory is typically read-only and has a fixed size, so on embedded systems it can usually be placed in read-only memory (ROM), without the need for loading. If the code segment is not read-only, then the particular architecture allows self-modifying code. Fixed-position or position independent code may be shared in memory by several processes in segmented or paged memory systems.[1][2] As a memory region, the code segment may be placed below the heap or stack in order to prevent heap and stack overflows from overwriting it.[3]

See also[edit]

References[edit]

  1. Jump up to:a b Jason W. Bacon (2012-03-13). "Chapter 10. Subprogram Calls and the Stack"cs.uwm.edu. Retrieved 2014-05-02. |chapter=ignored (help)
  2. Jump up^




source - https://en.wikipedia.org/wiki/Data_segment

https://en.wikipedia.org/wiki/Code_segment

'Development > Common' 카테고리의 다른 글

Using the OpenSSL toolkit  (0) 2017.09.17
First-class citizen, First-class function  (0) 2015.06.29
GUID(Globally Unique Identifier)  (0) 2014.04.02
MD 확장자  (0) 2013.03.27
SMTP & POP3 Server list  (0) 2013.02.11
Posted by linuxism
,