Hi,

is it possible to make gcc make relative functioncalls only?

Situation is as following:
I'm developing a core system, with functions to put graphic on a
display, interpret user input etc.

Some other guy (probably me too...) is coding an app for that system.
This app is later written into the flash (the free part where the core
system isn't). So neither the coderguy, nor the compiler/linker will
know the future position of the code.

This will make jumps to absolute addresses impossible.

If any questions are left, feel free to ask.

Greetings,
Lasse

PS: Cortex-M3, STM32F103, Codesourcery GCC

I've been looking for something like this for a long time. There appears
to be a "-fPIC" (Position Independent Code) switch in GCC. But there is
not much documentation about it, neither in general nor for ARM
architectures. Some descriptions claim that special tables are created
and a register is reserved for a base address - but details are missing.
Maybe "fPIC" works for certain other architectures only.

So if anybody knows something....?



Axel

So, you are basically coding API's?  I use software interrupts for this.
Will those work for you?

How would this solve the problems - the code still has to run from an
unknown location.

Axel

Yepp, it's going to be an api. And yes, I'm going to use the service
calls for that. But, as axel has already pointed out, it's not really
helping with the problem.

Our problem is concerning the program, not the api.



Ah, sorry, forgot to answer to your idea, Axel:
-fpic / -fPIC seems to be doing exactly, what we want.

You actually do find some information about it, eg. here:

http://tldp.org/HOWTO/Program-Library-HOWTO/shared...

or in the gcc help, sections "options".

Greetings,
Lasse

Oh, I must have misunderstood -- so the goal is to create a relocatable
library?

Presumably you have some sort of loader that at least knows where the
library is at runtime.  If nobody ever knows where the library is,
either at runtime or compile time, then you will be in trouble :)

I have plenty of experience with software interrupts but none with
relocatable libraries...best of luck!

--Bill

Hi,

it seemed so perfect, but it doesn't work.

Code output is identical to compiling without -fPIC, my disassembly
looks like:

0x0800185c <func+8>:  bl    0x8001840 <func2>

so no PIC at all. Has anyone got an(other) idea?

Reading in the CodeSourcery List [1], i've found out, that this seems to
be a bug in their compiler. But is that bug still open (That Message was
from 2007)? It actually is listed in their own manual.

Greetings
Lasse

[1]: http://www.codesourcery.com/archives/arm-gnu/msg01476.html

The machine operation BL already is PC-relative even though for your
convenience the disassembly shows the calculated target address instead
of the displacement. So there is not change to be expected from -fPIC at
this place.

The message refers to indirect function calls in C++ which are a little
more complicated to make position independant.

Thanks alot, that's good news! :)


Is there a way to get the listing be correct (with relative address)? I
can't find such an option.


Lasse

Obtain an assembly listing by -Wa,-a, then decode the instruction (low
order 24 bits sign extended and multiplied by 4).

Thanks!

I really appreciate your always well-founded answers! :)

Lasse

Lasse S. wrote:
> Is there a way to get the listing be correct (with relative address)? I
> can't find such an option.

Alternatively you may want to install a free-as-in-beer evaluation
version of Keil's MDK and use the command "fromelf -c <object>" to
obtain a disassembled listing. All PC-relative branches will be
displayed as such:

0x00000028:    3a000008    ...:    BCC      {pc}+0x28 ; 0x50

--
Marcus

Marcus Harnisch wrote:

0x00000028:    3a000008    ...:    BCC      {pc}+0x28 ; 0x50

Which however also is a convenience display mode, just a different one,
because the real offset is 8*4=0x20, based on PC+8 ;-).

A. K. wrote:
> Which however also is a convenience display mode, just a different one,
> because the real offset is 8*4=0x20, based on PC+8 ;-).

Of course, but within the listing numbers are consistent. Classical
difference between user friendly and expert friendly, I suppose :-)

However, the plan to simply decode the lower 24 bits would not really
help either, since the OP is targeting a Cortex-M3 which doesn't use the
simple ARM encoding that you suggested, but the various Thumb-2
encodings for (conditional) branches, which are rather more complex to
deal with.

--
Marcus