Re: sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section

[Krzysztof Kozlowski <krzk@kernel.org>]

On 21/03/2025 02:24, Oliver Sang wrote:
> hi, Krzysztof,
> 
> On Mon, Mar 17, 2025 at 06:02:14PM +0100, Krzysztof Kozlowski wrote:
>> On 17/03/2025 17:24, kernel test robot wrote:
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>> head:   4701f33a10702d5fc577c32434eb62adde0a1ae1
>>> commit: 9ea22713227397b56a2b36a68c8bda13f0b43d70 ASoC: codecs: wcd934x: Handle nicer probe deferral and simplify with dev_err_probe()
>>> date:   9 months ago
>>> config: x86_64-randconfig-102-20250317 (https://download.01.org/0day-ci/archive/20250318/202503180044.oH9gyPeg-lkp@intel.com/config)
>>> compiler: clang version 20.1.0 (https://github.com/llvm/llvm-project 24a30daaa559829ad079f2ff7f73eb4e18095f88)
>>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250318/202503180044.oH9gyPeg-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/202503180044.oH9gyPeg-lkp@intel.com/
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>>>> sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section
>>
>> I cannot reproduce it on clang-18 and clang-19 (I do not have clang-20
>> in my distros) and I do not see how original commit could trigger this
>> warning.
> 
> we double confirmed, the issue is really only reproduced on clang-20
> 
> linux$make W=1 LLVM=1 -j32 ARCH=x86_64
> 
> ...
> 
>   LD [M]  sound/soc/codecs/snd-soc-lpass-va-macro.o
> sound/soc/codecs/snd-soc-wcd934x.o: warning: objtool: .text.wcd934x_slim_irq_handler: unexpected end of section   <----
> 
> 
> but cannot be reproduced on clang-19
> 
> linux$make W=1 LLVM=1 -j32 ARCH=x86_64



Thanks, I still think this is a bug in clang because of two reasons:
1. Code looks correct,
2. I really, really, really do not see how
9ea22713227397b56a2b36a68c8bda13f0b43d70, which is marked as as the
culprit, could cause it.

Best regards,
Krzysztof