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

From: Josh Poimboeuf <jpoimboe@redhat.com>
To: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Julien Thierry <jthierry@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Brown <broonie@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace
Date: Mon, 1 Feb 2021 21:36:39 -0600	[thread overview]
Message-ID: <20210202033639.mjusaoqrbshzgjjl@treble> (raw)
In-Reply-To: <44a32a13-f744-b591-a68d-19cf665e5495@linux.microsoft.com>

On Mon, Feb 01, 2021 at 08:29:52PM -0600, Madhavan T. Venkataraman wrote:
> The no-ops were just a wild idea of mine. I knew I would rue it as soon as I hit
> the send button :-)

That's ok, I like wild ideas :-)

> > The original version of objtool was an awk script which basically just
> > crudely looked for the prologue/epilogue instructions.  It mostly
> > worked.
> > 
> > But it wasn't 100%, and these days the prologue isn't always at the
> > beginning, and the epilogue is usually buried in the middle.  And
> > sometimes there are more stack pushes/pops hidden outside of the formal
> > prologue/epilogue.  Not to mention asm code which does all kinds of
> > crazy things.  And other edge cases, like leaf functions which don't
> > require frame pointers, and alternatives patching/paravirt/etc which can
> > muck with the stack layout at runtime.  Eventually we realized a "full
> > coverage" objtool is the wisest approach.
> > 
> 
> Yes. I studied the objtool code. It does a fantastic job for X86. I suspect
> it took a lot of time and a lot of work to get it right. It is
> just that adding complete static analysis for an arch is daunting and
> time consuming. How would we ever prove to the community that we are
> truly done?

Objtool makes sure to visit all instructions in the file.  Otherwise it
prints an "unreachable instruction" warning.  That's how we make sure to
get full coverage.

And most compiled code is pretty straightforward, so the static analysis
is mostly "just" a matter of monitoring stack operations and following
the branches.  Of course, the devil's in the details.

It gets battle-tested pretty well with randconfigs across a lot of
different compiler versions.  When it encounters some situation it
doesn't understand, it complains, and we hear about it.

Julien and Raphael already laid a lot of the groundwork for porting it
to new arches, so as you can see with Julien's latest series there's not
much to do beyond adding the instruction decoder, and then looking at
all the warnings.

Sometimes warnings are legit, and other times they mean something's
amiss with objtool.  But once the warnings are all gone, in my
experience it means objtool's working well.

-- 
Josh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel