Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support
在 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.
Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support
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 School of Aerospace Science and Technology, Xidian University
Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support
在 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 #include
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
在 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 la.* 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 + -mno-explicit-relocs 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!:-)
Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support
在 2022/7/26 下午7:32, Gerald Pfeifer 写道: On Tue, 26 Jul 2022, Lulu Cheng wrote: +LoongArch + + The option -mexplicit-relocs has been added, this indicates + whether the la.* 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 + -mno-explicit-relocs at compile time. "...older versions..." (or "...an older version...") And I believe we can simplify and just say "...add -mno-explicit..." + The method for calling global functions changed from + la.global + jirl to bl when complied add + -fplt. Do you mean "compiled" instead of "complied"? And maybe "compiled with"? + Enable option -fsection-anchors when -O1 and + more advanced optimization. How about "-fsection-anchors is now enabled with -O1 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
On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote: > 在 2022/7/26 下午5:44, Xi Ruoyao 写道: > > > > > + whether the la.* 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 > > > + -mno-explicit-relocs 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 School of Aerospace Science and Technology, Xidian University
Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support
在 2022/7/26 下午5:44, Xi Ruoyao 写道: + whether the la.* 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 + -mno-explicit-relocs 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? + + The method for calling global functions changed from + la.global + jirl to bl when complied add + -fplt. "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. + Changed ASM_PREFERRED_EH_DATA_FORMAT macro definition from + WD_EH_PE_absptr to WD_EH_PE_pcrel | DW_EH_PE_sdata4. + 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
On Tue, 26 Jul 2022, Lulu Cheng wrote: > +LoongArch > + > + The option -mexplicit-relocs has been added, this > indicates > + whether the la.* 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 > + -mno-explicit-relocs at compile time. "...older versions..." (or "...an older version...") And I believe we can simplify and just say "...add -mno-explicit..." > + The method for calling global functions changed from > + la.global + jirl to bl when complied add > + -fplt. Do you mean "compiled" instead of "complied"? And maybe "compiled with"? > + Enable option -fsection-anchors when -O1 and > + more advanced optimization. How about "-fsection-anchors is now enabled with -O1 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
+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? > +LoongArch > + > + The option -mexplicit-relocs has been added, this indicate I think "added and enabled by default" would be better. > + whether the la.* 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 > + -mno-explicit-relocs 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... > + > + The method for calling global functions changed from > + la.global + jirl to bl when complied add > + -fplt. "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). > + Enable option -fsection-anchors when -O1 and > + more advanced optimization. "-fsection-anchors is enabled by default at -O1 and higher optimization levels for better code generation". > + Changed ASM_PREFERRED_EH_DATA_FORMAT macro definition from > + WD_EH_PE_absptr to WD_EH_PE_pcrel | > DW_EH_PE_sdata4. > + I don't think this paragraph is necessary because this change is purely internal. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
[PATCH][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(+) 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. +LoongArch + + The option -mexplicit-relocs has been added, this indicates + whether the la.* 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 + -mno-explicit-relocs at compile time. + + The method for calling global functions changed from + la.global + jirl to bl when complied add + -fplt. + + Enable option -fsection-anchors when -O1 and + more advanced optimization. + + Changed ASM_PREFERRED_EH_DATA_FORMAT macro definition from + WD_EH_PE_absptr to WD_EH_PE_pcrel | DW_EH_PE_sdata4. + + + -- 2.31.1
