All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Andrew Jones <andrew.jones@linux.dev>
Cc: Jinrong Liang <ljr.kernel@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Joerg Roedel <joro@8bytes.org>,
	Jinrong Liang <cloudliang@tencent.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests: kvm: Fix a compile error in selftests/kvm/rseq_test.c
Date: Wed, 3 Aug 2022 16:10:53 +0000	[thread overview]
Message-ID: <YuqeDetNukKp9lyF@google.com> (raw)
In-Reply-To: <20220803142637.3y5fj2cwyvbrwect@kamzik>

On Wed, Aug 03, 2022, Andrew Jones wrote:
> On Wed, Aug 03, 2022 at 09:58:51PM +0800, Jinrong Liang wrote:
> > My ldd version is (GNU libc) 2.28, and I get a compilation error in this case.
> > But I use another ldd (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31 is compiling fine.
> > This shows that compilation errors may occur in different GNU libc environments.
> > Would it be more appropriate to use syscall for better compatibility?
> 
> OK, it's a pity, but no big deal to use syscall().

Ya, https://man7.org/linux/man-pages/man2/gettid.2.html says:

  The gettid() system call first appeared on Linux in kernel 2.4.11.  Library
  support was added in glibc 2.30.

But there are already two other instances of syscall(SYS_gettid) in KVM selftests,
tools/testing/selftests/kvm/lib/assert.c even adds a _gettid() wrapper.

So rather than having to remember (or discover) to use syscall(SYS_gettid), I wonder
if it's possible to conditionally define gettid()?  E.g. check for GLIBC version?
Or do

  #define gettid() syscall(SYS_gettid)

so that it's always available and simply overrides the library's gettid() if it's
provided?

  reply	other threads:[~2022-08-03 16:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02  7:12 [PATCH] selftests: kvm: Fix a compile error in selftests/kvm/rseq_test.c Jinrong Liang
2022-08-02 15:08 ` Andrew Jones
2022-08-03 13:58   ` Jinrong Liang
2022-08-03 14:26     ` Andrew Jones
2022-08-03 16:10       ` Sean Christopherson [this message]
2022-08-03 17:26         ` Andrew Jones
2022-08-04 23:41           ` Sean Christopherson
2022-09-07 16:01 ` Sean Christopherson
2022-09-07 16:54   ` Liam Merwick
2022-09-16 10:02     ` JinrongLiang
2022-09-21 23:29       ` David Matlack
2022-09-22 21:02 ` Paolo Bonzini

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=YuqeDetNukKp9lyF@google.com \
    --to=seanjc@google.com \
    --cc=andrew.jones@linux.dev \
    --cc=cloudliang@tencent.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljr.kernel@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.