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

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

[kernel test robot]

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@intel.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)

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Baokun Li]

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@intel.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.


Thanks,
Baokun

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@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@intel.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@suse.com>
SUSE Labs, CR

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

[Baokun Li]

On 2026-01-13 00:35, Jan Kara wrote:
> 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@intel.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

That makes sense. I’ve CC'd the GCC C-SKY port maintainers.
Let's see if they have any thoughts.


Regards,
Baokun