* [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support @ 2022-07-26 7:21 Lulu Cheng 2022-07-26 9:44 ` Xi Ruoyao 2022-07-26 11:32 ` Gerald Pfeifer 0 siblings, 2 replies; 13+ messages in thread From: Lulu Cheng @ 2022-07-26 7:21 UTC (permalink / raw) To: gcc-patches; +Cc: gerald, xuchenghua, Lulu Cheng Hi, Recently we added split symbol support, changed in r13-1834. It is ok for wwwdocs? Thanks! Lulu Cheng --- htdocs/gcc-13/changes.html | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 57bd8724..60399e4e 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -124,6 +124,27 @@ a work-in-progress.</p> <!-- <h3 id="x86">IA-32/x86-64</h3> --> +<h3 id="loongarch">LoongArch</h3> +<ul> + <li>The option <code>-mexplicit-relocs</code> has been added, this indicates + whether the <code>la.*</code> macro instructions will be generated when + loading symbolic addresses. + This feature requires binutils version 2.40 or later. If you want to use the + older version of bintuils, add compiler parameters + <code>-mno-explicit-relocs</code> at compile time. + </li> + <li>The method for calling global functions changed from + <code>la.global + jirl</code> to <code>bl</code> when complied add + <code>-fplt</code>. + </li> + <li>Enable option <code>-fsection-anchors</code> when <code>-O1</code> and + more advanced optimization. + </li> + <li>Changed <code>ASM_PREFERRED_EH_DATA_FORMAT</code> macro definition from + <code>WD_EH_PE_absptr</code> to <code>WD_EH_PE_pcrel | DW_EH_PE_sdata4</code>. + </li> +</ul> + <!-- <h3 id="mips">MIPS</h3> --> <!-- <h3 id="mep">MeP</h3> --> -- 2.31.1 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-26 7:21 [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support Lulu Cheng @ 2022-07-26 9:44 ` Xi Ruoyao 2022-07-26 11:42 ` Lulu Cheng 2022-07-26 11:32 ` Gerald Pfeifer 1 sibling, 1 reply; 13+ messages in thread From: Xi Ruoyao @ 2022-07-26 9:44 UTC (permalink / raw) To: Lulu Cheng, gcc-patches; +Cc: xuchenghua, Wang Xuerui +Xuerui (his English is much better than mine). On Tue, 2022-07-26 at 15:21 +0800, Lulu Cheng wrote: > Hi, > Recently we added split symbol support, changed in r13-1834. > It is ok for wwwdocs? > +<h3 id="loongarch">LoongArch</h3> > +<ul> > + <li>The option <code>-mexplicit-relocs</code> has been added, this indicate I think "added and enabled by default" would be better. > + whether the <code>la.*</code> macro instructions will be generated when > + loading symbolic addresses. > + This feature requires binutils version 2.40 or later. If you want to use the > + older version of bintuils, add compiler parameters > + <code>-mno-explicit-relocs</code> at compile time. Does it mean we need to make sure GCC 13 released after binutils-2.40? binutils-2.39 release branch is already created and it's now explicitly "no new feature" so a backport seems impossible... > + </li> > + <li>The method for calling global functions changed from > + <code>la.global + jirl</code> to <code>bl</code> when complied add > + <code>-fplt</code>. "from la.global + jirl to bl with -fno-plt and -mexplicit-relocs"? With "-fplt" GCC 12 is already using bl, and with -mno-explicit-relocs la.global is still used (if I read func-call-3.c correctly). > + <li>Enable option <code>-fsection-anchors</code> when <code>-O1</code> and > + more advanced optimization. "-fsection-anchors is enabled by default at <code>-O1</code> and higher optimization levels for better code generation". > + <li>Changed <code>ASM_PREFERRED_EH_DATA_FORMAT</code> macro definition from > + <code>WD_EH_PE_absptr</code> to <code>WD_EH_PE_pcrel | DW_EH_PE_sdata4</code>. > + </li> I don't think this paragraph is necessary because this change is purely internal. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-26 9:44 ` Xi Ruoyao @ 2022-07-26 11:42 ` Lulu Cheng 2022-07-26 12:01 ` Xi Ruoyao 0 siblings, 1 reply; 13+ messages in thread From: Lulu Cheng @ 2022-07-26 11:42 UTC (permalink / raw) To: Xi Ruoyao, gcc-patches; +Cc: xuchenghua, Wang Xuerui 在 2022/7/26 下午5:44, Xi Ruoyao 写道: > >> + whether the <code>la.*</code> macro instructions will be generated when >> + loading symbolic addresses. >> + This feature requires binutils version 2.40 or later. If you want to use the >> + older version of bintuils, add compiler parameters >> + <code>-mno-explicit-relocs</code> at compile time. > Does it mean we need to make sure GCC 13 released after binutils-2.40? > binutils-2.39 release branch is already created and it's now explicitly > "no new feature" so a backport seems impossible... Do you think it's okay if we don't write Binutils version restrictions now and wait until Binutils code is released to annotate? >> + </li> >> + <li>The method for calling global functions changed from >> + <code>la.global + jirl</code> to <code>bl</code> when complied add >> + <code>-fplt</code>. > "from la.global + jirl to bl with -fno-plt and -mexplicit-relocs"? With > "-fplt" GCC 12 is already using bl, and with -mno-explicit-relocs > la.global is still used (if I read func-call-3.c correctly). I should put '-fplt -mexplicit-relocs' here. >> + <li>Changed <code>ASM_PREFERRED_EH_DATA_FORMAT</code> macro definition from >> + <code>WD_EH_PE_absptr</code> to <code>WD_EH_PE_pcrel | DW_EH_PE_sdata4</code>. >> + </li> > I don't think this paragraph is necessary because this change is purely > internal. > Should we indicate that our .eh_frame section format has changed? Thanks! ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-26 11:42 ` Lulu Cheng @ 2022-07-26 12:01 ` Xi Ruoyao 2022-07-26 13:26 ` Lulu Cheng 2022-07-28 2:59 ` [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support Lulu Cheng 0 siblings, 2 replies; 13+ messages in thread From: Xi Ruoyao @ 2022-07-26 12:01 UTC (permalink / raw) To: Lulu Cheng, gcc-patches; +Cc: xuchenghua, Wang Xuerui On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote: > 在 2022/7/26 下午5:44, Xi Ruoyao 写道: > > > > > + whether the <code>la.*</code> macro instructions will be generated when > > > + loading symbolic addresses. > > > + This feature requires binutils version 2.40 or later. If you want to use the > > > + older version of bintuils, add compiler parameters > > > + <code>-mno-explicit-relocs</code> at compile time. > > Does it mean we need to make sure GCC 13 released after binutils-2.40? > > binutils-2.39 release branch is already created and it's now explicitly > > "no new feature" so a backport seems impossible... > > Do you think it's okay if we don't write Binutils version restrictions > now and wait until Binutils code is released to annotate? I think you can just put Binutils 2.40 here. GCC 13 will be released in Apr or May 2023, and Binutils-2.40 will be released in Jan or Feb 2023 (if no bad thing happens), so my previous concern is actually not a problem. Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs? > > Should we indicate that our .eh_frame section format has changed? I don't really understand C++ exception handling, so: does the change breaks something? For example, if foo links to libbar, libbar is built with GCC 12 (or vice versa), would an exception thrown from libbar properly caught by foo? Generally changes.html is for compiler users (instead of developers), and I believe at least 90% of users (including I) don't know the potential consequences from a .eh_frame format change. So it's better to describe the breakage and possible workaround here. If nothing will be broken, we can just skip the change in changes.html. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-26 12:01 ` Xi Ruoyao @ 2022-07-26 13:26 ` Lulu Cheng 2022-07-26 14:15 ` [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature Xi Ruoyao 2022-07-28 2:59 ` [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support Lulu Cheng 1 sibling, 1 reply; 13+ messages in thread From: Lulu Cheng @ 2022-07-26 13:26 UTC (permalink / raw) To: Xi Ruoyao, gcc-patches; +Cc: xuchenghua, Wang Xuerui 在 2022/7/26 下午8:01, Xi Ruoyao 写道: > On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote: > >> 在 2022/7/26 下午5:44, Xi Ruoyao 写道: >>>> + whether the <code>la.*</code> macro instructions will be generated when >>>> + loading symbolic addresses. >>>> + This feature requires binutils version 2.40 or later. If you want to use the >>>> + older version of bintuils, add compiler parameters >>>> + <code>-mno-explicit-relocs</code> at compile time. >>> Does it mean we need to make sure GCC 13 released after binutils-2.40? >>> binutils-2.39 release branch is already created and it's now explicitly >>> "no new feature" so a backport seems impossible... >> Do you think it's okay if we don't write Binutils version restrictions >> now and wait until Binutils code is released to annotate? > I think you can just put Binutils 2.40 here. GCC 13 will be released in > Apr or May 2023, and Binutils-2.40 will be released in Jan or Feb 2023 > (if no bad thing happens), so my previous concern is actually not a > problem. > > Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld > supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs? I think this is a good way, I'll look at adding a check. >> Should we indicate that our .eh_frame section format has changed? > I don't really understand C++ exception handling, so: does the change > breaks something? For example, if foo links to libbar, libbar is built > with GCC 12 (or vice versa), would an exception thrown from libbar > properly caught by foo? > > Generally changes.html is for compiler users (instead of developers), > and I believe at least 90% of users (including I) don't know the > potential consequences from a .eh_frame format change. So it's better > to describe the breakage and possible workaround here. If nothing will > be broken, we can just skip the change in changes.html. > > I'm looking to see if I can find a test that can verify the compatibility or incompatibility before and after the modification. Thanks!:-) ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature 2022-07-26 13:26 ` Lulu Cheng @ 2022-07-26 14:15 ` Xi Ruoyao 2022-07-27 1:34 ` Lulu Cheng 0 siblings, 1 reply; 13+ messages in thread From: Xi Ruoyao @ 2022-07-26 14:15 UTC (permalink / raw) To: Lulu Cheng, gcc-patches; +Cc: xuchenghua, Wang Xuerui > > Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld > > supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs? > I think this is a good way, I'll look at adding a check. The following should work. I've tested it locally by building GCC with both old (2.38 with patch) and new (trunk) Binutils. Ok for trunk? I simply checked as instead of ld. If as supports explicitly relocations, the produced .o file won't be supported by an old ld even if we use -mno-explicit-relocs (because as will generate new relocation types for la.local etc). So such a mismatch between as and ld can be considered "completely broken" and we don't need to support it. And, the Alpha port also check the assembler for the default of -mexplicit- relocs. This should be documented in invoke.texi, but currently it does not mention -mexplicit-relocs for LoongArch at all. So I'll submit the doclater in another patch. -- >8 -- The assembly produced with -mexplicit-relocs is not supported by gas <= 2.39. Check if the assembler supports explicit relocations and set the default accordingly. gcc/ChangeLog: * configure.ac (HAVE_AS_EXPLICIT_RELOCS): Define to 1 if the assembler supports explicit relocation for LoongArch. * configure: Regenerate. * config/loongarch/loongarch-opts.h (HAVE_AS_EXPLICIT_RELOCS): Define to 0 if not defined. * config/loongarch/genopts/loongarch.opt.in (TARGET_EXPLICIT_RELOCS): Default to HAVE_AS_EXPLICIT_RELOCS. * config/loongarch/loongarch.opt: Regenerate. --- gcc/config/loongarch/genopts/loongarch.opt.in | 2 +- gcc/config/loongarch/loongarch-opts.h | 4 ++ gcc/config/loongarch/loongarch.opt | 2 +- gcc/configure | 37 +++++++++++++++++-- gcc/configure.ac | 7 +++- 5 files changed, 46 insertions(+), 6 deletions(-) diff --git a/gcc/config/loongarch/genopts/loongarch.opt.in b/gcc/config/loongarch/genopts/loongarch.opt.in index 6f39500935d..a571b6b7524 100644 --- a/gcc/config/loongarch/genopts/loongarch.opt.in +++ b/gcc/config/loongarch/genopts/loongarch.opt.in @@ -155,7 +155,7 @@ Target Joined RejectNegative UInteger Var(loongarch_max_inline_memcpy_size) Init -mmax-inline-memcpy-size=SIZE Set the max size of memcpy to inline, default is 1024. mexplicit-relocs -Target Var(TARGET_EXPLICIT_RELOCS) Init(1) +Target Var(TARGET_EXPLICIT_RELOCS) Init(HAVE_AS_EXPLICIT_RELOCS) Use %reloc() assembly operators. ; The code model option names for -mcmodel. diff --git a/gcc/config/loongarch/loongarch-opts.h b/gcc/config/loongarch/loongarch-opts.h index eaa6fc07448..da24ecd2b50 100644 --- a/gcc/config/loongarch/loongarch-opts.h +++ b/gcc/config/loongarch/loongarch-opts.h @@ -87,4 +87,8 @@ loongarch_config_target (struct loongarch_target *target, while -m[no]-memcpy imposes a global constraint. */ #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P loongarch_do_optimize_block_move_p() +#ifndef HAVE_AS_EXPLICIT_RELOCS +#define HAVE_AS_EXPLICIT_RELOCS 0 +#endif + #endif /* LOONGARCH_OPTS_H */ diff --git a/gcc/config/loongarch/loongarch.opt b/gcc/config/loongarch/loongarch.opt index 7a8c5b44418..9df7e187283 100644 --- a/gcc/config/loongarch/loongarch.opt +++ b/gcc/config/loongarch/loongarch.opt @@ -162,7 +162,7 @@ Target Joined RejectNegative UInteger Var(loongarch_max_inline_memcpy_size) Init -mmax-inline-memcpy-size=SIZE Set the max size of memcpy to inline, default is 1024. mexplicit-relocs -Target Var(TARGET_EXPLICIT_RELOCS) Init(1) +Target Var(TARGET_EXPLICIT_RELOCS) Init(HAVE_AS_EXPLICIT_RELOCS) Use %reloc() assembly operators. ; The code model option names for -mcmodel. diff --git a/gcc/configure b/gcc/configure index 62872d132ea..7eb9479ae8e 100755 --- a/gcc/configure +++ b/gcc/configure @@ -19674,7 +19674,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 19679 "configure" +#line 19677 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -19780,7 +19780,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 19785 "configure" +#line 19783 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -28771,7 +28771,7 @@ $as_echo "#define HAVE_AS_MARCH_ZIFENCEI 1" >>confdefs.h fi ;; - loongarch*-*-*) + loongarch*-*-*) { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for .dtprelword support" >&5 $as_echo_n "checking assembler for .dtprelword support... " >&6; } if ${gcc_cv_as_loongarch_dtprelword+:} false; then : @@ -28807,6 +28807,37 @@ if test $gcc_cv_as_loongarch_dtprelword != yes; then $as_echo "#define HAVE_AS_DTPRELWORD 1" >>confdefs.h fi + { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for explicit relocation support" >&5 +$as_echo_n "checking assembler for explicit relocation support... " >&6; } +if ${gcc_cv_as_loongarch_explicit_relocs+:} false; then : + $as_echo_n "(cached) " >&6 +else + gcc_cv_as_loongarch_explicit_relocs=no + if test x$gcc_cv_as != x; then + $as_echo 'a:pcalau12i $t0,%pc_hi20(a)' > conftest.s + if { ac_try='$gcc_cv_as $gcc_cv_as_flags -o conftest.o conftest.s >&5' + { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5 + (eval $ac_try) 2>&5 + ac_status=$? + $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5 + test $ac_status = 0; }; } + then + gcc_cv_as_loongarch_explicit_relocs=yes + else + echo "configure: failed program was" >&5 + cat conftest.s >&5 + fi + rm -f conftest.o conftest.s + fi +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_as_loongarch_explicit_relocs" >&5 +$as_echo "$gcc_cv_as_loongarch_explicit_relocs" >&6; } +if test $gcc_cv_as_loongarch_explicit_relocs = yes; then + +$as_echo "#define HAVE_AS_EXPLICIT_RELOCS 1" >>confdefs.h + +fi + ;; s390*-*-*) { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for .gnu_attribute support" >&5 diff --git a/gcc/configure.ac b/gcc/configure.ac index 446747311a6..e5f708c6b38 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -5287,7 +5287,7 @@ configured with --enable-newlib-nano-formatted-io.]) [AC_DEFINE(HAVE_AS_MARCH_ZIFENCEI, 1, [Define if the assembler understands -march=rv*_zifencei.])]) ;; - loongarch*-*-*) + loongarch*-*-*) gcc_GAS_CHECK_FEATURE([.dtprelword support], gcc_cv_as_loongarch_dtprelword, [2,18,0],, [.section .tdata,"awT",@progbits @@ -5297,6 +5297,11 @@ x: .dtprelword x+0x8000],, [AC_DEFINE(HAVE_AS_DTPRELWORD, 1, [Define if your assembler supports .dtprelword.])]) + gcc_GAS_CHECK_FEATURE([explicit relocation support], + gcc_cv_as_loongarch_explicit_relocs,, + [a:pcalau12i $t0,%pc_hi20(a)],, + [AC_DEFINE(HAVE_AS_EXPLICIT_RELOCS, 1, + [Define if your assembler supports explicit relocation.])]) ;; s390*-*-*) gcc_GAS_CHECK_FEATURE([.gnu_attribute support], -- 2.37.1 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature 2022-07-26 14:15 ` [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature Xi Ruoyao @ 2022-07-27 1:34 ` Lulu Cheng 2022-07-27 2:22 ` Xi Ruoyao 0 siblings, 1 reply; 13+ messages in thread From: Lulu Cheng @ 2022-07-27 1:34 UTC (permalink / raw) To: Xi Ruoyao, gcc-patches; +Cc: xuchenghua, Wang Xuerui 在 2022/7/26 下午10:15, Xi Ruoyao 写道: > > The following should work. I've tested it locally by building GCC with > both old (2.38 with patch) and new (trunk) Binutils. Ok for trunk? > > I simply checked as instead of ld. If as supports explicitly > relocations, the produced .o file won't be supported by an old ld even > if we use -mno-explicit-relocs (because as will generate new relocation > types for la.local etc). So such a mismatch between as and ld can be > considered "completely broken" and we don't need to support it. And, > the Alpha port also check the assembler for the default of -mexplicit- > relocs. > > This should be documented in invoke.texi, but currently it does not > mention -mexplicit-relocs for LoongArch at all. So I'll submit the > doclater in another patch. > > -- >8 -- > > The assembly produced with -mexplicit-relocs is not supported by gas <= > 2.39. Check if the assembler supports explicit relocations and set the > default accordingly. Looks good to me. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature 2022-07-27 1:34 ` Lulu Cheng @ 2022-07-27 2:22 ` Xi Ruoyao 0 siblings, 0 replies; 13+ messages in thread From: Xi Ruoyao @ 2022-07-27 2:22 UTC (permalink / raw) To: Lulu Cheng, gcc-patches; +Cc: xuchenghua, Wang Xuerui On Wed, 2022-07-27 at 09:34 +0800, Lulu Cheng wrote: > > -- >8 -- > > > > The assembly produced with -mexplicit-relocs is not supported by gas > > <= > > 2.39. Check if the assembler supports explicit relocations and set > > the > > default accordingly. > Looks good to me. Pushed r13-1851. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-26 12:01 ` Xi Ruoyao 2022-07-26 13:26 ` Lulu Cheng @ 2022-07-28 2:59 ` Lulu Cheng 2022-07-28 10:41 ` Xi Ruoyao 1 sibling, 1 reply; 13+ messages in thread From: Lulu Cheng @ 2022-07-28 2:59 UTC (permalink / raw) To: Xi Ruoyao, gcc-patches; +Cc: xuchenghua, Wang Xuerui 在 2022/7/26 下午8:01, Xi Ruoyao 写道: > On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote: > >> 在 2022/7/26 下午5:44, Xi Ruoyao 写道: >>> Should we indicate that our .eh_frame section format has changed? > I don't really understand C++ exception handling, so: does the change > breaks something? For example, if foo links to libbar, libbar is built > with GCC 12 (or vice versa), would an exception thrown from libbar > properly caught by foo? > > Generally changes.html is for compiler users (instead of developers), > and I believe at least 90% of users (including I) don't know the > potential consequences from a .eh_frame format change. So it's better > to describe the breakage and possible workaround here. If nothing will > be broken, we can just skip the change in changes.html. > > The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification is as follows: #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \ - (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr) + (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4) Use the following tests to describe the effect of modifying this macro on the generated assembly code： #include <iostream> #include <exception> using namespace std; int main() { try { throw 1; } catch (int i) { cout << i << endl; } } The main comparisons related to the eh_frame section are as follows： OLD NEW .LFB1997 = . | .LFB1780 = . .cfi_startproc | .cfi_startproc .cfi_personality 0x80,DW.ref.__gxx_personality_v0 | .cfi_personality 0x9b,DW.ref.__gxx_personality_v0 .cfi_lsda 0,.LLSDA1997 | .cfi_lsda 0x1b,.LLSDA1780 If the assembly file generated by the new gcc is compiled with the binutils of version 2.38, the following error will be reported: test.s:74: Error: invalid or unsupported encoding in .cfi_personality test.s:75: Error: invalid or unsupported encoding in .cfi_lsda So I think I should judge whether binutils supports this encoding when gcc is configured, and then choose how to define macro ASM_PREFERRED_EH_DATA_FORMAT. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-28 2:59 ` [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support Lulu Cheng @ 2022-07-28 10:41 ` Xi Ruoyao 2022-07-28 13:06 ` Lulu Cheng 0 siblings, 1 reply; 13+ messages in thread From: Xi Ruoyao @ 2022-07-28 10:41 UTC (permalink / raw) To: Lulu Cheng, gcc-patches; +Cc: xuchenghua, Wang Xuerui On Thu, 2022-07-28 at 10:59 +0800, Lulu Cheng wrote: > > The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification > > is > as follows: > #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \ > - (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr) > + (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | > DW_EH_PE_sdata4) The master branch still contains: #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \ (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr) Did you forgot to commit this change (or lost it during a rebase)? -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-28 10:41 ` Xi Ruoyao @ 2022-07-28 13:06 ` Lulu Cheng 0 siblings, 0 replies; 13+ messages in thread From: Lulu Cheng @ 2022-07-28 13:06 UTC (permalink / raw) To: Xi Ruoyao, gcc-patches; +Cc: xuchenghua, Wang Xuerui 在 2022/7/28 下午6:41, Xi Ruoyao 写道: > On Thu, 2022-07-28 at 10:59 +0800, Lulu Cheng wrote: > >>> The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification >>> is >> as follows: >> #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \ >> - (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr) >> + (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | >> DW_EH_PE_sdata4) > The master branch still contains: > > #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \ > (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr) > > Did you forgot to commit this change (or lost it during a rebase)? > > Oh,sorry I forgot to commit to upstream. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-26 7:21 [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support Lulu Cheng 2022-07-26 9:44 ` Xi Ruoyao @ 2022-07-26 11:32 ` Gerald Pfeifer 2022-07-26 12:28 ` Lulu Cheng 1 sibling, 1 reply; 13+ messages in thread From: Gerald Pfeifer @ 2022-07-26 11:32 UTC (permalink / raw) To: Lulu Cheng; +Cc: gcc-patches, xuchenghua On Tue, 26 Jul 2022, Lulu Cheng wrote: > +<h3 id="loongarch">LoongArch</h3> > +<ul> > + <li>The option <code>-mexplicit-relocs</code> has been added, this indicates > + whether the <code>la.*</code> macro instructions will be generated when > + loading symbolic addresses. How about making this "...has been added. It indicates..." or, if you prefer one sentence "...has been added to indicate whether"? > + This feature requires binutils version 2.40 or later. If you want to use the > + older version of bintuils, add compiler parameters > + <code>-mno-explicit-relocs</code> at compile time. "...older versions..." (or "...an older version...") And I believe we can simplify and just say "...add <code>-mno-explicit..." > + <li>The method for calling global functions changed from > + <code>la.global + jirl</code> to <code>bl</code> when complied add > + <code>-fplt</code>. Do you mean "compiled" instead of "complied"? And maybe "compiled with"? > + <li>Enable option <code>-fsection-anchors</code> when <code>-O1</code> and > + more advanced optimization. How about "<code>-fsection-anchors</code> is now enabled with <code>-O1</code> and above"? If my suggestions make sense to you, please go ahead and commit with those or variations thereof you may prefer. If you have any questions, please let me know and we'll sort things out quickly. Thank you, Gerald ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support 2022-07-26 11:32 ` Gerald Pfeifer @ 2022-07-26 12:28 ` Lulu Cheng 0 siblings, 0 replies; 13+ messages in thread From: Lulu Cheng @ 2022-07-26 12:28 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: gcc-patches, xuchenghua 在 2022/7/26 下午7:32, Gerald Pfeifer 写道: > On Tue, 26 Jul 2022, Lulu Cheng wrote: >> +<h3 id="loongarch">LoongArch</h3> >> +<ul> >> + <li>The option <code>-mexplicit-relocs</code> has been added, this indicates >> + whether the <code>la.*</code> macro instructions will be generated when >> + loading symbolic addresses. > How about making this "...has been added. It indicates..." or, if you > prefer one sentence "...has been added to indicate whether"? > >> + This feature requires binutils version 2.40 or later. If you want to use the >> + older version of bintuils, add compiler parameters >> + <code>-mno-explicit-relocs</code> at compile time. > "...older versions..." (or "...an older version...") > > And I believe we can simplify and just say "...add <code>-mno-explicit..." > >> + <li>The method for calling global functions changed from >> + <code>la.global + jirl</code> to <code>bl</code> when complied add >> + <code>-fplt</code>. > Do you mean "compiled" instead of "complied"? > > And maybe "compiled with"? > >> + <li>Enable option <code>-fsection-anchors</code> when <code>-O1</code> and >> + more advanced optimization. > How about "<code>-fsection-anchors</code> is now enabled with > <code>-O1</code> and above"? > > > If my suggestions make sense to you, please go ahead and commit with those > or variations thereof you may prefer. > > If you have any questions, please let me know and we'll sort things out > quickly. > > Thank you, > Gerald Thanks a lot, I will fix it soon. Lulu Cheng ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-07-28 13:07 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-26 7:21 [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support Lulu Cheng 2022-07-26 9:44 ` Xi Ruoyao 2022-07-26 11:42 ` Lulu Cheng 2022-07-26 12:01 ` Xi Ruoyao 2022-07-26 13:26 ` Lulu Cheng 2022-07-26 14:15 ` [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature Xi Ruoyao 2022-07-27 1:34 ` Lulu Cheng 2022-07-27 2:22 ` Xi Ruoyao 2022-07-28 2:59 ` [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support Lulu Cheng 2022-07-28 10:41 ` Xi Ruoyao 2022-07-28 13:06 ` Lulu Cheng 2022-07-26 11:32 ` Gerald Pfeifer 2022-07-26 12:28 ` Lulu Cheng
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).