This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: S/390: Avoid relocations in .eh_frame section
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>, Ulrich Weigand <weigand at immd1 dot informatik dot uni-erlangen dot de>, dje at watson dot ibm dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Nov 2002 17:31:45 -0500
- Subject: Re: S/390: Avoid relocations in .eh_frame section
- References: <200211152232.XAA21759@faui11.informatik.uni-erlangen.de> <20021119222616.GE9962@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Nov 19, 2002 at 02:26:16PM -0800, Richard Henderson wrote:
> On Fri, Nov 15, 2002 at 11:32:34PM +0100, Ulrich Weigand wrote:
> > Is there some way of using an udata4 offset relative to .text
> > or something like that? If not, I guess I'll have to use
> > sdata8 after all ...
>
> Yes, if you've got the right relocation type.
>
> This would be DW_EH_PE_udata4 | DW_EH_PE_textrel, with the
> base address registered with __register_frame_info_bases.
>
> However, to my knowledge only ia64 has the segment-relative
> relocation needed so that the result is relative to the
> _first_ .text section, instead of the .text section of the
> current object file.
Well, there is of course also the possibility to move the work
to the linker optimization, ie. start with DW_EH_PE_sdata8 | DW_EH_PE_pcrel
and if linker sees the shared library or binary is smaller than 2GB,
rewrite it into DW_EH_PE_sdata4 | DW_EH_PE_pcrel.
In fact this would be a IMO good idea for all 64-bit arches.
What I'm just wondering is the 4GB upper limit on shared libs,
does s390x have separate jump (resp. call) forward and backward?
Jakub