| Author |
Message |
s.subbarayan
Guest
|
 Posted:
Wed Jan 19, 2005 7:57 am Post subject:
Relocating application architecture and compiler support |
|
|
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. |
|
| Back to top |
|
 |
Tauno Voipio
Guest
|
| Posted:
Wed Jan 19, 2005 1:38 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
s.subbarayan wrote:
| Quote: | 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.
|
Which processor?
Which compiler / assembler / linker?
Which target board?
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.
--
Tauno Voipio
tauno voipio (at) iki fi |
|
| Back to top |
|
|
Guest
|
| Posted:
Wed Jan 19, 2005 5:31 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
Hi,
Thanks for your reply.I am using Hitachi 7709 processor and compiler is
Hitachi workbench compiler version .2(beta version!).
Hope this answers you.
sorry for not providing this.
looking farward further for replys,
regards,
subbarayan
Tauno Voipio wrote:
| Quote: | s.subbarayan wrote:
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.
Which processor?
Which compiler / assembler / linker?
Which target board?
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.
--
Tauno Voipio
tauno voipio (at) iki fi |
|
|
| Back to top |
|
|
Grant Edwards
Guest
|
| Posted:
Wed Jan 19, 2005 7:21 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
On 2005-01-19, s.subbarayan <s_subbarayan@rediffmail.com> wrote:
| Quote: | Can some one advice me how to create relocatable application in C?
|
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.
| Quote: | Now whats the way to do this relocation incase my compiler does not
provide support for creating relocatable image?
|
None.
--
Grant Edwards grante Yow! Dizzy, are we
at "REAL PEOPLE" or "AMAZING
visi.com ANIMALS"? |
|
| Back to top |
|
|
Tauno Voipio
Guest
|
| Posted:
Thu Jan 20, 2005 12:02 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
s_subbarayan@rediffmail.com wrote:
| Quote: | Hi,
Thanks for your reply.I am using Hitachi 7709 processor and compiler is
Hitachi workbench compiler version .2(beta version!).
Hope this answers you.
sorry for not providing this.
looking farward further for replys,
|
I have no experience of Hitachi tools, sorry. Maybe somebody
knowing better can help you.
Next time, please respond *below* the quoted text and
prune extras off, thanks.
--
Tauno Voipio
tauno voipio (at) iki fi |
|
| Back to top |
|
|
Niklas Holsti
Guest
|
| Posted:
Thu Jan 20, 2005 12:36 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
s.subbarayan wrote:
| Quote: | 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.
|
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.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ . |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Thu Jan 20, 2005 2:16 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
Niklas Holsti wrote:
| Quote: | 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.
|
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.
| Quote: |
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.
|
Avoiding all stack use is the safest, most useful approach.
| Quote: |
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.
|
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
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Jack Klein
Guest
|
| Posted:
Thu Jan 20, 2005 7:59 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
On 18 Jan 2005 20:48:49 -0800, s_subbarayan@rediffmail.com
(s.subbarayan) wrote in comp.arch.embedded:
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
CBFalconer
Guest
|
| Posted:
Thu Jan 20, 2005 7:59 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
Jack Klein wrote:
| Quote: |
.... snip ...
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.
|
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 |
|
| Back to top |
|
|
Stephen Pelc
Guest
|
| Posted:
Thu Jan 20, 2005 3:09 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
On 18 Jan 2005 20:48:49 -0800, s_subbarayan@rediffmail.com
(s.subbarayan) wrote:
| Quote: | 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.
|
We've had to write relocatable binaries on systems that do not
well support position independent code. Our solution is most
easily implemented using a few lines of assembler for some code
that calculates the base address at which the code is actually
running.
We compile/link for two different addresses, and produce a data
table that holds the addresses of the differences. This table is added
to the binary. A small piece of start up code applies fixes.
We usually write this start up code in assembler, and it will
require the link address.
From our point of view, this technique is particularly attractive
because it insulates us from many of the details of the final
executable format if it is not a simple memory image.
Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads |
|
| Back to top |
|
|
Dave Hansen
Guest
|
| Posted:
Thu Jan 20, 2005 8:28 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
On Wed, 19 Jan 2005 22:31:09 -0600, Jack Klein <jackklein@spamcop.net>
wrote:
[...]
| Quote: |
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
|
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.
But I assumed the PC RAM was fine. ;-)
Regards,
-=Dave
--
Change is inevitable, progress is not. |
|
| Back to top |
|
|
CBFalconer
Guest
|
| Posted:
Thu Jan 20, 2005 9:19 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
Stephen Pelc wrote:
| Quote: | (s.subbarayan) wrote:
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.
We've had to write relocatable binaries on systems that do not
well support position independent code. Our solution is most
easily implemented using a few lines of assembler for some code
that calculates the base address at which the code is actually
running.
We compile/link for two different addresses, and produce a data
table that holds the addresses of the differences. This table is
added to the binary. A small piece of start up code applies fixes.
We usually write this start up code in assembler, and it will
require the link address.
From our point of view, this technique is particularly attractive
because it insulates us from many of the details of the final
executable format if it is not a simple memory image.
|
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:
<http://cbfalconer.home.att.net/download/cpm/ddtz27.zip>
--
"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 |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Thu Jan 20, 2005 9:47 pm Post subject:
Re: Relocating application architecture and compiler support |
|
|
CBFalconer <cbfalconer@yahoo.com> writes:
| Quote: | 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:
http://cbfalconer.home.att.net/download/cpm/ddtz27.zip
|
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
http://www.garlic.com/~lynn/subtopic.html#adcon
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/ |
|
| Back to top |
|
|
CBFalconer
Guest
|
| Posted:
Fri Jan 21, 2005 12:35 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
Anne & Lynn Wheeler wrote:
| Quote: |
.... snip ...
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.
|
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 |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Fri Jan 21, 2005 12:50 am Post subject:
Re: Relocating application architecture and compiler support |
|
|
CBFalconer <cbfalconer@yahoo.com> writes:
| Quote: | I thought the 360 architecture handled relocation very simply from
the beginning, with base registers.
|
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/ |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in