From: Sean Christopherson <seanjc@google.com>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Hisam Mehboob <hisamshar@gmail.com>,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, Aqib Faruqui <aqibaf@amazon.com>,
shuah@kernel.org, pbonzini@redhat.com
Subject: Re: [PATCH] KVM: selftests: Guard execinfo.h inclusion for non-glibc builds
Date: Wed, 1 Apr 2026 07:01:18 -0700 [thread overview]
Message-ID: <ac0lGVlg4cJSNCGl@google.com> (raw)
In-Reply-To: <4334432d-982e-4450-9281-de739c25ebfd@linuxfoundation.org>
On Tue, Mar 31, 2026, Shuah Khan wrote:
> On 3/25/26 12:47, Hisam Mehboob wrote:
> > On 3/25/26 23:03, Shuah Khan wrote:
> > > On 3/24/26 12:02, Shuah Khan wrote:
> > > > On 3/18/26 18:08, Hisam Mehboob wrote:
> > > > > The backtrace() function and execinfo.h are GNU extensions available
> > > > > in glibc but not in non-glibc C libraries such as musl. Building KVM
> > > > > selftests with musl-gcc fails with:
> > > > >
> > > > > lib/assert.c:9:10: fatal error: execinfo.h: No such file or directory
> > > > >
> > > > > Guard the inclusion of execinfo.h under #ifdef __GLIBC__, and wrap
> > > > > all backtrace() usage under the same guard with a fallback message
> > > > > for non-glibc builds indicating that stack traces are not available.
> > > > >
> > > > > Unlike the approach of adding a weak stub for backtrace(), this
> > > > > explicitly handles the non-glibc case rather than silently providing
> > > > > an empty implementation.
> > > > >
> > > > > Link: https://lore.kernel.org/kvm/20250829142556.72577-7- aqibaf@amazon.com/
> > > > >
> > > > > Suggested-by: Aqib Faruqui <aqibaf@amazon.com>
> > > > > Signed-off-by: Hisam Mehboob <hisamshar@gmail.com>
> > > > > ---
> > > > > tools/testing/selftests/kvm/lib/assert.c | 7 +++++++
> > > > > 1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/tools/testing/selftests/kvm/lib/assert.c b/tools/ testing/selftests/kvm/lib/assert.c
> > > > > index b49690658c60..3442b80c37c1 100644
> > > > > --- a/tools/testing/selftests/kvm/lib/assert.c
> > > > > +++ b/tools/testing/selftests/kvm/lib/assert.c
> > > > > @@ -6,7 +6,9 @@
> > > > > */
> > > > > #include "test_util.h"
> > > > > +#ifdef __GLIBC__
> > > > > #include <execinfo.h>
> > > > > +#endif
> > > > > Is __GLIBC__ defined in musl-gcc? Looks like that is the case with the
> > > > error?
> > >
> > > If __GLIBC__ isn't there you shouldn't see this error because the include
> > > is in - this error doesn't make sense if __GLIBC__ isn't defined. What
> > > am I missing?
> > >
> >
> > To clarify the compiler error you mentioned: the error log in the commit
> > message shows the failure that occurs before this patch is applied. Because
> > musl-gcc doesn't define __GLIBC__, the original unconditional <execinfo.h>
> > inclusion causes the build to fail. The #ifdef in my patch was intended to
> > fix that exact failure.
> >
> > > +#ifdef __GLIBC__
> > > #include <execinfo.h>
> > > +#endif
> > >
> > > Also check tools/testing/selftests/bpf/test_progs.c - I think backtrace()
> > > stub needs be defined only for the !__GLIBC__ case
> > >
> >
> > Looking at how bpf/test_progs.c handles it, I agree the weak stub approach
> > is much cleaner. I will implement it so that it still prints an explicit
> > warning message when a trace is unavailable.
I disagree. _If_ we didn't need the __GLIBC__ #ifdef, then I would be in favor
of __weak, but since the #ifdeffery is needed, using an #ifdef and a __weak symbol
is double the ugliness.
IMO, the way to make this less ugly is to using a single #ifdef and a local stub.
diff --git a/tools/testing/selftests/kvm/lib/assert.c b/tools/testing/selftests/kvm/lib/assert.c
index b49690658c60..315175ca49f1 100644
--- a/tools/testing/selftests/kvm/lib/assert.c
+++ b/tools/testing/selftests/kvm/lib/assert.c
@@ -6,11 +6,13 @@
*/
#include "test_util.h"
-#include <execinfo.h>
#include <sys/syscall.h>
#include "kselftest.h"
+#ifdef __GLIBC__
+#include <execinfo.h>
+
/* Dumps the current stack trace to stderr. */
static void __attribute__((noinline)) test_dump_stack(void);
static void test_dump_stack(void)
@@ -57,6 +59,9 @@ static void test_dump_stack(void)
system(cmd);
#pragma GCC diagnostic pop
}
+#else
+static void test_dump_stack(void) {}
+#endif
static pid_t _gettid(void)
{
next prev parent reply other threads:[~2026-04-01 14:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 0:08 [PATCH] KVM: selftests: Guard execinfo.h inclusion for non-glibc builds Hisam Mehboob
2026-03-24 18:02 ` Shuah Khan
2026-03-25 18:03 ` Shuah Khan
2026-03-25 18:47 ` Hisam Mehboob
2026-03-31 23:09 ` Shuah Khan
2026-04-01 14:01 ` Sean Christopherson [this message]
2026-04-09 11:53 ` Hisam Mehboob
2026-04-09 15:38 ` [PATCH v2] " Hisam Mehboob
2026-05-19 0:40 ` Sean Christopherson
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=ac0lGVlg4cJSNCGl@google.com \
--to=seanjc@google.com \
--cc=aqibaf@amazon.com \
--cc=hisamshar@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
/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.