public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Richard Sandiford <Richard.Sandiford@arm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>,
	"maskray@google.com" <maskray@google.com>
Subject: Re: [PATCH] AArch64: Add support for -mdirect-extern-access
Date: Thu, 17 Nov 2022 16:42:01 +0000	[thread overview]
Message-ID: <PAWPR08MB8982319C22A5DDF880268C6C83069@PAWPR08MB8982.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <mptedu3goef.fsf@arm.com>

Hi Richard,

> Can you go into more detail about:
>
>    Use :option:`-mdirect-extern-access` either in shared libraries or in
>    executables, but not in both.  Protected symbols used both in a shared
>    library and executable may cause linker errors or fail to work correctly
>
> If this is LLVM's default for PIC (and by assumption shared libraries),
> is it then invalid to use -mdirect-extern-access for any PIEs that
> are linked against those shared libraries and use protected symbols
> from those libraries?  How would a user know that one of the shared
> libraries they're linking against was built in this way?

Yes, the usage model is that you'd either use it for static PIE or only on
data that is not shared. If you get it wrong them you'll get the copy
relocation error. In the future we need to decide what the ABI is and
ensure GCC and LLVM are compatible. An import feature to mark symbols
that may be overridden by a shared library would be useful too.

> It looks like the main difference between this implementation and
> the x86 one is that x86 allows direct accesses to common symbols.
> What's the reason for not doing that for AArch64?  Does it not work,
> is it a false optimisation (i.e. pessimisation), or did it not seem
> important now that -fno-common is the default?

I don't see any difference in the way common symbols are accessed on x86,
so it's not clear which cases common_local_p param actually affects (eg. with
-fPIC there is always a GOT indirection for common symbols).

Cheers,
Wilco

  reply	other threads:[~2022-11-17 16:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 14:48 Wilco Dijkstra
2022-11-16 10:54 ` Richard Sandiford
2022-11-17 16:42   ` Wilco Dijkstra [this message]
2022-11-17 17:30     ` Richard Sandiford
2022-11-17 20:52       ` Ramana Radhakrishnan
2022-11-17 21:20         ` maskray
2022-11-17 21:37           ` Andrew Pinski
2022-11-17 21:46             ` Fangrui Song
2022-11-17 21:55               ` Andrew Pinski
2022-11-17 22:07                 ` Fangrui Song

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=PAWPR08MB8982319C22A5DDF880268C6C83069@PAWPR08MB8982.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=Kyrylo.Tkachov@arm.com \
    --cc=Richard.Sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=maskray@google.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).