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

  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(+)
  

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

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
  

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

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.
  

在 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
  

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

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

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

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