All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hisam Mehboob <hisamshar@gmail.com>
To: Sean Christopherson <seanjc@google.com>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: 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: Thu, 9 Apr 2026 16:53:09 +0500	[thread overview]
Message-ID: <8262fe0c-cbec-4c85-b5ee-2f6cc20cf57a@gmail.com> (raw)
In-Reply-To: <ac0lGVlg4cJSNCGl@google.com>

On 4/1/26 19:01, Sean Christopherson wrote:
> 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)
>   {

Thanks for the suggestion. I will send a v2 implementing this approach.

  reply	other threads:[~2026-04-09 11:53 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
2026-04-09 11:53           ` Hisam Mehboob [this message]
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=8262fe0c-cbec-4c85-b5ee-2f6cc20cf57a@gmail.com \
    --to=hisamshar@gmail.com \
    --cc=aqibaf@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.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.