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