Data segment: Difference between revisions

Revision as of 08:42, 7 August 2017

Latest revision as of 07:43, 29 April 2025

(33 intermediate revisions by 29 users not shown)

Line 1:

{{Short description|Storage segment}}

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 variable]]s, that is, [[global variable]]s and [[static local variable]]s. 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 (program lifecycle phase)|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'' (''{{visible anchor|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. Zero-initializedUninitialized data, both variables and constants, is instead in the [[BSS segment.bss]] segment.

Historically, to be able to support memory address spaces larger than the native size of the internal address register would allow, early CPUs implemented a system of segmentation whereby they would store a small set of indexes to use as offsets to certain areas. The [[Intel 8086]] family of CPUs provided four segments: the code segment, the data segment, the stack segment and the extra segment. Each segment was placed at a specific ___location in memory by the software being executed and all instructions that operated on the data within those segments were performed relative to the start of that segment. This allowed a 16-bit address register, which would normally providebe 64KiBable (65536to access 64 bytes)KB of memory space, to access a1 1MiBMB (1048576of bytes) addressmemory space.

This segmenting of the memory space into discrete blocks with specific tasks carried over into the programming languages of the day and the concept is still widely in use within modern programming languages.

==Program memory==

A computer program memory can be largely categorized into two sections: read-only and read-write. This distinction grew from early systems holding their main program in [[read-only memory]] such as [[Mask ROM]], [[Programmable read-only memory|PROM]] or [[EEPROM]]. As systems became more complex and programs were loaded from other media into RAM instead of executing from ROM the idea that some portions of the program's memory should not be modified was retained. These became the ''.text'' and ''.rodata'' segments of the program, and the remainder which could be written to divided into a number of other segments for specific tasks.

== Program memory ==

'''<big>Text</big>'''

A computer program memory can be largely categorized into two sections: read-only and read-/write. This distinction grew from early systems holding their main program in [[read-only memory]] such as [[Mask ROM]], [[EPROM]], [[Programmable read-only memory|PROM]] or [[EEPROM]]. As systems became more complex and programs were loaded from other media into RAM instead of executing from ROM, the idea that some portions of the program's memory should not be modified was retained. These became the ''.text'' and ''.rodata'' segments of the program, and the remainder which could be written to divided into a number of other segments for specific tasks.

===Heap Code ===

The '''code segment''', also known as a '''text segment''' or simply as '''text''', is where a portion of an [[object file]] or the corresponding section of the program's [[virtual address space]] that contains [[executable]] instructions is stored and is generally read-only and fixed size.

{{main|Code segment}}

The '''code segment''', also known as '''text segment''', contains [[executable]] code and is generally read-only and fixed size.

=== Data ===

[[File:Program memory layout.pdf|thumb|383x383px|This shows the typical layout of a simple computer's program memory with the text, various data, and stack and heap sections.]]

The ''.'data segment''' segment contains any global orinitialized static variables, whichi.e. haveglobal a pre-defined valuevariables and canlocal be modified. That is anystatic variables thatwhich arehave nota defined within a functionvalue (and thus can be accessed from anywhere) or are defined in a function but are defined as ''static'' so they retain their address across subsequent callsmodified. Examples, in C, include:

<syntaxhighlight lang="c">

int vali = 3;

char stringa[] = "Hello World";bbbbbbbbbbbbbb

static int b = 2023; // Initialized static global variable

void foo (void) {

static int c = 2023; // Initialized static local variable

}

</syntaxhighlight>

===Stack BSS ===

The values for these variables are initially stored within the read-only memory (typically within ''.text'') and are copied into the ''.data'' segment during the start-up routine of the program.

{{main|BSS segment}}

The [['''BSS segment]], also known as ''uninitialized data'', iscontains usuallyuninitialized adjacent to thestatic data, segment.both Thevariables BSSand segmentconstants, contains alli.e. global variables and local static variables that are initialized to zero or do not have explicit initialization in source code. For instance, a variable defined as <code>static int i;</code> would be containedExamples in theC BSS segment.include:

<syntaxhighlight lang="c">

static int i;

static char a[12];

</syntaxhighlight>

=== Heap ===

{{main|Manual memory management}}

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

===BSS Stack ===

{{Main main| Call stack}}

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 <code>static int i;</code> would be contained in the BSS segment.

The '''stack areasegment''' contains the program [[Stack (datacall structure)|stack]], a [[LIFO (computing)|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 variable]]s are also allocated on the stack.

The stack areasegment traditionally adjoined the heap areasegment 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 a converging direction. 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.

===Heap===

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]], calloc, realloc, and free, which may use the [[Sbrk|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/calloc/realloc/free; they may also be implemented using [[mmap]]/munmap to reserve/unreserve 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===

{{Main | Call stack}}

The stack area contains the program [[Stack (data structure)|stack]], a [[LIFO (computing)|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 variable]]s 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 a converging direction. 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==

Some interpreted languages offer a similar facility to the data segment, notably [[Perl]]<ref>[http://perldoc.perl.org/perldata.html#Special-Literals perldata: Special Literals]</ref> and [[Ruby (programming language)|Ruby]].<ref>Ruby: ObjectEmbedded Data: [httphttps://docs.ruby-doclang.org/docsen/keywordsmaster/1.9/Objectglobals_rdoc.html#methodlabel-i-__END__ __END__Embedded+Data]</ref> In these languages, including the line <code>__DATA__</code> (Perl) or <code>__END__</code> (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: <code>PACKAGE::DATA</code> in Perl (e.g., <code>main::DATA</code>) and <code>DATA</code> in Ruby. This can be considered a form of [[here document]] (a file literal).

==See also==

Line 46 ⟶ 56:

* [[Uninitialized variable]]

* [[Stack (abstract data type)]]

* [[Process control block]]

== References ==

{{reflist}}

{{refbegin}}

* {{cite web|title=BraveGNU.org|url=http://www.bravegnu.org/gnu-eprog/c-startup.html}}

{{refend}}

== External links ==

* {{cite web

*[http://blog.ooz.ie/2008/09/0x03-notes-on-assembly-memory-from.html mem_sequence.c - sequentially lists memory regions in a process]

|title=C startup

*[http://www.comp.nus.edu.sg/~xujia/Expert.C.Programming.pdf Expert C Programming: Deep C Secrets, Peter van der Linden, Prentice Hall 1997, p. 119ff]

* {{cite web|title=BraveGNU.org|url=http://www.bravegnu.org/gnu-eprog/c-startup.html}}

|website = bravegnu.org}}

* {{cite web

*[|url = http://blog.ooz.ie/2008/09/0x03-notes-on-assembly-memory-from.html mem_sequence.c - sequentially lists memory regions in a process]

|archive-url = https://web.archive.org/web/20090202113414/http://blog.ooz.ie/2008/09/0x03-notes-on-assembly-memory-from.html

|url-status = dead

|archive-date = 2009-02-02

|title = mem_sequence.c - sequentially lists memory regions in a process}}

* {{cite book

|url = http://www.electroons.com/8051/ebooks/expert%20C%20programming.pdf

|title = Expert C Programming: Deep C Secrets

|first = Peter

|last = van der Linden

|publisher = Prentice Hall

|year = 1997

|pages = 119ff}}

{{DEFAULTSORT:Data Segment}}