public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-1975] Change EH pointer encodings to PC relative on Windows Date: Fri, 2 Jul 2021 08:25:17 +0000 (GMT) [thread overview] Message-ID: <20210702082517.9CB743857823@sourceware.org> (raw) https://gcc.gnu.org/g:496e1d6a1f973b3952a37163441f9149501dfb26 commit r12-1975-g496e1d6a1f973b3952a37163441f9149501dfb26 Author: Eric Botcazou <ebotcazou@adacore.com> Date: Fri Jul 2 10:21:11 2021 +0200 Change EH pointer encodings to PC relative on Windows A big difference between ELF and PE-COFF is that, with the latter, you can build position-independent executables or DLLs without generating PIC; as a matter of fact, flag_pic has historically been forced to 0 for 32-bit: /* Don't allow flag_pic to propagate since gas may produce invalid code otherwise. */ \ do { \ flag_pic = TARGET_64BIT ? 1 : 0; \ } while (0) The reason is that the linker builds a .reloc section that collects the absolute relocations in the generated binary, and the loader uses them to relocate it at load time if need be (e.g. if --dynamicbase is enabled). Up to binutils 2.35, the GNU linker didn't build the .reloc section for executables and defaulted to --enable-auto-image-base for DLLs, which means that DLLs had an essentially unique load address and, therefore, need not be relocated by the loader in most cases. With binutils 2.36 and later, the GNU linker builds a .reloc section for executables (thus making them PIE), --enable-auto-image-base is disabled and --dynamicbase is enabled by default, which means that essentially all the binaries are relocated at load time. This badly breaks the 32-bit compiler configured to use DWARF-2 EH because the loader corrupts the .eh_frame section when processing the relocations contained in the .reloc section. gcc/ * config/i386/i386.c (asm_preferred_eh_data_format): Always use the PIC encodings for PE-COFF targets. Diff: --- gcc/config/i386/i386.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 2fbaae7cd02..cff26909292 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -21930,10 +21930,12 @@ ix86_stack_protect_fail (void) After all, the relocation needed is the same as for the call insn. Whether or not a particular assembler allows us to enter such, I guess we'll have to see. */ + int asm_preferred_eh_data_format (int code, int global) { - if (flag_pic) + /* PE-COFF is effectively always -fPIC because of the .reloc section. */ + if (flag_pic || TARGET_PECOFF) { int type = DW_EH_PE_sdata8; if (!TARGET_64BIT @@ -21942,9 +21944,11 @@ asm_preferred_eh_data_format (int code, int global) type = DW_EH_PE_sdata4; return (global ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | type; } + if (ix86_cmodel == CM_SMALL || (ix86_cmodel == CM_MEDIUM && code)) return DW_EH_PE_udata4; + return DW_EH_PE_absptr; }
reply other threads:[~2021-07-02 8:25 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20210702082517.9CB743857823@sourceware.org \ --to=ebotcazou@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /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: linkBe 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).