On Sat, 21 Aug 1999, Philip Blundell wrote:
> > Why can the linker not deal with function calls more then a 26 bit
> >address offset from teh PC?
>
> The B instruction only has a 24-bit displacement field. That stores a number
> of words which gives you a 26-bit address offset. To do jumps beyond that,
I relise that but isn't this a common thing in RISC chips and
linkers/compilers use long jump?
> the linker would have to bounce the call through a PLT entry. It probably
> wouldn't be too hard to make this happen automatically for out of range
> jumps if you wanted (though this should be controlled by a switch). As a
> matter of passing interest modutils already does something a bit like this
> so that kernel modules can be quite distant from the main code body.
>
> Another possibility would be to extend the compiler and/or assembler to let
> you declare a particular function call as being "long" and have that generate
> code that rather than a straightforward branch contained code a bit like this:
>
> mov lr, pc
> ldr pc, =target
>
> It would take quite a lot to convince me that the latter was worth including
> in GCC, though. The linker thing seems conceptually cleaner - there will be
> a performance hit but I doubt it is measurable.
>
> In theory a smart linker could actually perform the second trick too but GNU
> ld isn't currently up to it.
Ic.
>
> (Why do you want to do this in the first place, by the way?)
>
I have initialiseation an initialisation section and a kernel text
section (both loadable segments) The initialisation section is mapped
one-one at 0xC0100000 (on the SA-1100) and the text section is mapped to
0xFFFF0000. I have debugging calls in the text section that I try to call
from the init sectin (putc, printf, dumpPT, etc) but the 26bit branching
gets in the way. I could use ASM macro's to make the calls but this seems
abit messy, is there a nice solution to this problem. Another solution is
to have the functions linked in both sections with different names but
again I think this is a bit messy.
Cheers Adam
> p.
>
>
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
