On Thu, Mar 21, 2024 at 12:07:51PM +0000, David Laight wrote: > From: Russell King > > Sent: 21 March 2024 11:24 > > > > 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. > > I've also seen the compiler defer generating a stack frame until > after an initial conditional. .. which is why we pass -mno-sched-prolog to GCC. > That might mean you can get the BL in the middle of a function > but where the following instruction is for the 'no stack frame' > side of the branch. > That is very likely to break any stack offset calculations. No it can't. At any one point in the function, the stack has to be in a well defined state, so that access to local variables can work, and also the stack can be correctly unwound. If there exists a point in the function body which can be reached where the stack could be in two different states, then the stack can't be restored to the parent context. > > 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. > > Isn't this already in the unwinder? > A BL itself isn't going to fault with PC = next-instruction. You are missing the fact that the PC can be the saved LR, and thus can very well be the next instruction. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
