Linux DTrace development list
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
	dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] test: ensure casting does not affect value
Date: Wed, 31 Jul 2024 16:04:46 -0400	[thread overview]
Message-ID: <ZqqY3mvU2Fv14hly@oracle.com> (raw)
In-Reply-To: <5c65028b-a5b8-12f8-d1c1-0fceee063dc7@oracle.com>

On Wed, Jul 31, 2024 at 03:51:52PM -0400, Eugene Loh wrote:
> What is the point of this test?  If we do not know the type of the kernel
> variable, then what does "kernel_read_neg_small_scalar" mean?

We *know* the type.  That is why we use that particular kernel symbol.  The
issue is that on kernel without CTF DTrace cannot know the type, so we need
to tell it that it is an int.

	Kris

> On 7/31/24 15:01, Kris Van Hees wrote:
> > On systems without CTF, we do not know the type of kernel variables.
> > By doing an explicit cast to int64_t a negative int is converted into a
> > large positive integer.  The proper cast is 'int' of course.
> > 
> > Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
> > ---
> >   test/unittest/codegen/tst.kernel_read_neg_small_scalar.d | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/test/unittest/codegen/tst.kernel_read_neg_small_scalar.d b/test/unittest/codegen/tst.kernel_read_neg_small_scalar.d
> > index 7c585d1b..cda6649b 100644
> > --- a/test/unittest/codegen/tst.kernel_read_neg_small_scalar.d
> > +++ b/test/unittest/codegen/tst.kernel_read_neg_small_scalar.d
> > @@ -1,6 +1,6 @@
> >   /*
> >    * Oracle Linux DTrace.
> > - * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> > + * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.
> >    * Licensed under the Universal Permissive License v 1.0 as shown at
> >    * http://oss.oracle.com/licenses/upl.
> >    */
> > @@ -11,10 +11,10 @@ BEGIN
> >   {
> >   	/*
> >   	 * Unless we are actually crashing, the `crashing_cpu int will be -1.
> > -	 * We cast it to int64_t to ensure that the value read from the kernel
> > +	 * We cast it to int to ensure that the value read from the kernel
> >   	 * is sign-extended.
> >   	 */
> > -	trace((int64_t)`crashing_cpu);
> > +	trace((int)`crashing_cpu);
> >   	exit(0);
> >   }

  reply	other threads:[~2024-07-31 20:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31 19:01 [PATCH] test: ensure casting does not affect value Kris Van Hees
2024-07-31 19:51 ` Eugene Loh
2024-07-31 20:04   ` Kris Van Hees [this message]
2024-08-01 18:44 ` Nick Alcock
2024-08-01 19:03   ` Kris Van Hees

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZqqY3mvU2Fv14hly@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox