This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v4] SH FDPIC backend support
- From: Rich Felker <dalias at libc dot org>
- To: Oleg Endo <oleg dot endo at t-online dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 10 Nov 2015 15:07:00 -0500
- Subject: Re: [PATCH v4] SH FDPIC backend support
- Authentication-results: sourceware.org; auth=none
- References: <20151021034138 dot GA4087 at brightrain dot aerifal dot cx> <1445433471 dot 5521 dot 100 dot camel at t-online dot de> <20151021201510 dot GV8645 at brightrain dot aerifal dot cx> <20151023063221 dot GI8645 at brightrain dot aerifal dot cx> <1445783331 dot 8060 dot 3 dot camel at t-online dot de> <20151027024706 dot GU8645 at brightrain dot aerifal dot cx> <1445954499 dot 8060 dot 22 dot camel at t-online dot de>
On Tue, Oct 27, 2015 at 11:01:39PM +0900, Oleg Endo wrote:
> On Mon, 2015-10-26 at 22:47 -0400, Rich Felker wrote:
> > On Sun, Oct 25, 2015 at 11:28:51PM +0900, Oleg Endo wrote:
> > > On Fri, 2015-10-23 at 02:32 -0400, Rich Felker wrote:
> > > > Here's my updated version of the FDPIC patch with all requested
> > > > changes made and Changelog added. I've included all the original
> > > > authors. This is my first time writing such an extensive
> > > > Changelog
> > > > entry so please let me know if there are things I got wrong.
> > >
> > > I took the liberty and fixed some minor formatting trivia and
> > > extracted
> > > functions sh_emit_storesi and sh_emit_storehi which are used in
> > > sh_trampoline_init to effectively memcpy code into the trampoline
> > > area. Can you please check it? If it's OK I'll commit the
> > > attached
> > > patch to trunk.
> >
> > Is there anything in particular you'd like me to check? It builds
> > fine
> > for fdpic target, successfully compiles musl libc.so, and busybox
> > runs
> > with the resulting libc.so. I did a quick visual inspection of the
> > diff between my version and yours too and didn't see anything that
> > looked suspicious to me.
>
> Thanks. I have committed it as r229438 after a sanity check with "make
> all" on sh-elf.
>
> The way libcalls are now emitted is a bit unhandy. If more special-ABI
> libcalls are to be added in the future, they all have to do the jsr vs.
> bsrf handling (some potential candidates for new libcalls are optimized
> soft FP routines). Then we still have PR 65374 and PR 54019. In the
> future maybe we should come up with something that allows emitting
> libcalls in a more transparent way...
I'd like to look into improving this at some point in the near future.
On further reading of the changes made, I think there's a lot of code
we could reduce or simplify.
In all the places where new RTL patterns were added for *call*_fdpic,
the main constraint change vs the non-fdpic version is using REG_PIC.
Is it possible to make a REG_GOT_ARG macro or similar that's defined
as something like TARGET_FDPIC ? REG_PIC : nonexistent_or_dummy?
As for the call site stuff, I wonder why the existing call site stuff
used by "call_pcrel" can't be used for SFUNC_STATIC. I'm actually
trying to prepare a simpler FDPIC patch for other gcc versions we're
interested in that's not so invasive, and for now I'm just having
function_symbol replace SFUNC_STATIC with SFUNC_GOT on TARGET_FDPIC to
avoid needing all the label stuff, but it would be nice to find a way
to reuse the existing framework.
Rich