Re: {standard input}:4155: Error: pcrel offset for branch to .LS000B too far (0x38)

[Jan Kara]

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@xxxxxxxxx/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@xxxxxxxxx/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@xxxxxxxxx>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202601121758.kA3osRht-lkp@xxxxxxxxx/
> >
> > 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@xxxxxxxx>
SUSE Labs, CR