[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <txzy4pnt3se34lsvbtpbgvndxts6xsydxx5sswdjzdrcie7zlq@63cewvtotbu3>
Date: Mon, 12 Jan 2026 17:35:30 +0100
From: Jan Kara <jack@...e.cz>
To: Baokun Li <libaokun1@...wei.com>
Cc: kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev,
linux-kernel@...r.kernel.org, Theodore Ts'o <tytso@....edu>, Zhang Yi <yi.zhang@...wei.com>,
Jan Kara <jack@...e.cz>, Ojaswin Mujoo <ojaswin@...ux.ibm.com>
Subject: Re: {standard input}:4155: Error: pcrel offset for branch to .LS000B
too far (0x38)
Hi!
On Mon 12-01-26 20:09:47, Baokun Li wrote:
> On 2026-01-12 17:42, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head: 0f61b1860cc3f52aef9036d7235ed1f017632193
> > commit: a6d73242b8b5caa9f9a529eab49cc1e85ace9890 ext4: support large block size in ext4_mpage_readpages()
> > date: 6 weeks ago
> > config: csky-randconfig-001-20260112 (https://download.01.org/0day-ci/archive/20260112/202601121758.kA3osRht-lkp@intel.com/config)
> > compiler: csky-linux-gcc (GCC) 15.2.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260112/202601121758.kA3osRht-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@...el.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202601121758.kA3osRht-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>):
> >
> > {standard input}: Assembler messages:
> >>> {standard input}:4155: Error: pcrel offset for branch to .LS000B too far (0x38)
>
> Hi,
>
> Thanks for the report.
>
> After looking into this issue, it turns out that replacing the original
> calculation with the macro version causes the compiler to emit a larger
> sequence of instructions.
>
> On most architectures this is harmless, because their GCC backends support
> proper branch relaxation and can automatically promote a short branch to
> a long branch when the offset grows.
>
> However, the CSKY GCC backend does not implement branch relaxation. As a
> result, once the generated basic block becomes slightly larger, some short
> branch instructions can no longer reach their targets, and the assembler
> reports the “pcrel offset too far” error.
>
> Given this, one possible workaround on the kernel side would be to replace
> the macro with a static inline helper. Using an inline function allows GCC
> to perform more aggressive optimization and typically avoids generating
> unnecessarily large instruction sequences, which helps prevent the
> short-branch overflow seen on CSKY.
>
> However, the more general and robust solution would be to improve the
> CSKY GCC backend so that it supports proper branch relaxation, as other
> architectures do. With branch relaxation in place, these issues would not
> depend on how the code is written.
>
> We’d appreciate any thoughts on which approach makes more sense.
Frankly, since this is such a niche platform, I'd just let those guys fix
their compiler and don't complicate ext4 codebase for that.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists