[PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[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

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Xi Ruoyao]

+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

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[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

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 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!

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[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?

> 
> 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

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 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

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 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!:-)

[PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature

[Xi Ruoyao]

> > 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

Re: [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature

[Lulu Cheng]

在 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.

Re: [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature

[Xi Ruoyao]

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.

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 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.

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[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)?


-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 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.