Re: PATCH: Re: ia64 ltoff22x/ldxmov relaxation

[Andreas Schwab <schwab at suse dot de>]

"H. J. Lu" <hjl at lucon dot org> writes:

|> On Mon, Apr 28, 2003 at 03:14:16PM +0200, Andreas Schwab wrote:
|> > "H. J. Lu" <hjl at lucon dot org> writes:
|> > 
|> > |> On Thu, Apr 24, 2003 at 06:09:56PM +0200, Andreas Schwab wrote:
|> > |> > Richard Henderson <rth at redhat dot 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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab at suse dot de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."