The u Area

In addition to the text, data, and stack segments, the operating system also maintains for each process a region called the u area (user area). The u area contains information specific to the process (e.g., open files, current directory, signal actions, accounting information) and a system stack segment for process use. If the process makes a system call (e.g., the system call to write in the function main in Program 1.1), the stack frame information for the system call is stored in the system stack segment. Again, this information is kept by the operating system in an area that the process does not normally have access to. Thus, if this information is needed, the process must use special system calls to access it. Like the process itself, the contents of the u area for the process are paged in and out by the operating system.

The conceptual relationship of system and process memory is illustrated in Figure 1.9.

1.10 Process Memory Addresses

The system keeps track of the virtual addresses^ associated with each user process segment. This address information is available to the process and can be obtained by referencing the external variables etext, edata, and end. The addresses (not the contents) of these three variables correspond respectively to the first valid address above the text, initialized data, and uninitialized data segments. Program 1.3 shows how this information can be obtained and displayed.

L J Logical addresses—calculated and used without concern as to their actual physical location.

Program 1.3 Displaying segment address information.

| Displaying process segment addresses

| #include <iostream>

+ extern int etext, edata, end;

| using namespace std;

| cout « "Adr etext: " « hex « int(&etext) « "\t ";

10 cout « "Adr edata: " « hex « int(&edata) « "\t ";

| cout « "Adr end: " « hex « int(&end ) « "\n";

If we add a few lines of code to our original Program 1.1, we can verify the virtual address location of key identifiers in our program. Program 1.4 incorporates an inline function, shw_adr( ), to display the address of an identifier.

Program 1.4 Confirming Program 1.1 address locations.

| Program 1.1 modified to display identifier addresses

| #include <iostream>

| #include <cstring> // needed for strcpy

| using namespace std;

| char *cptr = "Hello World\n"; // static by placement

| inline void SHW_ADR(char *ID, int address){

| cout « "The id " « ID « "\t is at : "

| extern int etext, edata, end;

| void showit(char *); // function prototype

| // display addresses

| cout « "Adr etext: " « hex « int(&etext) « "\t ";

| cout « "Adr edata: " « hex « int(&edata) « "\t ";

| cout « "Adr end: " « hex « int(&end ) « "\n";

+ SHW_ADR("main", int(main)); // function addresses

| SHW_ADR("cptr", int(&cptr)); // static

| SHW_ADR("buffer1", int(&buffer1 ));

| SHW_ADR("i", int(&i)); // automatic 30

| strcpy(buffer1, "A demonstration^"); //library function

| write(1, bufferl, strlen(buffer1)+1); // system call

| SHW_ADR("buffer2", int(&buffer2)); // display address

40 if ((buffer2= new char[ strlen(p)+1 ]) != NULL){

| delete [] buffer2; // release location

+ cerr « "Allocation errorAn";

A run of this program produces output (Figure 1.10) that verifies our assertions concerning the range of addresses for identifiers of different storage types. Note the actual addresses displayed by the program are system-dependent. Note that the command-line nm utility program can also be used verify the addresses displayed by Program 1.4.

Figure 1.10 Output of Program 1.4.

Adr etext: 8048bca Adr edata: 8049e18 Adr end: 8049ea8

The id main is at: 8048890

The id showit is at: 8048a44

The id cptr is at: 8049c74

The id bufferl is at: 8049e8c

The id i is at: bffffc54

A demonstration

The id buffer2 is at: bffffc34

Hello World

The output of Program 1.4 is presented pictorially in Figure 1.11.

etext 804£bca edata 804 9el8

804 9ea8

Figure 1.11. Address locations in Program 1.4.

Text

main

showit

Data Initialized

cptr

Uninitialized Data

bufferl

Unmapped (Heap)

Stack

buffers

i

8048690 S049c74 8049e8c bffffc34 bffffcS4

8048690 S049c74 8049e8c bffffc34 bffffcS4

For those with a further interest in this topic, many versions of Linux have an objdump utility that provides additional information for a specified object file.

Was this article helpful?

+1 0

Post a comment