Re: C aggregate passing (Rust kernel policy)

[Kent Overstreet]

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@xxxxxxxxxxxxxxxxxxxxx> 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

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.