Clarify on these questions, please?

chrisname (7395)
I came up with a couple of questions to check that I know about pointers and memory allocation and what not; could someone tell me if my answers are right, and if not; correct me? Thanks.

1. What is the purpose of the stack.
To allocate memory for variables, keep track of the program control (what function is being executed).

2. What is the purpose of the heap.
Allocates memory at runtime, gets memory from the operating system.

3. What is a segment?
The address space of a program in memory given by the operating system, e.g. 0x601044 - 0x602044 or something.

Could someone say if these answers are correct; and, if they are not, correct me? I need to learn this stuff accurately, thanks :)

I thought of some more but I can't remember them :l
jsmith (5804)
The main purpose of the stack is to allow function calls to return to the correct place in the program.
Side benefits include providing temporary memory for local variables, parameters, and return values.
The stack is typically small in relation to the heap.

The main purpose of the heap is to provide storage for objects/data that need to live beyond the
scope in which they are declared. It also provides a place to store large objects/data that would
not otherwise fit on the stack or consume too much stack space.

jRaskell (347)
Those answers look pretty good as brief descriptions. Couple minor clarifications:

Stack is where local variables get allocated.
Heap is where dynamic memory allocation occurs.

Memory segmentation is a form of access protection. The segment provided to an application by the OS is the only memory space it's allowed to access (without going through the OS). If it tries to access memory outside this segment, it causes a segmentation fault and the OS aborts operation of that application.
chrisname (7395)
The main purpose of the stack is to allow function calls to return to the correct place in the program.

That's what I meant by "program control". I should have said "flow of execution" though really.

Side benefits include providing temporary memory for local variables, parameters, and return values.
The stack is typically small in relation to the heap.

Ok, thanks.

Those answers look pretty good as brief descriptions.

Thanks, I was kind of rushed at the time so they had to be brief. I forgot what the rest of my questions were, I came up with about five last night to answer but forgot the last two.

Stack is where local variables get allocated.
Heap is where dynamic memory allocation occurs.

Thank you :)

There should be an OS that allows programs to run in real mode in kernel-land. That would give everyone else a lot of experimentation... It could be called TestyOS or something... Obviously it would be very stupid to run it on a physical machine; you'd be at a very high risk of damaging the content of your hd if you were testing hard disk accesses or something. Still it would be fun to play with.

I wish I knew how to get debugging privileges. It's so cool how GDB can read through all the memory and print the contents. Mostly it's just garbage but if you look at the first address of a variable you have (e.g. char str[] = "Hello, world!" and is adressed at 0x654321) you can read the content of it if you tell GDB to print however many bytes (I think it would be 2 * 13 = 26, round up to 32) after that address. It's cool.

Memory segmentation is a form of access protection. The segment provided to an application by the OS is the only memory space it's allowed to access (without going through the OS). If it tries to access memory outside this segment, it causes a segmentation fault and the OS aborts operation of that application.

Ok.
Last edited on
chrisname (7395)
I remembered another question.

What is the difference between
a:
int* a;
and b:
int& b;

and what is the latter meant to do/be?
jsmith (5804)
The former compiles and the latter doesn't.

a is a pointer -- which may be NULL -- to an integer. a can point to any integer at any time (ie, you could have it point to one integer, and then change its value to point to a different integer).

b is a reference -- which internally is a pointer, except that it cannot be NULL* -- to an integer. b must be initialized upon declaration to refer to a particular integer, and that "binding" can never be changed during the lifetime of b.

*The programmer could go to great lengths to force a NULL reference...

firedraco (6247)
*The programmer could go to great lengths to force a NULL reference...


How would you do that? I thought the standard stated "There shall be no NULL references" or something similar.
chrisname (7395)
*The programmer could go to great lengths to force a NULL reference...

That doesn't make sense, then you could have int* p = 0x0; or something.

The former compiles and the latter doesn't.

I've seen int& before somewhere. I've also seen std::string&.

I know that the asterisk '*' is the dereference/indirection operator and ampersand '&' is the reference operator, but I didn't understand when I saw "int& myInt" somewhere.
jsmith (5804)
1
2
3
 
int a;
int& b = a;
*reinterpret_cast<int*>( b ) = 0;


NULLs out the reference. (By 'going to great lengths' I mean 'doing stupid things').

All references must be initialized at instantiation time (which is different from declaration time):

1
2
3
4
 
struct foo {
    foo( int& ri ) : int_ref( ri ) {}
    int& int_ref;
};


chrisname (7395)
I think I get it now. Thank you.

Any ideas on reading memory locations outside my segment? :)
I wouldn't write any thing, I know how annoying it would be to lose half a text document because I was writing garbage data to random memory locations... it would be funny though... "Hello, this is a text file&£$FGN357(#F356G574FGTJO6I8|"
Last edited on
jRaskell (347)
Accessing other processes on the system is not exactly a trivial task, intentionally so for security reasons, but it is certainly possible.

Have a look at this MSDN on the various Win32 Debug functions available, one of which is ReadProcessMemory:
http://msdn.microsoft.com/en-us/library/ms679303(VS.85).aspx

Look up the following functions as well on how to get the necessary handles to other processes on the system to use with these Debug functions (Depending on what you're trying to do though, you may not have the appropriate security privileges):
GetWindow
EnumWindows
GetWindowThreadProcessId

And there are a bunch more that are available as well. I haven't actually worked with any of the Debug functions though.
chrisname (7395)
I should have mentioned that I'm on Linux :(
I don't have your crazy "ReadProcessMemory()" functions...
Otherwise I would have used the registry to force the processes to load my DLLs and then read their memory that way.
jsmith (5804)
I use linux all the time and am not aware of any functions that allow one process to access the memory of another
(shared memory stuff aside).
jRaskell (347)
Sorry, bad assumption on my part. Good news for you though. In this case, the solution is easier (but still not necessarily easy). Just look up ptrace().
chrisname (7395)
Ok, thanks :)

http://linux.die.net/man/2/ptrace

That looks do-able :)

I just did this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
 
#include <stdio.h>

typedef unsigned int uint;

/* Below is a structure containing information for the following
 * registers:
 * **********
 * General purpose:
 *     EAX EBX ECX EDX
 * Segment registers:
 *     CS DS ES FS GS SS
 * Index and pointers:
 *     ESI EDI EBP EIP ESP
 */

struct cpu_registers_contents {
    /* General purpose registers: */
    uint eax;
    uint ebx;
    uint ecx;
    uint edx;
    /* Segment registers: */
    /* Unsure of data type; TODO: Find out datatype. */
    /* Index and pointer registers: */
    /* TODO: Figure out datatype of index */
    uint ebp;
    uint eip;
    uint esp;
} reg;

void getRegisters(void);

int main() {
    getRegisters();

    printf("Contents of registers:\n\t");
    printf("General purpose registers:\n\t\t");
    printf("eax: %6d\n\t\tebx: %6d\n\t\tecx: %6d\n\t\tedx: %6d\n\t",
           reg.eax, reg.ebx, reg.ecx, reg.edx);
    printf("Segment registers: As yet unable to get.\n\t");
    printf("Index registers: As yet unable to get.\n\t");
    printf("Pointer registers:\n\t\t");
    printf("ebp: %6d\n\t\teip: unable to get\n\t\tesp: %6d\n",
            reg.ebp, /* reg.eip, */ reg.esp);
    return 0;
}

/* getRegisters() -- set values in struct cpu_registers_contents to the values
 *                   of the appropriate CPU registers.
 * Return value: void (none);
 * Arguments:    void (none).
 */

void getRegisters(void) {
    int temp;

    /* Get general purpose registers: */
    asm("movl %%eax, %0\n" :"=r"(temp));
    reg.eax = temp;

    asm("movl %%ebx, %0\n" :"=r"(temp));
    reg.ebx = temp;
    
    asm("movl %%ecx, %0\n" :"=r"(temp));
    reg.ecx = temp;
        
    asm("movl %%edx, %0\n" :"=r"(temp));
    reg.edx = temp;
    
    /* Get pointer addresses */
    
    asm("movl %%ebp, %0" :"=r"(temp));
    reg.ebp = temp;
    
    asm("movl %%esp, %0" :"=r"(temp));
    reg.esp = temp;
}
 
output:
root@chris:/home/chris# gcc -Wall -pedantic getRegisters.c
root@chris:/home/chris# ./a.out
Contents of registers:
	General purpose registers:
		eax: 1100946112
		ebx: 4195872
		ecx:      0
		edx: 1237406696
	Segment registers: As yet unable to get.
	Index registers: As yet unable to get.
	Pointer registers:
		ebp: 1237406448
		eip: unable to get
		esp: 1237406448
Last edited on
Topic archived. No new replies allowed.