While uncommon, nolibc executables can be linked together from multiple
compilation units.
Add some tests to make sure everything works in that case.
Signed-off-by: Thomas Weißschuh <[email protected]>
---
Note:
This depends on path "tools/nolibc: mark start_c as weak".
https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
---
tools/testing/selftests/nolibc/Makefile | 12 ++++-----
.../testing/selftests/nolibc/nolibc-test-linkage.c | 30 ++++++++++++++++++++++
.../testing/selftests/nolibc/nolibc-test-linkage.h | 9 +++++++
tools/testing/selftests/nolibc/nolibc-test.c | 4 +++
4 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
index af60e07d3c12..2600b4f3bed3 100644
--- a/tools/testing/selftests/nolibc/Makefile
+++ b/tools/testing/selftests/nolibc/Makefile
@@ -171,17 +171,17 @@ sysroot/$(ARCH)/include:
$(Q)mv sysroot/sysroot sysroot/$(ARCH)
ifneq ($(NOLIBC_SYSROOT),0)
-nolibc-test: nolibc-test.c sysroot/$(ARCH)/include
+nolibc-test: nolibc-test.c nolibc-test-linkage.c sysroot/$(ARCH)/include
$(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \
- -nostdlib -nostdinc -static -Isysroot/$(ARCH)/include $< -lgcc
+ -nostdlib -nostdinc -static -Isysroot/$(ARCH)/include nolibc-test.c nolibc-test-linkage.c -lgcc
else
-nolibc-test: nolibc-test.c
+nolibc-test: nolibc-test.c nolibc-test-linkage.c
$(QUIET_CC)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ \
- -nostdlib -static -include ../../../include/nolibc/nolibc.h $< -lgcc
+ -nostdlib -static -include ../../../include/nolibc/nolibc.h $< -lgcc nolibc-test.c nolibc-test-linkage.c -lgcc
endif
-libc-test: nolibc-test.c
- $(QUIET_CC)$(HOSTCC) -o $@ $<
+libc-test: nolibc-test.c nolibc-test-linkage.c
+ $(QUIET_CC)$(HOSTCC) -o $@ nolibc-test.c nolibc-test-linkage.c
# local libc-test
run-libc-test: libc-test
diff --git a/tools/testing/selftests/nolibc/nolibc-test-linkage.c b/tools/testing/selftests/nolibc/nolibc-test-linkage.c
new file mode 100644
index 000000000000..871db3d22713
--- /dev/null
+++ b/tools/testing/selftests/nolibc/nolibc-test-linkage.c
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include "nolibc-test-linkage.h"
+
+#ifndef NOLIBC
+#include <stdio.h>
+#ifndef _NOLIBC_STDIO_H
+/* standard libcs need more includes */
+#include <errno.h>
+#endif
+#endif
+
+void *linkage_test_errno_addr(void)
+{
+ return &errno;
+}
+
+int linkage_test_constructor_test_value;
+
+__attribute__((constructor))
+static void constructor1(void)
+{
+ linkage_test_constructor_test_value = 2;
+}
+
+__attribute__((constructor))
+static void constructor2(void)
+{
+ linkage_test_constructor_test_value *= 3;
+}
diff --git a/tools/testing/selftests/nolibc/nolibc-test-linkage.h b/tools/testing/selftests/nolibc/nolibc-test-linkage.h
new file mode 100644
index 000000000000..c66473070d73
--- /dev/null
+++ b/tools/testing/selftests/nolibc/nolibc-test-linkage.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _NOLIBC_TEST_LINKAGE_H
+#define _NOLIBC_TEST_LINKAGE_H
+
+void *linkage_test_errno_addr(void);
+extern int linkage_test_constructor_test_value;
+
+#endif /* _NOLIBC_TEST_LINKAGE_H */
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index 8da7f15d010e..2f10541e6f38 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -41,6 +41,8 @@
#endif
#endif
+#include "nolibc-test-linkage.h"
+
/* for the type of int_fast16_t and int_fast32_t, musl differs from glibc and nolibc */
#define SINT_MAX_OF_TYPE(type) (((type)1 << (sizeof(type) * 8 - 2)) - (type)1 + ((type)1 << (sizeof(type) * 8 - 2)))
#define SINT_MIN_OF_TYPE(type) (-SINT_MAX_OF_TYPE(type) - 1)
@@ -647,6 +649,8 @@ int run_startup(int min, int max)
CASE_TEST(auxv_addr); EXPECT_PTRGT(test_auxv != (void *)-1, test_auxv, brk); break;
CASE_TEST(auxv_AT_UID); EXPECT_EQ(1, getauxval(AT_UID), getuid()); break;
CASE_TEST(constructor); EXPECT_EQ(1, constructor_test_value, 2); break;
+ CASE_TEST(linkage_errno); EXPECT_PTREQ(1, linkage_test_errno_addr(), &errno); break;
+ CASE_TEST(linkage_constr); EXPECT_EQ(1, linkage_test_constructor_test_value, 6); break;
case __LINE__:
return ret; /* must be last */
/* note: do not set any defaults so as to permit holes above */
---
base-commit: e76716696ba0c5c41667a11caa092cd619a79c5b
change-id: 20231012-nolibc-linkage-test-48ebe6263feb
Best regards,
--
Thomas Weißschuh <[email protected]>
Hi Thomas,
On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Wei?schuh wrote:
> While uncommon, nolibc executables can be linked together from multiple
> compilation units.
> Add some tests to make sure everything works in that case.
(...)
Glad you did these two. Your approach is good and it remains easy to
use and should catch next breakage in this area.
> Signed-off-by: Thomas Wei?schuh <[email protected]>
> ---
> Note:
>
> This depends on path "tools/nolibc: mark start_c as weak".
> https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
For these two patches: Acked-by: Willy Tarreau <[email protected]>
Thanks
Willy
Hi Willy, Paul,
On 2023-10-12 09:06:33+0200, Willy Tarreau wrote:
> On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Weißschuh wrote:
> > While uncommon, nolibc executables can be linked together from multiple
> > compilation units.
> > Add some tests to make sure everything works in that case.
> (...)
[..]
> > Signed-off-by: Thomas Weißschuh <[email protected]>
> > ---
> > Note:
> >
> > This depends on path "tools/nolibc: mark start_c as weak".
> > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
>
> For these two patches: Acked-by: Willy Tarreau <[email protected]>
Thanks, applied locally.
I guess the linked patch "tools/nolibc: mark start_c as weak" should
also go into nolibc/fixes.
@Paul, would it introduce too much churn for you if I submit another
nolibc pull with an updated nolibc/fixes?
(And the rebased nolibc/next with this commit while we are at it)
Thomas
On Thu, Oct 12, 2023 at 09:23:29AM +0200, Thomas Wei?schuh wrote:
> Hi Willy, Paul,
>
> On 2023-10-12 09:06:33+0200, Willy Tarreau wrote:
> > On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Wei?schuh wrote:
> > > While uncommon, nolibc executables can be linked together from multiple
> > > compilation units.
> > > Add some tests to make sure everything works in that case.
> > (...)
>
> [..]
>
> > > Signed-off-by: Thomas Wei?schuh <[email protected]>
> > > ---
> > > Note:
> > >
> > > This depends on path "tools/nolibc: mark start_c as weak".
> > > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
> >
> > For these two patches: Acked-by: Willy Tarreau <[email protected]>
>
> Thanks, applied locally.
>
> I guess the linked patch "tools/nolibc: mark start_c as weak" should
> also go into nolibc/fixes.
>
> @Paul, would it introduce too much churn for you if I submit another
> nolibc pull with an updated nolibc/fixes?
> (And the rebased nolibc/next with this commit while we are at it)
Not a problem this week!
But after about Wednesday of next week, getting things into the upcoming
merge window is pretty much as fast as sending them quickly to Linus,
if that makes sense. Unless there is to be a -rc8 this time, but I
have heard no sign of that.
Make sense?
Thanx, Paul
On 2023-10-12 03:41:50-0700, Paul E. McKenney wrote:
> On Thu, Oct 12, 2023 at 09:23:29AM +0200, Thomas Weißschuh wrote:
> > Hi Willy, Paul,
> >
> > On 2023-10-12 09:06:33+0200, Willy Tarreau wrote:
> > > On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Weißschuh wrote:
> > > > While uncommon, nolibc executables can be linked together from multiple
> > > > compilation units.
> > > > Add some tests to make sure everything works in that case.
> > > (...)
> >
> > [..]
> >
> > > > Signed-off-by: Thomas Weißschuh <[email protected]>
> > > > ---
> > > > Note:
> > > >
> > > > This depends on path "tools/nolibc: mark start_c as weak".
> > > > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
> > >
> > > For these two patches: Acked-by: Willy Tarreau <[email protected]>
> >
> > Thanks, applied locally.
> >
> > I guess the linked patch "tools/nolibc: mark start_c as weak" should
> > also go into nolibc/fixes.
> >
> > @Paul, would it introduce too much churn for you if I submit another
> > nolibc pull with an updated nolibc/fixes?
> > (And the rebased nolibc/next with this commit while we are at it)
>
> Not a problem this week!
Great, then:
Please pull the changes since the v6.6-rc1 tag from
https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
The branch 'fixes' up to and including
90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle.
The branch 'next' up to and including
f2c7923763dae51226584494722349fef4df3748 for linux-next.
The branch 'next', based upon 'fixes', was tested as follows:
i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> But after about Wednesday of next week, getting things into the upcoming
> merge window is pretty much as fast as sending them quickly to Linus,
> if that makes sense. Unless there is to be a -rc8 this time, but I
> have heard no sign of that.
>
> Make sense?
Sure, hopefully no more fixes are needed!
Thanks,
Thomas
On Thu, Oct 12, 2023 at 12:51:28PM +0200, Thomas Wei?schuh wrote:
> On 2023-10-12 03:41:50-0700, Paul E. McKenney wrote:
> > On Thu, Oct 12, 2023 at 09:23:29AM +0200, Thomas Wei?schuh wrote:
> > > Hi Willy, Paul,
> > >
> > > On 2023-10-12 09:06:33+0200, Willy Tarreau wrote:
> > > > On Thu, Oct 12, 2023 at 01:13:37AM +0200, Thomas Wei?schuh wrote:
> > > > > While uncommon, nolibc executables can be linked together from multiple
> > > > > compilation units.
> > > > > Add some tests to make sure everything works in that case.
> > > > (...)
> > >
> > > [..]
> > >
> > > > > Signed-off-by: Thomas Wei?schuh <[email protected]>
> > > > > ---
> > > > > Note:
> > > > >
> > > > > This depends on path "tools/nolibc: mark start_c as weak".
> > > > > https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
> > > >
> > > > For these two patches: Acked-by: Willy Tarreau <[email protected]>
> > >
> > > Thanks, applied locally.
> > >
> > > I guess the linked patch "tools/nolibc: mark start_c as weak" should
> > > also go into nolibc/fixes.
> > >
> > > @Paul, would it introduce too much churn for you if I submit another
> > > nolibc pull with an updated nolibc/fixes?
> > > (And the rebased nolibc/next with this commit while we are at it)
> >
> > Not a problem this week!
>
> Great, then:
>
> Please pull the changes since the v6.6-rc1 tag from
> https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
>
> The branch 'fixes' up to and including
> 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle.
>
> The branch 'next' up to and including
> f2c7923763dae51226584494722349fef4df3748 for linux-next.
>
> The branch 'next', based upon 'fixes', was tested as follows:
>
> i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
please check the lead-in text for sanity. (Everything after the digital
signature is automatically generated.)
Testing for urgent/nolibc.2023.10.12a:
make run: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success
make run-user: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning
Testing for full nolibc stack:
make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
make run-user: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning
> > But after about Wednesday of next week, getting things into the upcoming
> > merge window is pretty much as fast as sending them quickly to Linus,
> > if that makes sense. Unless there is to be a -rc8 this time, but I
> > have heard no sign of that.
> >
> > Make sense?
>
> Sure, hopefully no more fixes are needed!
Ah, and have these been posted to a public mailing list? If not, then I
need to send them out.
We reset the -next testing clock, so if all goes well, then I send the
three urgent commits to Linus on Monday.
Thanx, Paul
On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> [..]
> > Please pull the changes since the v6.6-rc1 tag from
> > https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
> >
> > The branch 'fixes' up to and including
> > 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle.
> >
> > The branch 'next' up to and including
> > f2c7923763dae51226584494722349fef4df3748 for linux-next.
> >
> > The branch 'next', based upon 'fixes', was tested as follows:
> >
> > i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> > ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> > loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
>
> I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> please check the lead-in text for sanity. (Everything after the digital
> signature is automatically generated.)
Looks good. But it's only a listing of the commit subjects, correct?
> Testing for urgent/nolibc.2023.10.12a:
> make run: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success
> make run-user: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning
>
> Testing for full nolibc stack:
> make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> make run-user: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning
>
> > > But after about Wednesday of next week, getting things into the upcoming
> > > merge window is pretty much as fast as sending them quickly to Linus,
> > > if that makes sense. Unless there is to be a -rc8 this time, but I
> > > have heard no sign of that.
> > >
> > > Make sense?
> >
> > Sure, hopefully no more fixes are needed!
>
> Ah, and have these been posted to a public mailing list? If not, then I
> need to send them out.
All patches went through the lists as part of the normal developent
flow. They were not posted after rebasing.
For transparency I did the following follow-up changes:
* The rebase of "tools/nolibc: mark start_c as weak" required some
minor changes to resolve conflicts.
* reword the message of
"tools/nolibc: drop test for getauxval(AT_PAGESZ)" slightly.
* simplify the includes intruduced by
"selftests/nolibc: add tests for multi-object linkage".
> We reset the -next testing clock, so if all goes well, then I send the
> three urgent commits to Linus on Monday.
Sounds good, thanks!
Thomas
On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Wei?schuh wrote:
> On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> > [..]
>
> > > Please pull the changes since the v6.6-rc1 tag from
> > > https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
> > >
> > > The branch 'fixes' up to and including
> > > 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a for the v6.6 cycle.
> > >
> > > The branch 'next' up to and including
> > > f2c7923763dae51226584494722349fef4df3748 for linux-next.
> > >
> > > The branch 'next', based upon 'fixes', was tested as follows:
> > >
> > > i386: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > x86_64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > arm64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > arm: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > mips: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> > > ppc: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > ppc64: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > ppc64le: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > riscv: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > > s390: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> > > loongarch: 162 test(s): 161 passed, 1 skipped, 0 failed => status: warning
> >
> > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> > please check the lead-in text for sanity. (Everything after the digital
> > signature is automatically generated.)
>
> Looks good. But it's only a listing of the commit subjects, correct?
Pretty close, just a few added words on the last one.
So the question is whether there is some larger issue that Linus should
be made aware of. If these are just simple fixes for simple bugs,
we should be good, but yes, I do need to ask. ;-)
> > Testing for urgent/nolibc.2023.10.12a:
> > make run: 160 test(s): 160 passed, 0 skipped, 0 failed => status: success
> > make run-user: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning
> >
> > Testing for full nolibc stack:
> > make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> > make run-user: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning
> >
> > > > But after about Wednesday of next week, getting things into the upcoming
> > > > merge window is pretty much as fast as sending them quickly to Linus,
> > > > if that makes sense. Unless there is to be a -rc8 this time, but I
> > > > have heard no sign of that.
> > > >
> > > > Make sense?
> > >
> > > Sure, hopefully no more fixes are needed!
> >
> > Ah, and have these been posted to a public mailing list? If not, then I
> > need to send them out.
>
> All patches went through the lists as part of the normal developent
> flow. They were not posted after rebasing.
I have been sending the group, so I might as well continue the tradition.
There are a couple of substantive checkpatch complaints:
4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack misalign bug on _start")
The Fixes SHA-1 should be limited to 12 hex digits.
(I am ignoring this, but be prepared for Linus to gripe.
If you decide to fix it, I would be happy to repull.)
f2c7923763da ("selftests/nolibc: add tests for multi-object linkage")
nolibc-test-linkage.c and nolibc-test-linkage.h need
"//" comment for the SPDX comment header. This one needs
to be fixed, but this is not in the urgent stack, so there
is some time.
> For transparency I did the following follow-up changes:
>
> * The rebase of "tools/nolibc: mark start_c as weak" required some
> minor changes to resolve conflicts.
> * reword the message of
> "tools/nolibc: drop test for getauxval(AT_PAGESZ)" slightly.
> * simplify the includes intruduced by
> "selftests/nolibc: add tests for multi-object linkage".
Sounds good!
Thanx, Paul
> > We reset the -next testing clock, so if all goes well, then I send the
> > three urgent commits to Linus on Monday.
>
> Sounds good, thanks!
>
> Thomas
On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote:
> On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote:
> > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> > > [..]
> > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> > > please check the lead-in text for sanity. (Everything after the digital
> > > signature is automatically generated.)
> >
> > Looks good. But it's only a listing of the commit subjects, correct?
>
> Pretty close, just a few added words on the last one.
>
> So the question is whether there is some larger issue that Linus should
> be made aware of. If these are just simple fixes for simple bugs,
> we should be good, but yes, I do need to ask. ;-)
These are simple fixes for simple bugs.
Do you always have to ask specifically or can I just mention it in the
pull request in the future?
> [..]
> > > Ah, and have these been posted to a public mailing list? If not, then I
> > > need to send them out.
> >
> > All patches went through the lists as part of the normal developent
> > flow. They were not posted after rebasing.
>
> I have been sending the group, so I might as well continue the tradition.
Sounds good. If you want me to do something different, please let me
know.
> There are a couple of substantive checkpatch complaints:
>
> 4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack misalign bug on _start")
> The Fixes SHA-1 should be limited to 12 hex digits.
> (I am ignoring this, but be prepared for Linus to gripe.
> If you decide to fix it, I would be happy to repull.)
Done.
> f2c7923763da ("selftests/nolibc: add tests for multi-object linkage")
> nolibc-test-linkage.c and nolibc-test-linkage.h need
> "//" comment for the SPDX comment header. This one needs
> to be fixed, but this is not in the urgent stack, so there
> is some time.
nolibc limits itself intentionally to C89 language level which disallows
C++ style headers.
This should be covered by Documentation/process/license-rules.rst:
If a specific tool cannot handle the standard comment style, then the
appropriate comment mechanism which the tool accepts shall be used.
With that said:
Please pull the changes since the v6.6-rc1 tag from
https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
The branch 'fixes' up to and including
921992229b1f06df6b649860e4a5f3def1489866 for the v6.6 cycle.
The branch 'next' up to and including
b8c60e8fc6f755c2cdf7164931afdbfa670c6646 for linux-next.
No full test has been performed as only a commit message was changed.
Testing for full nolibc stack:
make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
make run-nolibc-test: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning
Thomas
On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Wei?schuh wrote:
> On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote:
> > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Wei?schuh wrote:
> > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> > > > [..]
>
> > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> > > > please check the lead-in text for sanity. (Everything after the digital
> > > > signature is automatically generated.)
> > >
> > > Looks good. But it's only a listing of the commit subjects, correct?
> >
> > Pretty close, just a few added words on the last one.
> >
> > So the question is whether there is some larger issue that Linus should
> > be made aware of. If these are just simple fixes for simple bugs,
> > we should be good, but yes, I do need to ask. ;-)
>
> These are simple fixes for simple bugs.
>
> Do you always have to ask specifically or can I just mention it in the
> pull request in the future?
I would be extremely happy to simply copy text from the pull request
into the signed tags. ;-)
We would just need to agree on the format. For example, in this case,
there will eventually be two signed tags, one for the urgent pull
request early next week and another for the pull request for the upcoming
merge window.
Proposals for the format?
> > [..]
>
> > > > Ah, and have these been posted to a public mailing list? If not, then I
> > > > need to send them out.
> > >
> > > All patches went through the lists as part of the normal developent
> > > flow. They were not posted after rebasing.
> >
> > I have been sending the group, so I might as well continue the tradition.
>
> Sounds good. If you want me to do something different, please let me
> know.
>
> > There are a couple of substantive checkpatch complaints:
> >
> > 4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack misalign bug on _start")
> > The Fixes SHA-1 should be limited to 12 hex digits.
> > (I am ignoring this, but be prepared for Linus to gripe.
> > If you decide to fix it, I would be happy to repull.)
>
> Done.
Very good, thank you!
> > f2c7923763da ("selftests/nolibc: add tests for multi-object linkage")
> > nolibc-test-linkage.c and nolibc-test-linkage.h need
> > "//" comment for the SPDX comment header. This one needs
> > to be fixed, but this is not in the urgent stack, so there
> > is some time.
>
> nolibc limits itself intentionally to C89 language level which disallows
> C++ style headers.
>
> This should be covered by Documentation/process/license-rules.rst:
>
> If a specific tool cannot handle the standard comment style, then the
> appropriate comment mechanism which the tool accepts shall be used.
I stand corrected, and thank you!
> With that said:
>
> Please pull the changes since the v6.6-rc1 tag from
> https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
>
> The branch 'fixes' up to and including
> 921992229b1f06df6b649860e4a5f3def1489866 for the v6.6 cycle.
>
> The branch 'next' up to and including
> b8c60e8fc6f755c2cdf7164931afdbfa670c6646 for linux-next.
>
> No full test has been performed as only a commit message was changed.
>
> Testing for full nolibc stack:
> make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> make run-nolibc-test: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning
I will pull this in, thank you!
Thanx, Paul
On Thu, Oct 12, 2023 at 01:18:18PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Wei?schuh wrote:
> > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote:
> > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Wei?schuh wrote:
> > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> > > > > [..]
> >
> > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> > > > > please check the lead-in text for sanity. (Everything after the digital
> > > > > signature is automatically generated.)
> > > >
> > > > Looks good. But it's only a listing of the commit subjects, correct?
> > >
> > > Pretty close, just a few added words on the last one.
> > >
> > > So the question is whether there is some larger issue that Linus should
> > > be made aware of. If these are just simple fixes for simple bugs,
> > > we should be good, but yes, I do need to ask. ;-)
> >
> > These are simple fixes for simple bugs.
> >
> > Do you always have to ask specifically or can I just mention it in the
> > pull request in the future?
>
> I would be extremely happy to simply copy text from the pull request
> into the signed tags. ;-)
>
> We would just need to agree on the format. For example, in this case,
> there will eventually be two signed tags, one for the urgent pull
> request early next week and another for the pull request for the upcoming
> merge window.
>
> Proposals for the format?
Actually, proposals for the signed-tag text for the urgent commits?
Left to myself, I would use the same text shown below that I proposed
last week.
Thanx, Paul
------------------------------------------------------------------------
tag urgent/nolibc.2023.10.12a
Tagger: Paul E. McKenney <[email protected]>
Date: Thu Oct 12 10:50:08 2023 -0700
Urgent pull request for nolibc into v6.6
This pull request contains the following fixes:
o tools/nolibc: i386: Fix a stack misalign bug on _start
o MAINTAINERS: nolibc: update tree location
o tools/nolibc: mark start_c as weak to avoid linker errors
MAINTAINERS | 2 +-
tools/include/nolibc/arch-i386.h | 4 +++-
tools/include/nolibc/crt.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEbK7UrM+RBIrCoViJnr8S83LZ+4wFAmUoMqATHHBhdWxtY2tA
a2VybmVsLm9yZwAKCRCevxLzctn7jAE9D/9aa/OzGPI9VFKcN1gIW8dYJnXvSI3n
+gUMjRhlWnx2DBxBkpg7jmiPUXySlsOzHoo9sgtMuOVXhkdmODZ5RL7drKJXNqxs
xmpb70mftOtj/+qx3CEj71K45t5pkwidRTwOuwcNGOGM4xb6sw7kVCWinsKGSPjh
l8pcJxquY2ZcKKp1OciT37IYw6AcWUz4v/JCeKLOg9FFlxIrenR56u41f7OR0GM/
D1kggSHuwAk+b0BmnUXEig2Ys0bORZ1sRQnTHjQEmba4kr41DzarwdIXMU2LUS3m
dIxTtSs8kRSRZ21A9rGNEnezwZaYVdRraH3LQcDYQ4lsaccZc7xUICzHwj/DVri1
PkHVrZzii/PZGIADLYEn1ob9PjbuPXbpf6p1xZsnOCaKv1n4DcG2fHsIsCTptHkr
qT8+DDu2x74WiD+lAaEuOJV1UeCDjQrTyrK2Impvg1af/d0xS6hUvDeap09OhLpW
odLgtpO5xRLsWFrKl/FGCZIsLXUkvpn3F2FfU3nLgFWMFiuw6Nkk+hLlr34WqTGs
A+LRYktd8moFPJRzUhgOr1jZpy8SUhs3MRWlfJ3I3FHQvCYFDX95xHsl5brZ3Vkp
UAfRPpJmJYfIzhfj7kQZQFJ+mCIfRI0jb+6VyF/u9/MaicfMes4YlUwKEUGBbx+f
rrUmEilQCZd3Sw==
=Wnux
-----END PGP SIGNATURE-----
commit 90864f0679fdbb3b2e1c3bdbe4b0a34df785cb0a
Author: Thomas Wei?schuh <[email protected]>
Date: Thu Oct 12 00:37:38 2023 +0200
tools/nolibc: mark start_c as weak
Otherwise the different instances of _start_c from each compilation unit
will lead to linker errors:
/usr/bin/ld: /tmp/ccSNvRqs.o: in function `_start_c':
nolibc-test-foo.c:(.text.nolibc_memset+0x9): multiple definition of `_start_c'; /tmp/ccG25101.o:nolibc-test.c:(.text+0x1ea3): first defined here
Fixes: 17336755150b ("tools/nolibc: add new crt.h with _start_c")
Signed-off-by: Thomas Wei?schuh <[email protected]>
Link: https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
Link: https://lore.kernel.org/lkml/[email protected]/
Acked-by: Willy Tarreau <[email protected]>
diff --git a/tools/include/nolibc/crt.h b/tools/include/nolibc/crt.h
index a5f33fef1672..a05655b4ce1d 100644
--- a/tools/include/nolibc/crt.h
+++ b/tools/include/nolibc/crt.h
@@ -13,6 +13,7 @@ const unsigned long *_auxv __attribute__((weak));
static void __stack_chk_init(void);
static void exit(int);
+__attribute__((weak))
void _start_c(long *sp)
{
long argc;
On 2023-10-16 09:24:19-0700, Paul E. McKenney wrote:
> On Thu, Oct 12, 2023 at 01:18:18PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Weißschuh wrote:
> > > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote:
> > > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote:
> > > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> > > > > > [..]
> > >
> > > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> > > > > > please check the lead-in text for sanity. (Everything after the digital
> > > > > > signature is automatically generated.)
> > > > >
> > > > > Looks good. But it's only a listing of the commit subjects, correct?
> > > >
> > > > Pretty close, just a few added words on the last one.
> > > >
> > > > So the question is whether there is some larger issue that Linus should
> > > > be made aware of. If these are just simple fixes for simple bugs,
> > > > we should be good, but yes, I do need to ask. ;-)
> > >
> > > These are simple fixes for simple bugs.
> > >
> > > Do you always have to ask specifically or can I just mention it in the
> > > pull request in the future?
> >
> > I would be extremely happy to simply copy text from the pull request
> > into the signed tags. ;-)
> >
> > We would just need to agree on the format. For example, in this case,
> > there will eventually be two signed tags, one for the urgent pull
> > request early next week and another for the pull request for the upcoming
> > merge window.
> >
> > Proposals for the format?
>
> Actually, proposals for the signed-tag text for the urgent commits?
> Left to myself, I would use the same text shown below that I proposed
> last week.
Looks good.
The tags for urgent PRs seem good with one item per patch.
I guess for normal PRs one item per series would be fine.
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> tag urgent/nolibc.2023.10.12a
> Tagger: Paul E. McKenney <[email protected]>
> Date: Thu Oct 12 10:50:08 2023 -0700
>
> Urgent pull request for nolibc into v6.6
>
> This pull request contains the following fixes:
>
> o tools/nolibc: i386: Fix a stack misalign bug on _start
>
> o MAINTAINERS: nolibc: update tree location
>
> o tools/nolibc: mark start_c as weak to avoid linker errors
> [..]
On Tue, Oct 17, 2023 at 12:03:41AM +0200, Thomas Wei?schuh wrote:
> On 2023-10-16 09:24:19-0700, Paul E. McKenney wrote:
> > On Thu, Oct 12, 2023 at 01:18:18PM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Wei?schuh wrote:
> > > > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote:
> > > > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Wei?schuh wrote:
> > > > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> > > > > > > [..]
> > > >
> > > > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> > > > > > > please check the lead-in text for sanity. (Everything after the digital
> > > > > > > signature is automatically generated.)
> > > > > >
> > > > > > Looks good. But it's only a listing of the commit subjects, correct?
> > > > >
> > > > > Pretty close, just a few added words on the last one.
> > > > >
> > > > > So the question is whether there is some larger issue that Linus should
> > > > > be made aware of. If these are just simple fixes for simple bugs,
> > > > > we should be good, but yes, I do need to ask. ;-)
> > > >
> > > > These are simple fixes for simple bugs.
> > > >
> > > > Do you always have to ask specifically or can I just mention it in the
> > > > pull request in the future?
> > >
> > > I would be extremely happy to simply copy text from the pull request
> > > into the signed tags. ;-)
> > >
> > > We would just need to agree on the format. For example, in this case,
> > > there will eventually be two signed tags, one for the urgent pull
> > > request early next week and another for the pull request for the upcoming
> > > merge window.
> > >
> > > Proposals for the format?
> >
> > Actually, proposals for the signed-tag text for the urgent commits?
> > Left to myself, I would use the same text shown below that I proposed
> > last week.
>
> Looks good.
>
> The tags for urgent PRs seem good with one item per patch.
You got it! urgent/nolibc.2023.10.16a
> I guess for normal PRs one item per series would be fine.
That makes a lot of sense -- with a non-urgent series, there should be
some sort of development theme. I immediately see the list shown below.
Please let me know of any needed adjustments.
Thanx, Paul
------------------------------------------------------------------------
Add stdarg.h.
Optimize x86 string functions and remove unused internal functions.
Adjust compiler flags to avoid accidental reliance on system header files,
to avoid false-positive warnings, and to allow building 32-bit i386 with
multi-architecture compilers.
Pass initrd to qemu separately from the kernel image to avoid needless
kernel relinks. Make ppc64le use qemu-system-ppc64 in order to provide
bi-endian support.
Create varargs __nolibc_enosys() function to avoid false-positive
compiler warnings for unimplemented system calls. Rely on kernel
system-call-number definitions to avoid breaking common-code userspace.
Automatrically determine whether pselect6() is required to avoid a bit of
manual coding. Add support for C-language constructors and destructors.
Drop redundant tests. Add tests for nolibc programs having multiple
.o files.