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

[Xi Ruoyao <xry111@xry111.site>]

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