Christophe Rhodes <csr21@...> writes:
> ldso-stubs.o: In function `ldso_stub__sqrt':
> ldso-stubs.o(.text+0x378): relocation truncated to fit: R_SPARC_13 sqrt@...
This is related to the macro expansion of LDSO_STUBIFYMy understanding of it is like this:
These are stub functions at known addresses, that contain references
to the real functions at unknown addresses. We depend on the dynamic
loader to scribble inside these functions when the shared libraries
are loaded, so that Lisp code can call our stubs and our stubs will
then forward the call to the actual function.
Problem is, the JMP instruction format on a sparc has only 13 bits for
'constant' in the address it jumps to (it's actually a synthetic
instruction that gets expanded to "jmpl address,%g0" and %g0 is
hardwired zero) so unless our shared library gets loaded nearby that's
not going to help a lot (I don't know what guarantees are or are not
made by sparc linux regarding where shared libraries end up in
memory, so I'm supposing they might not be nearby)
You might be able to use CALL instead, which has a 30 bit displacement
(and shifts it left two bits, so you can get to anywhere you like in
memory). But CALL expects to be used in conjunction with SAVE and
RESTORE (the register window shifting instructions) which we're not
using. So it writes PC into %r15, blotting out the previous value of
PC, which we need to keep if we're going to get back to the real
caller. That's no good either.
I think we have to use JMPL and load up a register with the offset we
want to jump to. I've not actually tried this (I don't have a sparc,
for one thing), but I think that the magic you want is along the lines
nop /* delay slot*/
%g1 is one of the global registers and considered volatile across
procedure calls. %g0 is hardwired zero, so we don't save the return
address anywhere. But that's ok, because we're not coming back here
anyway, we're returning direct to the caller. The nop is there because
the sparc will execute the instruction following a jump even if it
takes the jump.
So, clone the LDSO_STUBIFY macro (the alpha branch is fairly
straightforward) and replace "jmp fct" with aforementioned guff. Of
course, it'll be a while yet before you actually hit the point where
you can find out if this works ...
> Now, I believe I have identified, if not a compiler bug, at least a
> compiler confusion with respect to %instance-ref and sb!kernel:instances
This stuff I have no idea about. Bill?
> This is also a problem on the PPC port, incidentally...
Yes, it is. I have a truely bletcherous not-actually-a-workaround for
the PPC, which involves a placeholder definition of
define-full-reffer. It creates VOPs that translate to "nop", which is
why I know it's not a workaround. It does however let me get all the
way to genesis and a cold-sbcl.core that looks about the right size,
so I'm fighting on a different front right now.
[ On a marginally related note, I spent some time recently tidying up
cliki internals to the point that I believe I can now host two
separate instances of it in the same lisp image. What I intend to do
is create a "SBCL internals cliki" initially populated with the info
from doc/cmucl/internals and various posts on sbcl-devel - hands up if
you think you'd (a) find it a useful resource, (b) contribute to it ]
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources