Re: [DTrace-devel] [PATCH v2] test: stack_fbt

[Kris Van Hees <kris.van.hees@oracle.com>]

On Wed, Nov 20, 2024 at 03:39:34PM -0500, Eugene Loh wrote:
> On 11/20/24 14:38, Kris Van Hees wrote:
> 
> > On Wed, Nov 20, 2024 at 02:22:56PM -0500, Kris Van Hees wrote:
> > > On Thu, Nov 07, 2024 at 06:28:41PM -0500, eugene.loh--- via DTrace-devel wrote:
> > > > From: Eugene Loh <eugene.loh@oracle.com>
> > > > 
> > > > Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> > > Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
> > > 
> > > ... with small changes as shown below.
> > Also...  the full stack output comparison is riddled with issues because the
> > low level entry point handling for syscalls is an atrea that has changed a
> > lot and still changes.  E.g. this test fails now on a 6.8.8 upstream kernel
> > because of the following difference:
> > 
> > <               vmlinux`entry_SYSCALL_64+{ptr}
> > ---
> > >                vmlinux`entry_SYSCALL_64_after_hwframe+{ptr}
> > Maybe it would be better to not bother trying to test the full stack trace
> > because it is bound to keep changing and we'll keep needing to update the
> > test to deal with various kernel versions.  After all, we do need to be able
> > to pass tests with upstream kernels also.
> 
> Maybe.  Or we just bite the bullet and add more cases as they become
> needed.  After all, there is a framework here for being able to add new
> cases in the future.  There is the usual tension between simpler tests and
> more rigorous testing.

Yes, my challenge right now is that I really do not want to try this test on
a large variety of kernel versions to ensure that we cover the "most likely
cases" of kernels people might be wanting to use (and test) DTrace on.  That
is a recipe for fa massive headache.