Relocating application architecture and compiler support

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

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

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:
Quoted text here. Click to load it
C?We
Quoted text here. Click to load it
test
requirement
where
testing
to
come
the
module"
Quoted text here. Click to load it
same,


Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

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


Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

None.

--
Grant Edwards                   grante             Yow!  Dizzy, are we
                                  at               "REAL PEOPLE" or "AMAZING
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

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

We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

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.
Quoted text here. Click to load it

Avoiding all stack use is the safest, most useful approach.
Quoted text here. Click to load it

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"

Re: Relocating application architecture and compiler support

Quoted text here. Click to load it

But not too different.  It's still a good idea to have two copies of
the test code.  

One possibility is an interrupt driven test which incrementally steps
through memory N words at a time.  If the target memory location falls
within the test routine itself, a second copy of the test code is
invoked instead.  This is easy if checking a single location at each
interrupt.  If checking multiple locations each time, you need to be
careful with the test code boundaries.

Another possibility is simply having two identical test routines tied
to different interrupts (or alternating on one interrupt), each of
which can check on each other's code addresses.

George
--
for email reply remove "/" from address

Re: Relocating application architecture and compiler support
On 18 Jan 2005 20:48:49 -0800, s snipped-for-privacy@rediffmail.com
(s.subbarayan) wrote in comp.arch.embedded:

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support

[...]
Quoted text here. Click to load it

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.

Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

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 /

Re: Relocating application architecture and compiler support
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

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 /

Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

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" :-)


Regards,
Nick Maclaren.

Re: Relocating application architecture and compiler support

(snip)

Quoted text here. Click to load it

None of the OS/360 compilers that I know about.

Quoted text here. Click to load it

With the number of different people working on it, and with the
variety of design goals, I agree.

-- glen


Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

Thanks.  It would almost certainly have been an oddball one if so.
We used a large range of compilers, several of which had been developed
at Cambridge, but including other non-IBM ones.  There were also a
large number of student compiler projects that got to the point of
usability.

Writing position independent code was pretty easy, but you had to
separate out the system interfaces and/or write your own macros.  IBM's
standard ones often generated ACONs and VCONs.


Regards,
Nick Maclaren.

Re: Relocating application architecture and compiler support

(snip)

Quoted text here. Click to load it

(I wrote)

Quoted text here. Click to load it


It might have been possible in a closed system, where users
couldn't write any assembly code.  I do remember CALL/OS, a
timesharing system with BASIC, FORTRAN, and PL/I, but I don't
know at all what it was like internally.

With a convention where some registers only held addresses, and
the rest never did you would know which registers to change on
relocation.

I suppose there should be two kinds of position independent
code.  One kind could be executed at any address, even more than
one (virtual) address at the same time.  The second could
actually be moved to a different address while executing.  It is
the second kind that is more complicated because registers could
hold addresses.

-- glen


Re: Relocating application architecture and compiler support
Quoted text here. Click to load it

Eh?  Not at all.  Every compiler that had an assembler interface
also had a set of documented conventions, which people writing
assembler had to follow.  Not a problem.

Quoted text here. Click to load it

We aren't talking about moving a task once it had been started,
which I agree is and was very hard, but about position independent
code.  I.e. code that could be read into memory, anywhere, without
relocation, and executed.  It wasn't hard - just a bit tedious.

I can still describe how it was done, if you are interested.


Regards,
Nick Maclaren.

Site Timeline