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