This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reviving SH FDPIC target
- From: Rich Felker <dalias at libc dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 10 Sep 2015 23:49:19 -0400
- Subject: Re: Reviving SH FDPIC target
- Authentication-results: sourceware.org; auth=none
- References: <20150902183650 dot GA16052 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1509021957560 dot 30448 at digraph dot polyomino dot org dot uk> <20150902210535 dot GM17773 at brightrain dot aerifal dot cx> <20150903005101 dot GN17773 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1509031457510 dot 13579 at digraph dot polyomino dot org dot uk> <20150903155345 dot GQ17773 at brightrain dot aerifal dot cx> <20150904201640 dot GU17773 at brightrain dot aerifal dot cx>
On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote:
> On Thu, Sep 03, 2015 at 11:53:45AM -0400, Rich Felker wrote:
> > On Thu, Sep 03, 2015 at 02:58:39PM +0000, Joseph Myers wrote:
> > > On Wed, 2 Sep 2015, Rich Felker wrote:
> > >
> > > > So if __fpscr_values was the only reason for patch 1/3 in the FDPIC
> > > > patchset, I think we can safely drop it. And patch 2/3 was already
> > > > committed, so 3/3, the one I was originally looking at, seems to be
> > > > all we need. It was approved at the time, so I'll proceed with merging
> > > > it with 5.2.0.
> > >
> > > Well, obviously if trying dropping patch 1/3 you need to remove everything
> > > related to use_initial_val (the feature added in patch 1/3) from patch
> > > 3/3.
> >
> > As far as I can tell, the only "use" of use_initial_val is defining
> > the pseudo-instruction in the md file, which causes the code in patch
> > 1/3 to use it. I see no other references to it. As I understand, the
> > breakage from not having it (in the original 4.5-era patch) would be
> > when introducing references to __fpscr_values later, and no longer
> > having the GOT pointer, but that code is gone now.
>
> I have this basically working -- obviously no heavy testing yet, and
> the specs glue is not sufficient to make it practical for others to
> try it yet, so it'll be a little longer til I have something to post.
I'm running into a problem with crtstuff.c: the references to
__TMC_END__, etc. end up using @GOTOFF relocations which the linker
then rejects. Is this a linker bug or something I need to fix in the
target code to avoid generating @GOTOFF relocations? Since crtbegin.o
has no information about what section __TMC_END__ will be in when it's
defined, I don't see a lot of options except to avoid using @GOTOFF
entirely for symbols that aren't defined in the same TU.
Rich