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: Oleg Endo <oleg dot endo at t-online dot de>
- To: Rich Felker <dalias at libc dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 27 Oct 2015 23:01:39 +0900
- 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>
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...
Cheers,
Oleg