From: Fangrui Song <maskray@google.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] x86: Use DW_EH_PE_indirect|DW_EH_PE_pcrel encodings for -fno-pic code
Date: Wed, 1 Feb 2023 21:50:17 -0800 [thread overview]
Message-ID: <CAFP8O3JJUAVyMSS9JMsNQdpWhRS0MPoWOppfERN2vpLFCZtiNw@mail.gmail.com> (raw)
In-Reply-To: <Y9osNajNemfznjua@tucnak>
> The above is incorrectly formatted, the GCC Coding Conventions
say || etc. shouldn't be at the end of lines, but rather at the
start of the next ones.
Ack.
> And, while I can understand the rationale for global cases
> (though am not sure I agree, as currently the user can choose
> by using -mno-direct-extern-access or not using it, the above change
> disallows the choice), for !global I miss the point altogether.
> In non-PIC (and non-PECOFF maybe, don't know that format well)
> code if code references a local symbol, it will never generate
> a copy relocation and so DW_EH_PE_udata4 could be just fine and cheaper
> to handle on the consumer sides.
On Wed, Feb 1, 2023 at 1:09 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Wed, Feb 01, 2023 at 10:01:36AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > And, while I can understand the rationale for global cases
> > (though am not sure I agree, as currently the user can choose
> > by using -mno-direct-extern-access or not using it, the above change
> > disallows the choice), for !global I miss the point altogether.
> > In non-PIC (and non-PECOFF maybe, don't know that format well)
> > code if code references a local symbol, it will never generate
> > a copy relocation and so DW_EH_PE_udata4 could be just fine and cheaper
> > to handle on the consumer sides.
>
> Plus, e.g. for the typeinfo references, if using the default
> -mdirect-extern-access and RTTI is used, there will be copy relocations
> anyway and so the .eh_frame growth will be just waste of .got space.
>
> Jakub
>
There is a copy relocation but the canonical PLT entry for
__gxx_personality_v0 can be removed.
-fno-pic C++ exception code is less common nowadays, so there seems little value
to keep a complex condition (if (flag_pic || TARGET_PECOFF ||
!ix86_direct_extern_access)) to
optimize a bit for the object file size (I think you mean .data space
instead of .got space).
The .eh_frame growth is nearly negligible as well.
prev parent reply other threads:[~2023-02-02 5:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 7:38 Fangrui Song
2023-02-01 9:01 ` Jakub Jelinek
2023-02-01 9:09 ` Jakub Jelinek
2023-02-02 5:50 ` Fangrui Song [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=CAFP8O3JJUAVyMSS9JMsNQdpWhRS0MPoWOppfERN2vpLFCZtiNw@mail.gmail.com \
--to=maskray@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.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).