[RFC PATCH 0/3] arm64: Implement reliable stack trace

Madhavan T. Venkataraman madvenka at linux.microsoft.com
Mon Feb 1 16:40:16 EST 2021

On 2/1/21 10:22 AM, Mark Brown wrote:
> On Mon, Feb 01, 2021 at 04:02:25PM +0000, Mark Rutland wrote:
>> On Mon, Feb 01, 2021 at 09:21:43AM -0600, Madhavan T. Venkataraman wrote:
>>> OK. Before this whole discussion, I did not know that the compiler cannot be trusted.
>> I think "the compiler cannot be trusted" is overly strong. We want to
>> *verify* that the compiler is doing what we expect, which might be more
>> than what it guarantees to do (and those expectations can change over
>> time), but it doesn't mean we should try to avoid the compiler wherever
>> possible.
> Right, part of what objtool offers here is that it is a static checker
> which has an independent implementation of the assumptions we have about
> the generated code to that in the compiler - the fact that we've got two
> implementations means we're more likely to notice any implementation
> drift or unintended changes that affect those assumptions.  Moving code
> generation into objtool would mean we were again relying on a single
> implementation.

Agreed. And I am fine with the compiler doing it and objtool checking it.
If we find that the compiler's implementation does not perform well
enough for the kernel, we can revisit this point.


More information about the linux-arm-kernel mailing list