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?
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 08:44 PM.
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 08: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.
Originally Posted by Sebastiani
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?
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
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 09:11 PM.
Ok, so just having a few ORIGIN statements shouldn't ruin the system, but probably won't work? I will try the malloc statements
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.
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.
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); //}
Ok, so I should be all set running it as-is then?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.
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.
