Re: C aggregate passing (Rust kernel policy)

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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@HansenPartnership.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

while we don't need full unwind in rust, we do need enough to get
traces working.

Regards,

James