Embedded gurus, Can some one advice me how to create relocatable application in C?We are currently working in an application,where we are supposed to test the entire RAM area for physical errors in the chip.We have created our application for this.The problem we are facing is this:
Our application sits in a particular location in RAM.The requirement states we have to test entire area of RAM including the location where the code is sitting.(Code in this sense,entire binary image which includes code,data,stack,bss).So we came up with the idea of testing the areas other then where our image sits and then move our image to different location with in RAM which is already tested and then come back to original location.
But the problem with this solution is ,we are not aware how this relocation can be done?Does this relocation require compiler support?In the linker options used in our linker,we have options to create relocatable modules.But my colleague says it relocates only the code not the data and section areas.When I mean "relocatable module" what does it generally mean?
Now whats the way to do this relocation incase my compiler does not provide support for creating relocatable image?
Looking farward for all your replys and advanced thanks for the same, Regards, s.subbarayan.
The relocation method is much dependent on the responses to the previous questions.
Some examples:
- On an Intel x86 processor, it is possible to use the segment registers to effect a relocation. It's easier in 16 bit real mode and doable in protected mode.
- On an ARM, all the address constants in the code have to be changed to relocate the code. Direct branches and calls are OK without changes, but indirect pointers have to be changed.
- Some compilers are able to generate position-independent code, for example with the -fpic and -fPIC switches in GCC. The runtime library has to be compatible to work.
Sure. When you compile your files, tell your compiler you want it to generate position independant code. When you link your object modules into an executable image, tell it you want it to generate position independant code.
None.
--
Grant Edwards grante Yow! Dizzy, are we
at "REAL PEOPLE" or "AMAZING
visi.com ANIMALS"?
To me that seems like a complex and risky solution. For an alternative solution, and assuming that your memory-testing function can restore the original content of each memory location after testing it, how about having two copies of the test function in the application? Each copy uses its own (small) area of memory. The first copy tests the memory (code and data) used by the second copy, and the second copy tests everything else, including the first copy but not its own memory. In this way, the application can stay in one place, and memory locations are always inactive while they are being tested.
If your memory-testing function is complex enough to need a stack, you may have to use different stack areas for each copy. A simple testing function could be implemented with only registers and static variables so it could check the stack area without problems.
I'm assuming that the memory test is done with interrupts disabled and only one active thread. If the testing has to be done while the application is running, the solution must be very different.
This is a good approach if you have to stay with semi-portable C code.
If you can use asm, then it becomes much easier, I have written many self-relocating programs in pure assembler. (My usual approach for TSRs (Terminate and Stay Resident) Dos helper programs was to make them self-relocatable, so that they could initialize, figure out which functions would needed, and then pack the required modules into the smallest possible memory area.
For my executable ascii program, the wrapper code starts by unpacking the payload, which entails packing 4 MIME-encoded characters into 3 bytes of binary code. Next it moves itself into the tail end of the 64 K segment where a Dos .COM file must fit, moves the payload binary down to offset 100h which is the required starting point for such a file, and then jumps to the starting offset.
Avoiding all stack use is the safest, most useful approach.
Single-threading is given, but disabling all interrupts might be harder.
In that case you pretty much have to granularize your tests, disabling and enabling interrupts around each block.
Terje
--
-
"almost all programming can be viewed as an exercise in caching"
On 18 Jan 2005 20:48:49 -0800, s snipped-for-privacy@rediffmail.com (s.subbarayan) wrote in comp.arch.embedded:
I never have, and probably never will, write a RAM test in C, or for that matter one that runs in RAM. Although under some circumstances you might have to write one that runs from internal RAM on a microcontroller.
Your executable code exists in some sort of non-volatile memory at power up, obviously, most likely EPROM or flash. These days there are two possibilities, as a lot of microcontrollers have routines in internal ROM to copy code from a serial EEPROM device into internal RAM to boot from. No code you write ever runs until after it has been loaded into RAM.
But in the more general case, you have a flash or EPROM connected to the processor in the address range where start-up code is fetched. Because that device is narrow or slow or both, you want to copy your code from the flash or EPROM to RAM for faster execution. If your memory test code is copied into untested RAM, and the RAM is bad, the test will never run and your system is going off into never land when it jumps into the copied code.
The only robust way to do it, to guarantee that your RAM test will identify bad RAM and not crash or go crazy, is to run your test in place from the EPROM or flash, and don't use any of the RAM you are testing for anything, such as stack or variable storage. That's easy to do in assembly language, but ranges from difficult to impossible in C.
I have successfully written memory tests this way, for systems with no internal RAM on the processor/microcontroller, that will correctly run with no RAM installed on the board, and indicate a RAM failure of course.
A RAM test that can't run unless at least part of the RAM is already good is for show only, just window dressing. It's absolutely useless for high reliability or safety critical systems.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
But you can use a pretty simple test for that preliminary work. I used to read a location, save in register, complement value, write, compare reg/memory, complement again (to restore), write, compare reg/memory. This could test everything except the few instructions used within that loop.
I put this all in a routine that used only registers, including the return address. It was called with start/end/return addresses to test, and returned a condition flag. On failure the address register indicated the problem location. It also served nicely to find the top of read/write memory installed.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
I wrote one if Forth once, though it could have been written in C.
Kind of a special circumstance, though. I was testing the RAM on a prototype video capture board plugged into the PCI bus of a desktop PC. This was for hardware development/bring up rather than production/end user use. Somewhat more thorough than the standard power-up read/write RAM test most embedded system go through -- I was looking for crossed/stuck address/decode lines more than stuck bits.
Took longer, too. But speed of execution wasn't the driving issue, speed of implementation was. Forth provided an interactive environment. C didn't.
This technique has been around for a long time, and is the heart of the old CP/M PRL (page relocatable) format. I had it highly automated, as exemplified by the program CCINSTAL and batch job MAKEDDT.JOB contained in ddtz27.zip. My CCINSTAL code is dated
1986, and was not new then. You can examine it all at:
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
i had done stuff in the early 70s for relocatable shared segments ... i.e. the same code running concurrently in the same shared segment that resided at different virtual addresses in different virtual address spaces ... random past posts on the subject
formatting link
i was trying to deal with the problem from a structure that was basically os/360 conventions with relocatable adcons .... a feature of executable binaries when stored on disk ... and which would be updated with fixed addresses when the binaries were brought into memory for execution. the problem was that the embedded fixed addressess would be unique to specific location of the executable binary. basically i had to make addresses relative to value that could be calculated on the fly.
not quite ten years earlier, tss/360 had dealt with the issue by separating the code and addresses (as data) ... and that the addresses could be located in private memory area separate from the instruction.
there were other systems from the 60s that also addressed the same issue.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
I thought the 360 architecture handled relocation very simply from the beginning, with base registers.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
standard instructions used register address plus 12bit displacement. however os/360 compilers and assemblers generated intermediate executables that had instructions and data intermixed ... including address constants that conventional programs would load into registers for use in "relocation".
there was administrative bookkeeping kept at the end of each such file that listed the location (within the program) of each such address constant and some (possibly symbolic) information on how to initialize the address constant when the program was loaded into memory. This administrative information was commonly referred to as relocatable adcons (ADdress Constants) .... but they actually became fixed address constants at the time the program was loaded into memory for actual execution (aka the executable image out on disk and the executable image resident in memory tended to defer at least by the swizzling that went on for such address constants).
so 360 hardware architecture went to all the trouble of making instruction execution relocatable ... and then, effectively, the os/360 software guys took some short cuts and established conventions making the actually executable images in memory bound to fixed address location.
tss/360 was a parallel operating system effort that was targeted at time-sharing (aka TSS .. Time Sharing System) designed for 360/67 ... which was the only 360 with virtual memory capability. tss/360 operating system conventions went a lot further towards trying to make sure that the executable image on disk was exactly the same executable image running in memory ... and preserving the relocatable 360 hardware instruction paradigm.
In os/360 operating system convention the "relocatble address constants' that were sprinkled thru-out the binary image on disk had to be swizzled as part of brining the image into memory for execution (and at the same time bound the in-memory image to a specific address).
TSS/360 had a one-level store, page-mapped orientation ... much more orientated towards what was on disk and what was in memory would be identical.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Plus others that did other things, including creating position independent code - I can't remember if any IBM compilers did that, but it wouldn't surprise me.
I was only half joking when I said that the answer to "Did OS/360 use technique XXX?" is "yes" :-)
One of the reasons for base registers is to keep code size down. In the days of 24 bit address space on 32K byte machines, it is not necessary to use 24 instruction bits for each address.
Base plus 12 bit displacement uses 16 instruction bits, and allows for a variety of different addressing modes using one addressing model.
1) Absolute addressing within the first 4K.
2) With one base register, addressing within a 4K CSECT often including data and code.
3) Indirect addressing by loading an address into a register and using that in the instruction.
4) Indexed using the index field of RX instructions, or computing the address using other instructions.
To do relocation using base registers would require that the OS know which registers contained addresses. There is no hardware support for that.
however, there was one hardware mechanism of getting a value of the current instruction into a register for addressability ... w/o there having been loaded from some sort of address constant ... standard convention of BALR R12,0 USING *,R12
assembler convention and could also be used by compilers. Normally, branch-and-link was used for calls to subroutines with the supplied to branch address ... and at the same time saving the address of where the call came from. The above sequence was special case of branch-and-link, where it didn't actually take any branch but did establish the current address in a register (w/o requiring any address constant).
a fairly typical os/360 calling convention is something like:
L R15,=A(subroutine) BALR R14,R15
or
L R15,=V(subroutine) BALR R14,R15
where =A(subroutine) and =V(subroutine) become address constants that are internal to the program. In standard os/360, address constants are embedded inside the program and administrative detail is added at the end of the program which the program loader uses to swizzle all address constants to their absolute value when the program is loaded.
While the standard hardware didn't provide relocation of base registers .... it did provide the BALR convention of establishing an address on the fly w/o requiring (fixed) address constant and it didn't preclude software conventions that avoided the use of fixed address constants embedded in the executable image of the code.
TSS/360 created a different type of convention where on entry to a program, certain registers had preloaded values ... one of the registers contains a pointer to block of storage outside the executable code image ... where various things like address constants were located. The other convention was something like this
L R15,=V(subroutine-executablebase) AR R15,R12 BALR R14,R15
Where R12 contains "executablebase" for situation invoving displacements larger than 12bits. In os/360 terms, the value =A(subroutine-executablebase) is an absolute address constant (not a relocatible address constant requiring swizzle at program load) .... amd would be the same/constant value, regardless of the address that the program image was loaded. I used the above convention a lot in the early 70s for relocable shared segments.
One argument for =V(subroutine) address constant was that there was effectively "early binding" of the address (performed at program load time) ... and saved a register (assigning extra register for the convention) as well as saving an instruction in each calling sequence.
Now there were 360 machines that did have some additional relocation provided (not the virtual memory kind found in 360/67). System engineer on boeing account adapted a version of cp/67 (normally using paged virtual memory) to run on 360/50(?). My understanding is the
360/50 had something that I think was referred to as a DIL instruction (not part of standard 360 instruction operation) that was used in conjunction with some emulation packages (7090?) that allowed specification of base&bound .... basically a base value that the hardware added to all address calculations and then checked against the a bound value. This allowed simple contiguous address relocation (and required swapping of whole address space ... rather than the more granular paging available on 360/67.
This would be more akin to the current mainframe implementation of hardware supported virtual machines called LPARS (logical partitions) where physical memory can be partitioned into logical contiguous areas. No swapping or paging is supported by the hardware microcode for LPARs ... just the (relative) static partitioning of available physical memory. LPARS started out sort of being a significant subset of the mainframe virtual machine operating system support dropped into the hardware of the mainframe.
followed by an explanation about relocation techniques for the /360.
Corby wrote a paper Corbató, F. J., System requirements for multiple-access, time-shared computers, MAC-TR-3, May 1964.
"It is now clear that it is possible to create a general-purpose time-shared multiple access system on most contemporary computers. However, it is equally clear that none of the existent computers are well designed for multiple access systems...."
essentially explaining why the /360 architecture wouldn't do for what was becoming the Multics project. There's a downloadable version referenced in the Multicians' bibliography at
formatting link
(the paper is image format).
The do-it-yourself relocation scheme caused lots of pain for more vanilla users too: ultimately the addresses were physically absolute and the OS doesn't know where the addresses are. So if the operator wanted to swap something out, it was necessary to bring it back to the same place.
Base-and-bounds relocation (added as a hack by Boeing, as Wheeler reported) and of course the 360/67 and later DAT fixed this.
Yup. IBM published a most interesting set of articles on the S/360 in the IBM Systems Journal in 1964. An article by Gene Amdahl on "Processing unit design considerations" says on p 147-148 that relocation hardware was expensive, so they designed the 360's instruction set with small address displacements in the instructions to force all addressing to be relative to base registers so you can relocate programs by changing the base registers.
formatting link
By the following year they'd figured out that didn't work. In an article "On dynamic relocation" W. C. McGee, which references Corbató's report, he covers the various ways to make programs relocatable and concludes that you need hardware like that in the just-announced 360/67.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.