Add stdbool.h to the list of nolibc.h includes, otherwise tests compiled
with -nostdlib will fail with "error: unknown type name 'bool'", even if
a nolibc stdbool implementation is available at tools/include/nolibc/.

Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/
Signed-off-by: André Almeida <andrealmeid@igalia.com>
---
 tools/include/nolibc/nolibc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
index c199ade200c2..d2f5aa085f8e 100644
--- a/tools/include/nolibc/nolibc.h
+++ b/tools/include/nolibc/nolibc.h
@@ -116,6 +116,7 @@
 #include "sched.h"
 #include "signal.h"
 #include "unistd.h"
+#include "stdbool.h"
 #include "stdio.h"
 #include "stdlib.h"
 #include "string.h"
-- 
2.51.0

On 2025-09-25 11:14:23-0300, André Almeida wrote:
> Add stdbool.h to the list of nolibc.h includes, otherwise tests compiled
> with -nostdlib will fail with "error: unknown type name 'bool'", even if
> a nolibc stdbool implementation is available at tools/include/nolibc/.
> 
> Reported-by: Mark Brown <broonie@kernel.org>
> Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/
> Signed-off-by: André Almeida <andrealmeid@igalia.com>

As mentioned in the other subthread I'm fine with this.
How urgent is this fix? Can it wait until my regular PR for -rc1?
If not, who is going to send it to Linus?

If someone else sends it:
Acked-by: Thomas Weißschuh <linux@weissschuh.net>

> ---
>  tools/include/nolibc/nolibc.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
> index c199ade200c2..d2f5aa085f8e 100644
> --- a/tools/include/nolibc/nolibc.h
> +++ b/tools/include/nolibc/nolibc.h
> @@ -116,6 +116,7 @@
>  #include "sched.h"
>  #include "signal.h"
>  #include "unistd.h"
> +#include "stdbool.h"
>  #include "stdio.h"
>  #include "stdlib.h"
>  #include "string.h"
> -- 
> 2.51.0
> 

On Thu, Sep 25, 2025 at 06:15:07PM +0200, Thomas Weißschuh wrote:

> As mentioned in the other subthread I'm fine with this.
> How urgent is this fix? Can it wait until my regular PR for -rc1?
> If not, who is going to send it to Linus?

It's pretty urgent, this is a build break for at least the arm64
selftests in -next due to the commit I mentioned with a fixes tag which
is in the tip tree.

On 2025-09-25 17:24:18+0100, Mark Brown wrote:
> On Thu, Sep 25, 2025 at 06:15:07PM +0200, Thomas Weißschuh wrote:
> 
> > As mentioned in the other subthread I'm fine with this.
> > How urgent is this fix? Can it wait until my regular PR for -rc1?
> > If not, who is going to send it to Linus?
> 
> It's pretty urgent, this is a build break for at least the arm64
> selftests in -next due to the commit I mentioned with a fixes tag which
> is in the tip tree.

I pushed it into the nolibc for-next branch and will include it in my
6.18-rc1 PR in a few days. Let me know if this is insufficient.

Thomas

On Thu, Sep 25, 2025 at 11:14:23AM -0300, André Almeida wrote:
> Add stdbool.h to the list of nolibc.h includes, otherwise tests compiled
> with -nostdlib will fail with "error: unknown type name 'bool'", even if
> a nolibc stdbool implementation is available at tools/include/nolibc/.
> 
> Reported-by: Mark Brown <broonie@kernel.org>
> Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/
> Signed-off-by: André Almeida <andrealmeid@igalia.com>

Fixes: f2662ec26b26 ("selftests: kselftest: Create ksft_print_dbg_msg()")

> ---
>  tools/include/nolibc/nolibc.h | 1 +
>  1 file changed, 1 insertion(+)

> --- a/tools/include/nolibc/nolibc.h
> +++ b/tools/include/nolibc/nolibc.h
> @@ -116,6 +116,7 @@
>  #include "sched.h"
>  #include "signal.h"
>  #include "unistd.h"
> +#include "stdbool.h"
>  #include "stdio.h"
>  #include "stdlib.h"
>  #include "string.h"

It's not 100% clear to me that we should add this to the nolibc
includes given that nolibc itself does not rely on or offer stdbool -
I was going to send something out adjusting kselftest.h to unguard the
include there.

Hi Mark,

Em 25/09/2025 11:24, Mark Brown escreveu:
> On Thu, Sep 25, 2025 at 11:14:23AM -0300, André Almeida wrote:
>> Add stdbool.h to the list of nolibc.h includes, otherwise tests compiled
>> with -nostdlib will fail with "error: unknown type name 'bool'", even if
>> a nolibc stdbool implementation is available at tools/include/nolibc/.
>>
>> Reported-by: Mark Brown <broonie@kernel.org>
>> Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/
>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> 
> Fixes: f2662ec26b26 ("selftests: kselftest: Create ksft_print_dbg_msg()")
> 
>> ---
>>   tools/include/nolibc/nolibc.h | 1 +
>>   1 file changed, 1 insertion(+)
> 
>> --- a/tools/include/nolibc/nolibc.h
>> +++ b/tools/include/nolibc/nolibc.h
>> @@ -116,6 +116,7 @@
>>   #include "sched.h"
>>   #include "signal.h"
>>   #include "unistd.h"
>> +#include "stdbool.h"
>>   #include "stdio.h"
>>   #include "stdlib.h"
>>   #include "string.h"
> 
> It's not 100% clear to me that we should add this to the nolibc
> includes given that nolibc itself does not rely on or offer stdbool -
> I was going to send something out adjusting kselftest.h to unguard the
> include there.

If we don't include stdbool.h here, it looks like 
tools/include/nolibc/stdbool.h cannot be used by any test, and 
unguarding <stdbool.h> would defeat the purpose of using -nolibc?

I'm also not 100% sure as well, lets see if Thomas or Willy can shine a 
light here.

Sep 25, 2025 16:37:45 André Almeida <andrealmeid@igalia.com>:

> Hi Mark,
>
> Em 25/09/2025 11:24, Mark Brown escreveu:
>> On Thu, Sep 25, 2025 at 11:14:23AM -0300, André Almeida wrote:
>>> Add stdbool.h to the list of nolibc.h includes, otherwise tests compiled
>>> with -nostdlib will fail with "error: unknown type name 'bool'", even if
>>> a nolibc stdbool implementation is available at tools/include/nolibc/.
>>>
>>> Reported-by: Mark Brown <broonie@kernel.org>
>>> Closes: https://lore.kernel.org/lkml/833f5ae5-190e-47ec-9ad9-127ad166c80c@sirena.org.uk/
>>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>> Fixes: f2662ec26b26 ("selftests: kselftest: Create ksft_print_dbg_msg()")
>> ---
>>>   tools/include/nolibc/nolibc.h | 1 +
>>>   1 file changed, 1 insertion(+)
>> --- a/tools/include/nolibc/nolibc.h
>>> +++ b/tools/include/nolibc/nolibc.h
>>> @@ -116,6 +116,7 @@
>>>   #include "sched.h"
>>>   #include "signal.h"
>>>   #include "unistd.h"
>>> +#include "stdbool.h"
>>>   #include "stdio.h"
>>>   #include "stdlib.h"
>>>   #include "string.h"
>> It's not 100% clear to me that we should add this to the nolibc
>> includes given that nolibc itself does not rely on or offer stdbool -
>> I was going to send something out adjusting kselftest.h to unguard the
>> include there.
>
> If we don't include stdbool.h here, it looks like tools/include/nolibc/stdbool.h cannot be used by any test, and unguarding <stdbool.h> would defeat the purpose of using -nolibc?

It can still be used through '#include <stdbool.h>'.
But we support both ways of using nolibc, so this is a valid bugfix and I will apply it.

On the other hand removing the guard in kselftest.h would be nice too,
the code will look idiomatic.
It could trigger issues for programs that do not have tools/include/nolibc/ in their include path.
But Mark should be able to fund those.
I removed the guards in kselftest_harness.h before and that didn't lead to issues.

> I'm also not 100% sure as well, lets see if Thomas or Willy can shine a light here.

On Thu, Sep 25, 2025 at 11:37:39AM -0300, André Almeida wrote:
> Em 25/09/2025 11:24, Mark Brown escreveu:

> > It's not 100% clear to me that we should add this to the nolibc
> > includes given that nolibc itself does not rely on or offer stdbool -
> > I was going to send something out adjusting kselftest.h to unguard the
> > include there.
> 
> If we don't include stdbool.h here, it looks like
> tools/include/nolibc/stdbool.h cannot be used by any test, and unguarding
> <stdbool.h> would defeat the purpose of using -nolibc?

Huh, I'd not seen that - generally stdbool.h comes from the compiler
rather than libc so it didn't occur to me that nolibc would provide one.
Looking at the compilers I have installed they all seem to be doing
essentially the same thing (with some C++ handling).

> I'm also not 100% sure as well, lets see if Thomas or Willy can shine a
> light here.

Yeah, if we've got the nolibc one I guess we should use it in which case
your patch is I guess what's expected.  I'll send out my version once my
tests finish just in case.

Sep 25, 2025 16:45:19 Mark Brown <broonie@kernel.org>:

> On Thu, Sep 25, 2025 at 11:37:39AM -0300, André Almeida wrote:
>> Em 25/09/2025 11:24, Mark Brown escreveu:
>
>>> It's not 100% clear to me that we should add this to the nolibc
>>> includes given that nolibc itself does not rely on or offer stdbool -
>>> I was going to send something out adjusting kselftest.h to unguard the
>>> include there.
>>
>> If we don't include stdbool.h here, it looks like
>> tools/include/nolibc/stdbool.h cannot be used by any test, and unguarding
>> <stdbool.h> would defeat the purpose of using -nolibc?
>
> Huh, I'd not seen that - generally stdbool.h comes from the compiler
> rather than libc so it didn't occur to me that nolibc would provide one.
> Looking at the compilers I have installed they all seem to be doing
> essentially the same thing (with some C++ handling).

-nostdinc also prevents the compiler from using its own headers, so we decided to have our own variant in nolibc.

(The same holds true for stdarg.h IIRC)

>> I'm also not 100% sure as well, lets see if Thomas or Willy can shine a
>> light here.
>
> Yeah, if we've got the nolibc one I guess we should use it in which case
> your patch is I guess what's expected.  I'll send out my version once my
> tests finish just in case.

Thanks!