Build H2 with Picolibc

[quic-k]

No description provided.

[colmode]

Looks good overall, but we might want to merge this after erich's makefile changes rather than the other way around.

[quic-k]

we can, but since we are not including any C header, we don't have __PICOLIBC__
so for simplicity I created 2 files

maybe I will have to use the PICOLIBC=1 flag to define a macro, which we can use
or do you have something else in mind?

[bryanb-h2]

"PICOLIBC=1 flag to define a macro", yes. But since this is all transitional and we'll eventually use only pico I think that leaving it as is would be fine.

[quic-k]

we can, but since we are not including any C header, we don't have __PICOLIBC__
so for simplicity I created 2 files

maybe I will have to use the PICOLIBC=1 flag to define a macro, which we can use
or do you have something else in mind?

[quic-k]

Looks good overall, but we might want to merge this after erich's makefile changes rather than the other way around.

thanks for the review, ping me whenever that is merged, I will have to resolve merge conflicts

Also, we don't yet have a way to run unit tests with pico since those tools aren't on github. Best to run make testall locally and then comment here when it passes.

sure, so far I have built H2 successfully and used the install artifacts to run Picolibc testsuite which passes
will look into getting H2 unit tests working with Picolibc

[bryanb-h2]

Looks good overall, but we might want to merge this after erich's makefile changes rather than the other way around.

Hey, look; our first comment from a non-qc account :)

[quic-k]

why is hexagon_standalone.h being used? @bryanb-h2

hexagon-hypervisor/kernel/util/stmode/test/test.c

Line 12 in f74ebc7

#include <hexagon_standalone.h>

hexagon-hypervisor/kernel/util/spinlock/test/test.c

Line 10 in f74ebc7

#include <hexagon_standalone.h>

[bryanb-h2]

why is hexagon_standalone.h being used? @bryanb-h2

hexagon-hypervisor/kernel/util/stmode/test/test.c

Line 12 in f74ebc7

#include <hexagon_standalone.h>

hexagon-hypervisor/kernel/util/spinlock/test/test.c

Line 10 in f74ebc7

#include <hexagon_standalone.h>

Because most of the unit tests run with standalone with a test harness for testing only one function -- avoids booting the kernel to simplify debug. We need a substitute for standalone but we haven't addressed this yet. The unit tests don't even use features of standalone. Using the default dinkum build is just a convenient way to link with crt0 and get to main(). We actually have a min_crt0 in the h2 repo. Just need to dust that off and change how we link unit tests.

Here it is, entirely:

/*

• Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.

• SPDX-License-Identifier: BSD-3-Clause-Clear
  */

  .section .start,"awx",@progbits

.global _start

.global hexagon_pre_main

#_start:

jump start

hexagon_pre_main:
r0 = ##SDA_BASE
gp = r0
r29 = ##stack
{
r0 = r29
r1 = #1
call main
}

jump start

.data
.p2align 8
.space 1024

stack:
.word stack
.word 0

[quic-k]

Because most of the unit tests run with standalone with a test harness for testing only one function -- avoids booting the kernel to simplify debug.

yeah, for debugging that is better, but booter tests would have been easier for me to get passing

We need a substitute for standalone but we haven't addressed this yet. The unit tests don't even use features of standalone. Using the default dinkum build is just a convenient way to link with crt0 and get to main(). We actually have a min_crt0 in the h2 repo. Just need to dust that off and change how we link unit tests.

is this planned to be done soon? or am I supposed to do this in this PR? maybe I could but this sounds like lot of debugging
:\

[bryanb-h2]

Because most of the unit tests run with standalone with a test harness for testing only one function -- avoids booting the kernel to simplify debug.

yeah, for debugging that is better, but booter tests would have been easier for me to get passing

We need a substitute for standalone but we haven't addressed this yet. The unit tests don't even use features of standalone. Using the default dinkum build is just a convenient way to link with crt0 and get to main(). We actually have a min_crt0 in the h2 repo. Just need to dust that off and change how we link unit tests.

is this planned to be done soon? or am I supposed to do this in this PR? maybe I could but this sounds like lot of debugging :\

Not unless you're really keen to do it. I just filed QDSP-57392 for this.