This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Stub group default for hppa elf
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: amodra at bigpond dot net dot au (Alan Modra)
- Cc: binutils at sources dot redhat dot com
- Date: Sat, 8 Feb 2003 00:36:06 -0500 (EST)
- Subject: Re: Stub group default for hppa elf
> Sort of. We don't try to put stubs in any particular order. They're
> as they come out of a hash table traversal. So a stub serving group B
> may indeed appear near the start of the stubs, which is obviously a
> bad choice. I thought about sorting the stubs but decided it wasn't
> worth it, especially as some stubs might serve both group A and B
> (I suppose they should go in the middle). Incidentally, stub sharing
> is the reason why it's a good idea to maximize the amount of code
> served by a stub section, and why I'd recommend the default go back to
> -1.
Thanks for explaining how this works.
The thing that's bothering me about this is the gcc branch transition
limit is set at 240000 bytes. At that point, branches that can't
reach the beginning of the current translation unit or function, as
the case may be, get output as long branches and they don't need
long branch stubs. I think changing the stub group size without
changing the gcc value will leave a gap where a branch won't get
a stub. I also need to rethink how this process works if we are
going to collect both forward and backward branches. Changing
this in 3.3 and the main should be straight forward. However,
in 3.2, this length is encoded into many different locations in
attribute rtl in the machine definition and it would be hard
to implement a forward and backward approach (hpux is only
backward, 64-bit version of gnu ld has only one stub group
which is a problem for sibcalls).
I can see dropping the gcc limit to make it agree with the ld value
if we do both forward and backward branches. That would nearly
double the size of code which can use short branches. Possibly,
the stub group default could be set by gcc. 3.3 and later could
set the mode to forward and backward.
There are also stub group issues with "ld -r".
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)