On Thu, 21 Mar 2024 at 12:24, Russell King (Oracle) <linux@xxxxxxxxxxxxxxx> wrote: > > On Thu, Mar 21, 2024 at 10:22:30AM +0000, David Laight wrote: > > How aggressively does the compiler optimise 'noreturn' functions? > > I've seen cases where the compiler emits a BL instruction as the very > last thing in the function, and nothing after it. > > This is where the problem lies - because the link register value > created by the BL instruction will point to the instruction after the > BL which will _not_ part of the function that invoked the BL. That > will probably cause issues for the ELF unwinder, which means this > issue probably goes beyond _just_ printing the function name. > > I have vague memories that Ard has been involved in the unwinder, > maybe he could comment on this problem? Maybe we need the unwinder > itself to do the correction? I also wonder whether we should only > do the correction if we detect that we're pointing at the first > instruction of a function, and the previous instruction in the > text segment was a BL. > First of all, I consider this to be a defect in the toolchain. Given that the compiler knows that the BL is not going to return, it should simply emit a BRK instruction or similar after it. This would catch inadvertent returns as well as eliminate this kind of confusion. The ARM unwind format is not really suitable for asynchronous unwinding, so unwinding across exceptions is always going to be hit and miss. Also, we should consider what the unwind information actually tells us: for debugging, it is useful to understand where we came from, i.e., how we ended up in the situation where the backtrace was triggered, but what it actually tells us is where we would have gone next had execution not been interrupted. The latter notion is important for things like reliable stacktrace and live patch, which need to know where a task might be returning to. Returning to the first instruction of a function is unusual, but in the light of the above, I don't think we can assume that it means that the call originated from the preceding function, even when it ends in a BL instruction (although it would be highly likely, of course). The tracers and other instrumentation might insert probes in the return path, and I suspect that this may result in a similar situation in some cases. Given that this particular issue would just disappear if the compiler would just insert a BRK after the BL, I'd prefer to explore first whether we can get this fixed on the compiler side.
