Memory allocation/corruption

This is a discussion on Memory allocation/corruption within the C Programming forums, part of the General Programming Boards category; I have a program that I am converting from being compiled with Green Hills Multi to GNU. There are several ...

  1. #1
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50

    Memory allocation/corruption

    I have a program that I am converting from being compiled with Green Hills Multi to GNU. There are several instances in the Linker script that set data to specific memory locations, i.e. ORIGIN = 0x70000.

    Since I assume Green Hills Multi somehow simulated these memory addresses, what can I do to ensure that I do not corrupt the memory on my computer by trying to run this program?

  2. #2
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    What operating system is the program running on? On Windows, for example, the linker can't really specify load addresses (or at least they won't make it into the executable).

    EDIT: That is not to say you can't "request" a preferred load address for the code, for example, but it's just treated as a "suggestion".
    Last edited by Sebastiani; 09-08-2009 at 09:44 PM.

  3. #3
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    Something Like ORIGIN = malloc(STACK_MAX-0x70000) perhaps. STACK_MAX, because generally the stack is at the highest memory address available. Although you may need something smaller, if the system cannot allocate that much memory for you.

    Basically convert all hard coded pointers to either malloced blocks, or offsets from a fixed beginning of working memory, which is malloced.
    Last edited by King Mir; 09-08-2009 at 09:48 PM.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  4. #4
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by Sebastiani View Post
    What operating system is the program running on? On Windows, for example, the linker can't really specify load addresses (or at least they won't make it into the executable).

    EDIT: That is not to say you can't "request" a preferred load address for the code, for example, but it's just treated as a "suggestion".
    Something Like ORIGIN = malloc(STACK_MAX-0x70000) perhaps. STACK_MAX, because generally the stack is at the highest memory address available. Although you may need something smaller, if the system cannot allocate that much memory for you.

    Basically convert all hard coded pointers to either malloced blocks, or offsets from a fixed beginning of working memory, which is malloced.

    I am running on windows XP. The program is currently cross compiled for a motorola 68000 but I needed a way to test it before being loaded.

    If I just run the program how it is, without the malloc, will it corrupt the windows/intel memory or will it just place the data where ever it can? The specific memory locations are really only important on the 68k. Or do I have to malloc every statement?

  5. #5
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Windows uses virtual memory, so 0x70000 in program A will be in a completely different real memory location than 0x70000 in program B.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  6. #6
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    If what you mean is that you have some hard-coded memory accesses in your code, it won't harm the system* - it will just crash your program. All pointers should either be to real variables or call to malloc. Hard-coded addresses just won't work on most modern systems.

    *that is unless of course you write a bit-pattern to those locations that would be interpreted as "erase the hard-drive" or such and the OS executes it, thinking it's legitimate code! Unlikely scenario, obviously, but nonetheless possible.
    Last edited by Sebastiani; 09-08-2009 at 10:11 PM.

  7. #7
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by cpjust View Post
    Windows uses virtual memory, so 0x70000 in program A will be in a completely different real memory location than 0x70000 in program B.

    If what you mean is that you have some hard-coded memory accesses in your code, it won't harm the system* - it will just crash your program. All pointers should either be to real variables or call to malloc. Hard-coded addresses just won't work on most modern systems.

    *that is unless of course you write a bit-pattern to those locations that would be interpreted as "erase the hard-drive" or such and the OS executes it, thinking it's legitimate code! Unlikely scenario, obviously, but nonetheless possible.
    Ok, so just having a few ORIGIN statements shouldn't ruin the system, but probably won't work? I will try the malloc statements

  8. #8
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    You may be better off Getting an emulator for motorola 68k. Such as found here.

    IO may be different on the emulator than on the whatever the chip is connected to, however.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  9. #9
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by TheEngineer View Post
    I have a program that I am converting from being compiled with Green Hills Multi to GNU. There are several instances in the Linker script that set data to specific memory locations, i.e. ORIGIN = 0x70000.

    Since I assume Green Hills Multi somehow simulated these memory addresses, what can I do to ensure that I do not corrupt the memory on my computer by trying to run this program?
    If you're running on an operating system with virtual memory, you do not need to worry about this. If it was possible to crash/corrupt a system this way, then anybody with a linker could take down a computer. That would be kind of crazy.

    As long as the virtual address 0x70000 is not otherwise reserved (by the kernel or some other piece of code being linked) then you can leave it exactly as-is. The OS will load the program image at VMA 0x70000 just like you ask for. Remember that we're talking about virtual memory, not real memory. If you ask the operating system to give you a chunk of memory located at such-and-such address, it will do it.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  10. #10
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by King Mir View Post
    You may be better off Getting an emulator for motorola 68k. Such as found here.

    IO may be different on the emulator than on the whatever the chip is connected to, however.

    If you're running on an operating system with virtual memory, you do not need to worry about this. If it was possible to crash/corrupt a system this way, then anybody with a linker could take down a computer. That would be kind of crazy.

    As long as the virtual address 0x70000 is not otherwise reserved (by the kernel or some other piece of code being linked) then you can leave it exactly as-is. The OS will load the program image at VMA 0x70000 just like you ask for. Remember that we're talking about virtual memory, not real memory. If you ask the operating system to give you a chunk of memory located at such-and-such address, it will do it.
    Ok, so I should be all set running it as-is then?

    I have tried that emulator before but haven't been able to use it because I need to input s-record files in order to test the program.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 01-13-2008, 02:14 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  3. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  4. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 02:15 AM
  5. What's the best memory (RAM) type?
    By Unregistered in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 12-15-2001, 12:37 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21