Re: [PATCH v2 0/5] loongarch: add relaxation support

[Daniel Kiper]

On Mon, Jun 12, 2023 at 04:20:41PM +0800, Xi Ruoyao via Grub-devel wrote:
> On Mon, 2023-06-12 at 14:54 +0800, WANG Xuerui wrote:
> > On 6/12/23 11:09, Xiaotian Wu wrote:
> > > 在 2023-06-12星期一的 06:35 +0800，Xi Ruoyao via Grub-devel写道：
> > > > On Wed, 2023-06-07 at 15:34 +0800, Xiaotian Wu wrote:
> > > > > Because the binutils of the loongarch architecture adds relaxation
> > > > > support [1], the next version of binutils will not be able to build
> > > > > grub.
> > > > >
> > > > > So we added the R_LARCH_B16, R_LARCH_B21 and R_LARCH_RELAX
> > > > > relocations
> > > > > to enhance grub compatibility.
> > > > Wouldn't it be easier to just pass -mno-relax to the toolchain when
> > > > we
> > > > build GRUB?  I don't think it makes too much sense to perform
> > > > relaxation
> > > > on a boot loader.  The boot loader is generally the coldest code
> > > > paths
> > > > in a system, so relaxing it won't give any real benefit (well, if you
> > > > reboot a system 100 times you may finally save one second), but
> > > > increases the maintenance burden.
> > > >
> > > Yes, it's easy to pass -mno-relax, but binutils-2.40 doesn't support
> > > this option.
> > Then maybe probe it in grub's configure and add it to CFLAGS when it's
> > supported? IIUC every toolchain with support for relaxation should
> > provide this toggle, and we already probe several LoongArch-specific
> > flags right now so the infra is already there.
>
> --no-relax is accepted even with ld-2.38, the man page says:
>
>            On platforms where the feature is not supported, both --relax and
>            --no-relax are accepted, but ignored.
>
> And it *should* disable relax for ld-2.41.  If not I'd consider it a bug
> and we should fix it for Binutils.
>
> If --no-relax behaves as expected I guess we just need
>
>     LDFLAGS_PLATFORM += -Wl,--no-relax
>
> in "if test "x$target_cpu" = xloongarch64" block.

It looks we have "no-relax" flag detection in the configure for sparc64
target. So, detection code is in place...

Anyway, I do not have very strong preference here because relaxation
code is not that big. So, we can carry it. Just please decide ASAP
which solution you prefer. I am going to do code freeze this week...

Daniel