understanding memory

I'm not too sure of how memory allocation works. Correct me if I'm wrong:

When the code for a variable declaration is run, the program stores the address of an unnused location in memory in a data table. When the value held by the variable is called for, the program refers back to the data table for the address of the variable contents and then retrieves the contents from the memory location.


Is this true?
Is this only for object oriented programming?
Is there an intermediate "variable allocation table"?

Comments

  • : I'm not too sure of how memory allocation works. Correct me if I'm wrong:
    :
    : When the code for a variable declaration is run, the program stores the address of an unnused location in memory in a data table. When the value held by the variable is called for, the program refers back to the data table for the address of the variable contents and then retrieves the contents from the memory location.
    :
    :
    : Is this true?
    : Is this only for object oriented programming?
    : Is there an intermediate "variable allocation table"?
    :
    [blue]1. When you declare the variable inside the .DATA section its address called a [italic][b]relocation item[/b][/italic]. All these relocation items are stored into EXE file header. When EXE is loaded into memory - the loader also scans EXE for a table of relocations and 'fixes' all memory locations inside EXE file image in memory (just loaded). This way, when code runs, the correct address is stored inside a code segment. There is no tables as you described. If the code will go through a table every time you need to access a variable - it will be horribly slow.

    2. Another thing if you declare a local variable inside a procedure - the address of that variable depends on a current value of a stack access register (EBP for 32-bit programming or BP for 16-bit programming). So, the loader does not 'fix' that address. Every time you access such variable - the ASSEMBLER compiler uses instruction, like [EBP-xxx] - where 'xxx' is a relative offset for the local variable.

    I am not sure if it's clear enough...
    That's how it is.[/blue]
  • : [blue]1. When you declare the variable inside the .DATA section its address called a [italic][b]relocation item[/b][/italic]. All these relocation items are stored into EXE file header. When EXE is loaded into memory - the loader also scans EXE for a table of relocations and 'fixes' all memory locations inside EXE file image in memory (just loaded). This way, when code runs, the correct address is stored inside a code segment. There is no tables as you described. If the code will go through a table every time you need to access a variable - it will be horribly slow.
    :
    : 2. Another thing if you declare a local variable inside a procedure - the address of that variable depends on a current value of a stack access register (EBP for 32-bit programming or BP for 16-bit programming). So, the loader does not 'fix' that address. Every time you access such variable - the ASSEMBLER compiler uses instruction, like [EBP-xxx] - where 'xxx' is a relative offset for the local variable.
    :
    : I am not sure if it's clear enough...
    : That's how it is.[/blue]



    I understand.
    so when an exe is loaded, it is copied to RAM, where the header is read and the items in the relocation table are fixed (have their values increased by the segment of the loaded exe?).

    Now my question is: what is the purpose of the relocation table?
    you say that the declaration of the variable creates the relocation item, so is the variable now refered to through its corresponding relocation item?

    perhaps you could give me a link to a good paper on exe architecture, and what happens during runtime
  • hello
    the benefit of relocation is that the .data or any other section can be loaded anywhere in memory. for ex if relative virtual address of .data section is 1000h and image base is 400000h. the .data section will always be loaded at the offset 1000h of image base.

    not that the image base is just preferred address and loader can use any other address depending ont the situation.
    thus the pe loader has to just change the value in image base and all the values will in .data,.text will be correctly reflected because they are relative to the image base and not absolute address.

    you may want to read the pe tutorials from www.win32asm.cjb.net

    Regards
    Madhur Ahuja
    India



    : : [blue]1. When you declare the variable inside the .DATA section its address called a [italic][b]relocation item[/b][/italic]. All these relocation items are stored into EXE file header. When EXE is loaded into memory - the loader also scans EXE for a table of relocations and 'fixes' all memory locations inside EXE file image in memory (just loaded). This way, when code runs, the correct address is stored inside a code segment. There is no tables as you described. If the code will go through a table every time you need to access a variable - it will be horribly slow.
    : :
    : : 2. Another thing if you declare a local variable inside a procedure - the address of that variable depends on a current value of a stack access register (EBP for 32-bit programming or BP for 16-bit programming). So, the loader does not 'fix' that address. Every time you access such variable - the ASSEMBLER compiler uses instruction, like [EBP-xxx] - where 'xxx' is a relative offset for the local variable.
    : :
    : : I am not sure if it's clear enough...
    : : That's how it is.[/blue]
    :
    :
    :
    : I understand.
    : so when an exe is loaded, it is copied to RAM, where the header is read and the items in the relocation table are fixed (have their values increased by the segment of the loaded exe?).
    :
    : Now my question is: what is the purpose of the relocation table?
    : you say that the declaration of the variable creates the relocation item, so is the variable now refered to through its corresponding relocation item?
    :
    : perhaps you could give me a link to a good paper on exe architecture, and what happens during runtime
    :

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories