Message-ID: <20250226115726.27530000@gandalf.local.home>
Date: Wed, 26 Feb 2025 11:57:26 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>, Greg KH
 <gregkh@...uxfoundation.org>, Miguel Ojeda
 <miguel.ojeda.sandonis@...il.com>, Ventura Jack <venturajack85@...il.com>,
 "H. Peter Anvin" <hpa@...or.com>, Alice Ryhl <aliceryhl@...gle.com>, Linus
 Torvalds <torvalds@...ux-foundation.org>, Gary Guo <gary@...yguo.net>,
 airlied@...il.com, boqun.feng@...il.com, david.laight.linux@...il.com,
 hch@...radead.org, ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, Ralf Jung <post@...fj.de>, Josh Poimboeuf
 <jpoimboe@...hat.com>
Subject: Re: C aggregate passing (Rust kernel policy)


[ Adding Josh ]

On Wed, 26 Feb 2025 11:47:09 -0500
Kent Overstreet <kent.overstreet@...ux.dev> wrote:

> On Wed, Feb 26, 2025 at 11:42:41AM -0500, James Bottomley wrote:
> > On Wed, 2025-02-26 at 11:00 -0500, Steven Rostedt wrote:  
> > > On Wed, 26 Feb 2025 09:45:53 -0500
> > > James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > >   
> > > > > From some other rust boot system work, I know that the quality of
> > > > > a    
> > > > simple backtrace in rust where you just pick out addresses you
> > > > think you know in the stack and print them as symbols can sometimes
> > > > be rather misleading, which is why you need an unwinder to tell you
> > > > exactly what happened.  
> > > 
> > > One thing I learned at GNU Cauldron last year is that the kernel
> > > folks use the term "unwinding" incorrectly. Unwinding to the compiler
> > > folks mean having full access to all the frames and variables and
> > > what not for all the previous functions.
> > > 
> > > What the kernel calls "unwinding" the compiler folks call "stack
> > > walking". That's a much easier task than doing an unwinding, and that
> > > is usually all we need when something crashes.  
> > 
> > Well, that's not the whole story.  We do have at least three unwinders
> > in the code base.  You're right in that we don't care about anything
> > other than the call trace embedded in the frame, so a lot of unwind
> > debug information isn't relevant to us and the unwinders ignore it.  In
> > the old days we just used to use the GUESS unwinder which looks for
> > addresses inside the text segment in the stack and prints them in
> > order.  Now we (at least on amd64) use the ORC unwinder because it
> > gives better traces:
> > 
> > https://docs.kernel.org/arch/x86/orc-unwinder.html  

Note, both myself and Josh (creator of ORC) were arguing with the GCC folks
until we all figured out we were talking about two different things. Once
they said "Oh, you mean stack walking. Yeah that can work" and the
arguments stopped. Lessons learned that day was that compiler folks take
the term "unwinding" to mean much more than kernel folks, and since we have
compiler folks on this thread, I'd figure I would point that out.

We still use the term "unwinder" in the kernel, but during the sframe
meetings, we need to point out that we all just care about stack walking.

> 
> More accurate perhaps, but I still don't see it working reliably - I'm x
> still having to switch all my test setups (and users) to frame pointers
> if I want to be able to debug reliably.

Really? The entire point of ORC was to have accurate stack traces so that
live kernel patching can work. If there's something incorrect, then please
report it.

-- Steve

Powered by blists - more mailing lists