> 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 <ja...@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.
