Wookey wrote:
And a follow-on
----- Forwarded message from Andrew Haley <[EMAIL PROTECTED]> -----
From: Andrew Haley <[EMAIL PROTECTED]>
Date: Wed, 4 Jul 2007 11:21:11 +0100
To: Wookey <[EMAIL PROTECTED]>, Aurelien Jarno <[EMAIL PROTECTED]>
Subject: Re: debian java libffi patches
X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO,
RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7-deb, No
Andrew Haley writes:
> Wookey writes:
> > On 2007-07-03 17:02 +0100, Andrew Haley wrote:
> > > [EMAIL PROTECTED]:~$ apt-get source libjava
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > E: You must put some 'source' URIs in your sources.list
> > > [EMAIL PROTECTED]:~$ apt-get source libgcj
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > E: You must put some 'source' URIs in your sources.list
> >
> > Only the binary repositories were listed (sources not normally needed
> > here, you are expected to be operating in the chroots).
> >
> > I've added source repositories too - should work now.
> >
> > (I fell off the net for a couple of hours after the thunder and
> > lightning)
>
> Ah. :) Remarkably, all the machines here stayed up despite the brownouts.
>
> Anyway, I have a problem. The linker is complaining about overflows
> in relocs, and I can see why:
>
> 2d9c: ebfffffe bl 0 <lt_dlopenext>
> 2d9c: R_ARM_PLT32 lt_dlopenext
>
> This looks to me like offsets from an instruction to the PLT have to
> be contained within 24 bits. Is that correct? The text section of
> libgcj (unoptimized) is 52794995 bytes, which I reckon needs a 26 or
> 27 bit offset field, depending on whether the bl instruction takes a
> signed or an unsigned offset.
>
> size .libs/libgcj.so.9.0.0
> text data bss dec hex filename
> 52794995 4723732 219216 57737943 37102d7 .libs/libgcj.so.9.0.0
>
> Dows the 24-bit limit of the bl instruction impose an absolute limit
> on the size of a shared library?
I would think that it would, at least in the general case. (OT: *man*
that's one huuuuge library!!)
The BL instruction has a 24-bit signed offset field. If you're going
bigger than that, use gcc's -mlong-calls option, which forces gcc to
emit branch instructions in a two-instruction sequence which has a
modest performance overhead but gives you the full 32-bit address space.
Which suggests that the text size when built with -Os would be about
halved -- 24 megabytes.
... which would have performance implications (probably not serious
ones), and would probably only postpone the inevitable. Maybe you want
to use -mlong-calls for the unoptimized case, and not anywhere else?
At one point I thought gas/ld would patch up oversized branch
instructions, but I guess not...
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
