[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b07ae769-6f10-484f-9291-a8b40f58c5f9@huawei.com>
Date: Tue, 13 Jan 2026 10:13:49 +0800
From: Baokun Li <libaokun1@...wei.com>
To: Jan Kara <jack@...e.cz>
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>, Ojaswin Mujoo <ojaswin@...ux.ibm.com>,
<cooper.qu@...ux.alibaba.com>, <yunhai@...ux.alibaba.com>
Subject: Re: {standard input}:4155: Error: pcrel offset for branch to .LS000B
too far (0x38)
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@...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
That makes sense. I’ve CC'd the GCC C-SKY port maintainers.
Let's see if they have any thoughts.
Regards,
Baokun
Powered by blists - more mailing lists