PATCH: Re: ia64 ltoff22x/ldxmov relaxation
H. J. Lu
hjl@lucon.org
Mon Apr 28 20:41:00 GMT 2003
On Mon, Apr 28, 2003 at 10:35:52PM +0200, Andreas Schwab wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
>
> |> On Mon, Apr 28, 2003 at 03:14:16PM +0200, Andreas Schwab wrote:
> |> > "H. J. Lu" <hjl@lucon.org> writes:
> |> >
> |> > |> On Thu, Apr 24, 2003 at 06:09:56PM +0200, Andreas Schwab wrote:
> |> > |> > Richard Henderson <rth@redhat.com> writes:
> |> > |> >
> |> > |> > |> Also misses properly choosing a new gp when jump buffers are added.
> |> > |> > |> Technically this is a potential correctness issue. Failures will
> |> > |> > |> be caught by relocate_section in the form of GPREL22 overflows.
> |> > |> > |> However this should should work well in practice because of the default
> |> > |> > |> 2**61 byte separation of the text and data segments in executables.
> |> > |> > |> In order for this to be fixed, I need a callback from the main ld
> |> > |> > |> relaxation loop at the start of a new round of relaxation.
> |> > |> >
> |> > |> > Unfortunately, this bites with large shared libraries where this text/data
> |> > |> > separation does not exist. For example, we get GPREL22 overflows when
> |> > |> > linking libjava from gcc mainline. I can prepare a test case if you need.
> |> > |> >
> |> > |>
> |> > |> Yes, plase. I am interested in a testcase for that.
> |> >
> |> > You can download it from
> |> > <ftp://ftp.suse.com/pub/people/schwab/libjava-test.tar.bz2>.
> |> > Unfortunately it is quite big, but I couldn't reduce it without the bug
> |> > going away. Unpack the archive and run link-java, you will get these
> |> > errors:
> |> >
> |>
> |> This patch seems to work for me.
>
> Not for me. I did my tests with your patch already applied.
>
Please back it out and apply the new one. They are slightly
different :-).
H.J.
More information about the Binutils
mailing list