From: Rich Felker <dalias@libc.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Reviving SH FDPIC target
Date: Fri, 11 Sep 2015 08:02:00 -0000 [thread overview]
Message-ID: <20150911040547.GT17773@brightrain.aerifal.cx> (raw)
In-Reply-To: <20150911034919.GS17773@brightrain.aerifal.cx>
On Thu, Sep 10, 2015 at 11:49:19PM -0400, Rich Felker wrote:
> 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.
Well, that was easier than I thought, at least for a quick hack: I
added:
SYMBOL_REF_EXTERNAL_P(orig) || DECL_SECTION_NAME(SYMBOL_REF_DECL(orig))
to the list of conditions for using @GOT instead of @GOTOFF. This may
actually be optimal under the constraints we have...
Rich
prev parent reply other threads:[~2015-09-11 4:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 18:36 Rich Felker
2015-09-02 20:00 ` Joseph Myers
2015-09-02 21:14 ` Rich Felker
2015-09-03 4:33 ` Rich Felker
2015-09-03 14:59 ` Joseph Myers
2015-09-03 15:59 ` Rich Felker
2015-09-04 20:22 ` Rich Felker
2015-09-04 23:08 ` Segher Boessenkool
2015-09-05 12:37 ` Rich Felker
2015-09-13 17:11 ` Rich Felker
2015-09-11 4:05 ` Rich Felker
2015-09-11 8:02 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150911040547.GT17773@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).