Relative Jumps Only

OP #1818979
Rate this post
useful
not useful
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
#1818996
Rate this post
useful
not useful
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
OP #1820311
Rate this post
useful
not useful
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-libraries.html

or in the gcc help, sections "options".

Greetings,
Lasse
#1820375
Rate this post
useful
not useful
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
OP #1827218
Rate this post
useful
not useful
Hi,

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

Code output is identical to compiling without -fPIC, my disassembly 
looks like:
1
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
#1827221
Rate this post
useful
not useful
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.
#1827743
Rate this post
useful
not useful
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:
1
0x00000028:    3a000008    ...:    BCC      {pc}+0x28 ; 0x50

--
Marcus
#1829288
Rate this post
useful
not useful
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

Reply

Please log in before posting.

or

Log in with Google account

Registration is free and takes only a minute.

Register now