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

[Baokun Li <libaokun1@huawei.com>]

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