[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
quic-k wrote: > There are some restrictions on what MUSL supports for example ifunc support > https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/TargetInfo.h#L1578 > > I agree that there isn't any defined rules for when an environment is the > right answer or not. There was some concern raised at the dev meeting about > the number of possible bare-metal C-libraries that exist and could have > environments added for them. I think it would be reasonable to say picolibc, > newlib and llvmlibc. > > > Instead of switching include and library directories for a specific > environment then you have a single -I and -L directory structure (shared > between C-libraries) and then change sysroot to switch between C libraries. > We support newlib and LLVM libc as an overlay package by installing a > sysroot. We then have a config file that sets the sysroot and the same driver > works for all 3. > > That wouldn't require a new environment per C-library, just a change of > sysroot. > > > Yes, I think there is scope to do this better, although for most Drivers the > choice of semihosting or not is independent of the environment. Production = > no semihosting (no argc/argv and debug IO interface), development = > semihosting. Picolibc's default is production with crt0.o no semihosting. It > looks like you want to default to semihosting. > > There's always two environments picolibc and picolibc-semihosting but it > seems like we're just putting too much into the environment. > > > Main reason to split it out into two PRs is that there's two separate > decisions here: > > * Should we add an environment for Picolibc that can be used by any > Driver? > > * What should the Hexagon driver do with the Picolibc environment? > > > I can much more easily contribute to reviews that could affect an Arm target. > Decisions that are specific to the Hexagon driver are much harder for me to > contribute to (as an Arm employee). It may be easier to get approval for the > two independently as a smaller number of people are likely to be concerned > about Hexagon specific changes. > > I don't think you need to split it, if I'm the only one bothered about it. I > just won't be able to comment on anything beyond the environment parts. > > To summarise: > > * The main downside of adding a picolibc environment is that we'll likely > end up with several more environments, I think newlib, newlib-nano and > LLVM-libc are likely. > this is true, if we add Picolibc as enviroment type, we will need to add other libc implementations as well, when needed > * I think that there are ways to add support for picolibc without using > an environment. That would avoid the concern above, for now at least, but I > acknowledge that there are design trade-offs that may prefer an environment. again true, alternative is that user specifies sysroot, crt files, semihost/OS lib explicitly in the command adding libc to environment or adding a --libc flag will allow the user to switch libraries, I hope other toolchains would want this as well, ARM embedded is one of the major ones > * I don't/can't have an opinion on the Hexagon specific parts of the PR. I will move out the hexagon bits to a separate PR so reviewers can focus on both parts separately > * If there is a consensus is that adding an environment for bare-metal > C-library is fine, then I don't have any objections, it is not much extra > code and there are already examples in the hosted area. any idea who else we can add here to reach this consensus? https://github.com/llvm/llvm-project/pull/169613 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
smithp35 wrote: > thanks for review @smithp35 > > > Not knowing the hexagon toolchain, I can't give you any useful comments on > > that part of the review. Based on our experience of Picolibc in the > > baremetal driver the question I have for you is whether there is enough > > picolibc specific details here to justify a specific picolibc environment. > > picolibc enviroment is right now used to set -I and -L paths, and we add > crt0-semihost and -lsemihost that we get from Picolibc, I don't know if this > is enough to justify a new environment. But what else is Musl environment > used for apart from what I listed? > There are some restrictions on what MUSL supports for example ifunc support https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/TargetInfo.h#L1578 I agree that there isn't any defined rules for when an environment is the right answer or not. There was some concern raised at the dev meeting about the number of possible bare-metal C-libraries that exist and could have environments added for them. I think it would be reasonable to say picolibc, newlib and llvmlibc. > > It looks like the majority of the extra configuration that you are adding > > is not specific to picolibc, but could also apply to other bare-metal > > C-libraries like llvm libc and newlib. About the only thing that I can see > > that is Picolibc specific is adding crt-semihost.o for the startfiles. > > Would it be better to add this as a bare-metal configuration, not specific > > to picolibc, then you wouldn't need a new environment when changing > > C-library? > > sry, I don't get what you mean my "add this as bare-metal configuration", the > idea for adding this triple was so that C libraries can co-exist and can be > switch by just switching the triple from say : hexagon-none-picolibc to > hexagon-none-llvmlibc we would point -I and -L flags to the different dirs > based on the environment, and add crt and other files > Instead of switching include and library directories for a specific environment then you have a single -I and -L directory structure (shared between C-libraries) and then change sysroot to switch between C libraries. We support newlib and LLVM libc as an overlay package by installing a sysroot. We then have a config file that sets the sysroot and the same driver works for all 3. That wouldn't require a new environment per C-library, just a change of sysroot. > > FWIW. We require our users to use `-nostartfiles -lcrt-semihost` if they > > prefer the semihosting startup code (with semihosted argc, argv and return) > > and `lsemihost` for the semihost implementation. > > I did check > https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/blob/main/docs/newlib.md, > I like the idea of pointing to correct sysroot using .cfg file, but isn't > adding crt/semihost libs too much work for users? wouldn't it be better if > the user can just specify triple or/and --libc flag and clang driver takes > care of everything else? > Yes, I think there is scope to do this better, although for most Drivers the choice of semihosting or not is independent of the environment. Production = no semihosting (no argc/argv and debug IO interface), development = semihosting. Picolibc's default is production with crt0.o no semihosting. It looks like you want to default to semihosting. There's always two environments picolibc and picolibc-semihosting but it seems like we're just putting too much into the environment. > > It may also be useful to respond to > > https://discourse.llvm.org/t/rfc-add-command-line-option-for-selecting-c-library/87335 > > as the environment part is acting that way. > > --libc flag would have been perfect for our usecase, but I don't know if this > is going to go in. if we could simply use `libc.isPicolibc()` instead of > `triple.isPicolibc()`, that would have been great > > > While I don't have any strong objections to adding picolibc as an > > evironment, there was some pushback to the RFC as there were so many > > bare-metal C-libraries, do we end up with an environment for each of them? > > With that in mind it may be better to split the generic triple parts out > > into a separate patch, to get more opinions on whether it is the right > > thing to do. > > I have split it into 2 commits, do you prefer it to be a separate PR instead? Main reason to split it out into two PRs is that there's two separate decisions here: * Should we add an environment for Picolibc that can be used by any Driver? * What should the Hexagon driver do with the Picolibc environment? I can much more easily contribute to reviews that could affect an Arm target. Decisions that are specific to the Hexagon driver are much harder for me to contribute to (as an Arm employee). It may be easier to get approval for the two independently as a smaller number of people are likely to be concerned about Hexagon specific changes. I don't think you nee
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
https://github.com/quic-k updated
https://github.com/llvm/llvm-project/pull/169613
>From 767ef0ae4193335ebf5bf0a9a01a94d3c64052b2 Mon Sep 17 00:00:00 2001
From: Kushal Pal
Date: Tue, 9 Dec 2025 11:37:25 +0530
Subject: [PATCH 1/2] [Clang] Add Picolibc environment type for triples
Introduce `EnvironmentType::Picolibc` so that LLVM triples can
explicitly represent targets using Picolibc.
Signed-off-by: Kushal Pal
---
llvm/include/llvm/TargetParser/Triple.h | 4
llvm/lib/TargetParser/Triple.cpp| 3 +++
2 files changed, 7 insertions(+)
diff --git a/llvm/include/llvm/TargetParser/Triple.h
b/llvm/include/llvm/TargetParser/Triple.h
index 11b76cd183108..8728288f3538a 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -280,6 +280,7 @@ class Triple {
MuslX32,
MuslWALI,
LLVM,
+Picolibc,
MSVC,
Itanium,
@@ -866,6 +867,9 @@ class Triple {
getEnvironment() == Triple::OpenHOS || isOSLiteOS();
}
+ // Tests whether the environment is picolibc
+ bool isPicolibc() const { return getEnvironment() == Triple::Picolibc; }
+
/// Tests whether the target is OHOS
/// LiteOS default enviroment is also OHOS, but omited on triple.
bool isOHOSFamily() const { return isOpenHOS() || isOSLiteOS(); }
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 11ba9ee32f66a..de9ea67bde939 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -378,6 +378,8 @@ StringRef Triple::getEnvironmentTypeName(EnvironmentType
Kind) {
case MuslWALI:
return "muslwali";
case Simulator: return "simulator";
+ case Picolibc:
+return "picolibc";
case Pixel: return "pixel";
case Vertex: return "vertex";
case Geometry: return "geometry";
@@ -747,6 +749,7 @@ static Triple::OSType parseOS(StringRef OSName) {
static Triple::EnvironmentType parseEnvironment(StringRef EnvironmentName) {
return StringSwitch(EnvironmentName)
+ .StartsWith("picolibc", Triple::Picolibc)
.StartsWith("eabihf", Triple::EABIHF)
.StartsWith("eabi", Triple::EABI)
.StartsWith("gnuabin32", Triple::GNUABIN32)
>From 56c0dc91c7f4a9b2204750a4c444abc733f2ef67 Mon Sep 17 00:00:00 2001
From: Kushal Pal
Date: Tue, 9 Dec 2025 11:42:18 +0530
Subject: [PATCH 2/2] [Clang][Hexagon] Enable Picolibc environment in Hexagon
toolchain
Update the Hexagon toolchain to recognize and handle triples
with `EnvironmentType::Picolibc`. This allows proper selection
of Picolibc runtime and libraries when targeting Hexagon environments.
Signed-off-by: Kushal Pal
---
clang/lib/Driver/ToolChains/Hexagon.cpp | 184 --
clang/lib/Driver/ToolChains/Hexagon.h | 8 +
.../test/Driver/hexagon-toolchain-picolibc.c | 133 +
3 files changed, 312 insertions(+), 13 deletions(-)
create mode 100644 clang/test/Driver/hexagon-toolchain-picolibc.c
diff --git a/clang/lib/Driver/ToolChains/Hexagon.cpp
b/clang/lib/Driver/ToolChains/Hexagon.cpp
index 084f51721315c..f4aa3a94a9a72 100644
--- a/clang/lib/Driver/ToolChains/Hexagon.cpp
+++ b/clang/lib/Driver/ToolChains/Hexagon.cpp
@@ -13,6 +13,7 @@
#include "clang/Driver/InputInfo.h"
#include "clang/Options/Options.h"
#include "llvm/Option/ArgList.h"
+#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Path.h"
#include "llvm/Support/VirtualFileSystem.h"
@@ -273,6 +274,97 @@ void hexagon::Linker::RenderExtraToolArgs(const JobAction
&JA,
ArgStringList &CmdArgs) const {
}
+static void constructHexagonPicolibcLinkArgs(
+Compilation &C, const JobAction &JA,
+const toolchains::HexagonToolChain &HTC, const InputInfo &Output,
+const InputInfoList &Inputs, const ArgList &Args, ArgStringList &CmdArgs,
+const char *LinkingOutput) {
+ const Driver &D = HTC.getDriver();
+ bool IsShared = Args.hasArg(options::OPT_shared);
+ bool IncStdLib = !Args.hasArg(options::OPT_nostdlib);
+ bool IncStartFiles = !Args.hasArg(options::OPT_nostartfiles);
+ bool IncDefLibs = !Args.hasArg(options::OPT_nodefaultlibs);
+ StringRef CpuVer = toolchains::HexagonToolChain::GetTargetCPUVersion(Args);
+ // Use G0 for Picolibc
+ bool UseG0 = true;
+ auto OsType = HTC.getOS();
+
+ CmdArgs.push_back("--eh-frame-hdr");
+ // Propagate arch flags to the linker when not using LLD, to match
+ // upstream Hexagon driver behavior validated by tests.
+ bool UseLLD = false;
+ const char *LinkerPath = Args.MakeArgString(HTC.GetLinkerPath(&UseLLD));
+ UseLLD = UseLLD ||
+ llvm::sys::path::filename(LinkerPath).ends_with("ld.lld") ||
+ llvm::sys::path::stem(LinkerPath).ends_with("ld.lld");
+ if (!UseLLD) {
+CmdArgs.push_back("-march=hexagon");
+CmdArgs.push_back(Args.MakeArgString("-mcpu=hexagon" + CpuVer));
+ }
+ CmdArgs.push_back("-o");
+ CmdArgs.push_back(Output.getFilename());
+
+ // Inputs
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
quic-k wrote: thanks for review @smithp35 > Not knowing the hexagon toolchain, I can't give you any useful comments on > that part of the review. Based on our experience of Picolibc in the baremetal > driver the question I have for you is whether there is enough picolibc > specific details here to justify a specific picolibc environment. > picolibc enviroment is right now used to set -I and -L paths, and we add crt0-semihost and -lsemihost that we get from Picolibc, I don't know if this is enough to justify a new environment. But what else is Musl environment used for apart from what I listed? > It looks like the majority of the extra configuration that you are adding is > not specific to picolibc, but could also apply to other bare-metal > C-libraries like llvm libc and newlib. About the only thing that I can see > that is Picolibc specific is adding crt-semihost.o for the startfiles. > > Would it be better to add this as a bare-metal configuration, not specific to > picolibc, then you wouldn't need a new environment when changing C-library? > sry, I don't get what you mean my "add this as bare-metal configuration", the idea for adding this triple was so that C libraries can co-exist and can be switch by just switching the triple from say : hexagon-none-picolibc to hexagon-none-llvmlibc we would point -I and -L flags to the different dirs based on the environment, and add crt and other files > FWIW. We require our users to use `-nostartfiles -lcrt-semihost` if they > prefer the semihosting startup code (with semihosted argc, argv and return) > and `lsemihost` for the semihost implementation. > I did check https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/blob/main/docs/newlib.md, I like the idea of pointing to correct sysroot using .cfg file, but isn't adding crt/semihost libs too much work for users? wouldn't it be better if the user can just specify triple or/and --libc flag and clang driver takes care of everything else? > It may also be useful to respond to > https://discourse.llvm.org/t/rfc-add-command-line-option-for-selecting-c-library/87335 > as the environment part is acting that way. > --libc flag would have been perfect for our usecase, but I don't know if this is going to go in. if we could simply use `libc.isPicolibc()` instead of `triple.isPicolibc()`, that would have been great > While I don't have any strong objections to adding picolibc as an evironment, > there was some pushback to the RFC as there were so many bare-metal > C-libraries, do we end up with an environment for each of them? With that in > mind it may be better to split the generic triple parts out into a separate > patch, to get more opinions on whether it is the right thing to do. I have split it into 2 commits, do you prefer it to be a separate PR instead? https://github.com/llvm/llvm-project/pull/169613 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
github-actions[bot] wrote: # :window: Windows x64 Test Results * 77014 tests passed * 1947 tests skipped All tests passed but another part of the build **failed**. Click on a failure below to see the details. [code=1] tools/clang/lib/Driver/CMakeFiles/obj.clangDriver.dir/ToolChains/Hexagon.cpp.obj ``` FAILED: [code=1] tools/clang/lib/Driver/CMakeFiles/obj.clangDriver.dir/ToolChains/Hexagon.cpp.obj sccache C:\clang\clang-msvc\bin\clang-cl.exe /nologo -TP -DCLANG_BUILD_STATIC -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_GLIBCXX_ASSERTIONS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\clang\lib\Driver -IC:\_work\llvm-project\llvm-project\clang\lib\Driver -IC:\_work\llvm-project\llvm-project\clang\include -Itools\clang\include -Iinclude -IC:\_work\llvm-project\llvm-project\llvm\include /DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive- -Werror=unguarded-availability-new /W4 -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wno-pass-failed -Wmisleading-indentation -Wctad-maybe-unsupported /Gw /O2 /Ob2 -MD /EHs-c- /GR- -UNDEBUG -std:c++17 /showIncludes /Fotools\clang\lib\Driver\CMakeFiles\obj.clangDriver.dir\ToolChains\Hexagon.cpp.obj /Fdtools\clang\lib\Driver\CMakeFiles\obj.clangDriver.dir\ -c -- C:\_work\llvm-project\llvm-project\clang\lib\Driver\ToolChains\Hexagon.cpp C:\_work\llvm-project\llvm-project\clang\lib\Driver\ToolChains\Hexagon.cpp(927,5): error: expected expression 927 | llvm_unreachable(); | ^ C:\_work\llvm-project\llvm-project\llvm\include\llvm/Support/ErrorHandling.h(165,40): note: expanded from macro 'llvm_unreachable' 165 | ::llvm::llvm_unreachable_internal(msg, __FILE__, __LINE__) |^ C:\_work\llvm-project\llvm-project\clang\lib\Driver\ToolChains\Hexagon.cpp(926,3): warning: default label in switch which covers all enumeration values [-Wcovered-switch-default] 926 | default: | ^ 1 warning and 1 error generated. ``` If these failures are unrelated to your changes (for example tests are broken or flaky at HEAD), please open an issue at https://github.com/llvm/llvm-project/issues and add the `infrastructure` label. https://github.com/llvm/llvm-project/pull/169613 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
https://github.com/quic-k updated
https://github.com/llvm/llvm-project/pull/169613
>From 767ef0ae4193335ebf5bf0a9a01a94d3c64052b2 Mon Sep 17 00:00:00 2001
From: Kushal Pal
Date: Tue, 9 Dec 2025 11:37:25 +0530
Subject: [PATCH 1/2] [Clang] Add Picolibc environment type for triples
Introduce `EnvironmentType::Picolibc` so that LLVM triples can
explicitly represent targets using Picolibc.
Signed-off-by: Kushal Pal
---
llvm/include/llvm/TargetParser/Triple.h | 4
llvm/lib/TargetParser/Triple.cpp| 3 +++
2 files changed, 7 insertions(+)
diff --git a/llvm/include/llvm/TargetParser/Triple.h
b/llvm/include/llvm/TargetParser/Triple.h
index 11b76cd183108..8728288f3538a 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -280,6 +280,7 @@ class Triple {
MuslX32,
MuslWALI,
LLVM,
+Picolibc,
MSVC,
Itanium,
@@ -866,6 +867,9 @@ class Triple {
getEnvironment() == Triple::OpenHOS || isOSLiteOS();
}
+ // Tests whether the environment is picolibc
+ bool isPicolibc() const { return getEnvironment() == Triple::Picolibc; }
+
/// Tests whether the target is OHOS
/// LiteOS default enviroment is also OHOS, but omited on triple.
bool isOHOSFamily() const { return isOpenHOS() || isOSLiteOS(); }
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index 11ba9ee32f66a..de9ea67bde939 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -378,6 +378,8 @@ StringRef Triple::getEnvironmentTypeName(EnvironmentType
Kind) {
case MuslWALI:
return "muslwali";
case Simulator: return "simulator";
+ case Picolibc:
+return "picolibc";
case Pixel: return "pixel";
case Vertex: return "vertex";
case Geometry: return "geometry";
@@ -747,6 +749,7 @@ static Triple::OSType parseOS(StringRef OSName) {
static Triple::EnvironmentType parseEnvironment(StringRef EnvironmentName) {
return StringSwitch(EnvironmentName)
+ .StartsWith("picolibc", Triple::Picolibc)
.StartsWith("eabihf", Triple::EABIHF)
.StartsWith("eabi", Triple::EABI)
.StartsWith("gnuabin32", Triple::GNUABIN32)
>From c3c8dc1358507db8d2b0fc62ec5def629c7f0374 Mon Sep 17 00:00:00 2001
From: Kushal Pal
Date: Tue, 9 Dec 2025 11:42:18 +0530
Subject: [PATCH 2/2] [Clang][Hexagon] Enable Picolibc environment in Hexagon
toolchain
Update the Hexagon toolchain to recognize and handle triples
with `EnvironmentType::Picolibc`. This allows proper selection
of Picolibc runtime and libraries when targeting Hexagon environments.
Signed-off-by: Kushal Pal
---
clang/lib/Driver/ToolChains/Hexagon.cpp | 185 --
clang/lib/Driver/ToolChains/Hexagon.h | 8 +
.../test/Driver/hexagon-toolchain-picolibc.c | 133 +
3 files changed, 313 insertions(+), 13 deletions(-)
create mode 100644 clang/test/Driver/hexagon-toolchain-picolibc.c
diff --git a/clang/lib/Driver/ToolChains/Hexagon.cpp
b/clang/lib/Driver/ToolChains/Hexagon.cpp
index 084f51721315c..1b736ec9f7965 100644
--- a/clang/lib/Driver/ToolChains/Hexagon.cpp
+++ b/clang/lib/Driver/ToolChains/Hexagon.cpp
@@ -13,6 +13,7 @@
#include "clang/Driver/InputInfo.h"
#include "clang/Options/Options.h"
#include "llvm/Option/ArgList.h"
+#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Path.h"
#include "llvm/Support/VirtualFileSystem.h"
@@ -273,6 +274,97 @@ void hexagon::Linker::RenderExtraToolArgs(const JobAction
&JA,
ArgStringList &CmdArgs) const {
}
+static void constructHexagonPicolibcLinkArgs(
+Compilation &C, const JobAction &JA,
+const toolchains::HexagonToolChain &HTC, const InputInfo &Output,
+const InputInfoList &Inputs, const ArgList &Args, ArgStringList &CmdArgs,
+const char *LinkingOutput) {
+ const Driver &D = HTC.getDriver();
+ bool IsShared = Args.hasArg(options::OPT_shared);
+ bool IncStdLib = !Args.hasArg(options::OPT_nostdlib);
+ bool IncStartFiles = !Args.hasArg(options::OPT_nostartfiles);
+ bool IncDefLibs = !Args.hasArg(options::OPT_nodefaultlibs);
+ StringRef CpuVer = toolchains::HexagonToolChain::GetTargetCPUVersion(Args);
+ // Use G0 for Picolibc
+ bool UseG0 = true;
+ auto OsType = HTC.getOS();
+
+ CmdArgs.push_back("--eh-frame-hdr");
+ // Propagate arch flags to the linker when not using LLD, to match
+ // upstream Hexagon driver behavior validated by tests.
+ bool UseLLD = false;
+ const char *LinkerPath = Args.MakeArgString(HTC.GetLinkerPath(&UseLLD));
+ UseLLD = UseLLD ||
+ llvm::sys::path::filename(LinkerPath).ends_with("ld.lld") ||
+ llvm::sys::path::stem(LinkerPath).ends_with("ld.lld");
+ if (!UseLLD) {
+CmdArgs.push_back("-march=hexagon");
+CmdArgs.push_back(Args.MakeArgString("-mcpu=hexagon" + CpuVer));
+ }
+ CmdArgs.push_back("-o");
+ CmdArgs.push_back(Output.getFilename());
+
+ // Inputs
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
@@ -311,6 +311,7 @@ class Triple {
OpenCL,
OpenHOS,
Mlibc,
+Picolibc,
petrhosek wrote:
This section is for shader stages, `Picolibc` should go next to other ABI/libc
after `LLVM` on line 282.
https://github.com/llvm/llvm-project/pull/169613
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
smithp35 wrote: Not knowing the hexagon toolchain, I can't give you any useful comments on that part of the review. Based on our experience of Picolibc in the baremetal driver the question I have for you is whether there is enough picolibc specific details here to justify a specific picolibc environment. It looks like the majority of the extra configuration that you are adding is not specific to picolibc, but could also apply to other bare-metal C-libraries like llvm libc and newlib. About the only thing that I can see that is Picolibc specific is adding crt-semihost.o for the startfiles. Would it be better to add this as a bare-metal configuration, not specific to picolibc, then you wouldn't need a new environment when changing C-library? FWIW. We require our users to use `-nostartfiles -lcrt-semihost` if they prefer the semihosting startup code (with semihosted argc, argv and return) and `lsemihost` for the semihost implementation. It may also be useful to respond to https://discourse.llvm.org/t/rfc-add-command-line-option-for-selecting-c-library/87335 as the environment part is acting that way. While I don't have any strong objections to adding picolibc as an evironment, there was some pushback to the RFC as there were so many bare-metal C-libraries, do we end up with an environment for each of them? With that in mind it may be better to split the generic triple parts out into a separate patch, to get more opinions on whether it is the right thing to do. https://github.com/llvm/llvm-project/pull/169613 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
quic-seaswara wrote: @MaskRay can you please take a look ? https://github.com/llvm/llvm-project/pull/169613 ___ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
@@ -769,11 +902,38 @@ void HexagonToolChain::addLibStdCxxIncludePaths(
DriverArgs, CC1Args);
}
+void HexagonToolChain::AddClangCXXStdlibIncludeArgs(
+const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args) const {
+ if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+ DriverArgs.hasArg(options::OPT_nostdincxx))
+return;
+ // For Picolibc baremetal, add libc++ headers via extern C system include
+ // from the normalized triple tree to match driver tests.
+ const Driver &D = getDriver();
+ if (getTriple().isPicolibc() && getTriple().getOS() != llvm::Triple::Linux) {
+StringRef InstallDir = D.Dir;
+addExternCSystemInclude(DriverArgs, CC1Args,
+InstallDir + "/../target/" +
+getTriple().normalize() + "/include/c++/v1");
+return;
+ }
+ // Otherwise delegate to the chosen C++ stdlib include path helper.
+ switch (GetCXXStdlibType(DriverArgs)) {
+ case ToolChain::CST_Libcxx:
+addLibCxxIncludePaths(DriverArgs, CC1Args);
+break;
+ case ToolChain::CST_Libstdcxx:
+addLibStdCxxIncludePaths(DriverArgs, CC1Args);
+break;
+ }
androm3da wrote:
The default case here should be handled (perhaps `LLVM_UNREACHABLE`?).
https://github.com/llvm/llvm-project/pull/169613
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
@@ -583,16 +682,38 @@ void HexagonToolChain::getHexagonLibraryPaths(const
ArgList &Args,
HasG0 = *G == 0;
const std::string CpuVer = GetTargetCPUVersion(Args).str();
- for (auto &Dir : RootDirs) {
-std::string LibDir = Dir + "/hexagon/lib";
-std::string LibDirCpu = LibDir + '/' + CpuVer;
+ // Special-case Picolibc baremetal layout:
androm3da wrote:
Once picolibc stabilizes, maybe we could consider migrating other targets to
use this and make it the general case.
https://github.com/llvm/llvm-project/pull/169613
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
https://github.com/quic-k updated
https://github.com/llvm/llvm-project/pull/169613
>From 5172ab300086a92be5b9d4be3e9cd17c582392da Mon Sep 17 00:00:00 2001
From: Kushal Pal
Date: Wed, 26 Nov 2025 11:57:23 +0530
Subject: [PATCH] Add Picolibc as part of triple
This patch adds Picolibc as part of triple so toolchains can switch
the to Picolibc based on triple.
Hexagon toolchain uses the triple hexagon-none-picolibc.
Signed-off-by: Kushal Pal
---
clang/lib/Driver/ToolChains/Hexagon.cpp | 186 --
clang/lib/Driver/ToolChains/Hexagon.h | 8 +
.../test/Driver/hexagon-toolchain-picolibc.c | 133 +
llvm/include/llvm/TargetParser/Triple.h | 4 +
llvm/lib/TargetParser/Triple.cpp | 3 +
5 files changed, 321 insertions(+), 13 deletions(-)
create mode 100644 clang/test/Driver/hexagon-toolchain-picolibc.c
diff --git a/clang/lib/Driver/ToolChains/Hexagon.cpp
b/clang/lib/Driver/ToolChains/Hexagon.cpp
index 084f51721315c..189ee999a268f 100644
--- a/clang/lib/Driver/ToolChains/Hexagon.cpp
+++ b/clang/lib/Driver/ToolChains/Hexagon.cpp
@@ -273,6 +273,101 @@ void hexagon::Linker::RenderExtraToolArgs(const JobAction
&JA,
ArgStringList &CmdArgs) const {
}
+static void constructHexagonPicolibcLinkArgs(
+Compilation &C, const JobAction &JA,
+const toolchains::HexagonToolChain &HTC, const InputInfo &Output,
+const InputInfoList &Inputs, const ArgList &Args, ArgStringList &CmdArgs,
+const char *LinkingOutput) {
+ const Driver &D = HTC.getDriver();
+ bool IsShared = Args.hasArg(options::OPT_shared);
+ bool IncStdLib = !Args.hasArg(options::OPT_nostdlib);
+ bool IncStartFiles = !Args.hasArg(options::OPT_nostartfiles);
+ bool IncDefLibs = !Args.hasArg(options::OPT_nodefaultlibs);
+ StringRef CpuVer = toolchains::HexagonToolChain::GetTargetCPUVersion(Args);
+ // Use G0 for Picolibc
+ bool UseG0 = true;
+ auto OsType = HTC.getOS();
+
+ CmdArgs.push_back("--eh-frame-hdr");
+ // Propagate arch flags to the linker when not using LLD, to match
+ // upstream Hexagon driver behavior validated by tests.
+ bool UseLLD = false;
+ const char *LinkerPath = Args.MakeArgString(HTC.GetLinkerPath(&UseLLD));
+ UseLLD = UseLLD ||
+ llvm::sys::path::filename(LinkerPath).ends_with("ld.lld") ||
+ llvm::sys::path::stem(LinkerPath).ends_with("ld.lld");
+ if (!UseLLD) {
+CmdArgs.push_back("-march=hexagon");
+CmdArgs.push_back(Args.MakeArgString("-mcpu=hexagon" + CpuVer));
+ }
+ CmdArgs.push_back("-o");
+ CmdArgs.push_back(Output.getFilename());
+
+ // Inputs
+ Args.addAllArgs(CmdArgs, {options::OPT_T_Group, options::OPT_s,
+options::OPT_t, options::OPT_u_Group});
+ AddLinkerInputs(HTC, Inputs, Args, CmdArgs, JA);
+
+
//
+ // Start Files
+
//
+ const std::string MCpuSuffix = "/" + CpuVer.str();
+ const std::string MCpuG0Suffix = MCpuSuffix + "/G0";
+ const std::string RootDir =
+ HTC.getHexagonTargetDir(D.Dir, D.PrefixDirs) + "/";
+ std::string NormalizedTriple =
+ HTC.getTriple().normalize(llvm::Triple::CanonicalForm::FOUR_IDENT);
+ const std::string StartSubDir =
+ NormalizedTriple + "/lib" + (UseG0 ? MCpuG0Suffix : MCpuSuffix);
+
+ if (IncStdLib && IncStartFiles) {
+if (!IsShared) {
+ if (OsType == "none" || OsType == "unknown") {
+std::string Crt0 = RootDir + StartSubDir + "/crt0-semihost.o";
+CmdArgs.push_back(Args.MakeArgString(Crt0));
+ }
+}
+ }
+
+
//
+ // Library Search Paths
+
//
+ const ToolChain::path_list &LibPaths = HTC.getFilePaths();
+ for (const auto &LibPath : LibPaths)
+CmdArgs.push_back(Args.MakeArgString(StringRef("-L") + LibPath));
+
//
+ // Libraries
+
//
+ if (IncStdLib && IncDefLibs) {
+if (D.CCCIsCXX()) {
+ if (HTC.ShouldLinkCXXStdlib(Args))
+HTC.AddCXXStdlibLibArgs(Args, CmdArgs);
+ CmdArgs.push_back("-lm");
+}
+
+CmdArgs.push_back("--start-group");
+
+if (!IsShared) {
+ // add OS libraries to link
+ std::vector OsLibs{};
+ if (OsType == "none" || OsType == "unknown") {
+OsLibs.push_back("semihost");
+ } else if (OsType == "h2") {
+OsLibs.push_back("h2");
+ } else if (OsType == "qurt") {
+OsLibs.push_back("qurt");
+ }
+ for (StringRef Lib : OsLibs)
+CmdArgs.push_back(Args.MakeArgString("-l" + Lib));
+ if (!Args.hasArg(options::OPT_nolibc))
+CmdArgs.push_back("-lc");
+}
+// Force
[clang] [llvm] [clang][Hexagon] Add Picolibc as part of triple (PR #169613)
github-actions[bot] wrote:
# :penguin: Linux x64 Test Results
* 166370 tests passed
* 2869 tests skipped
* 2 tests failed
## Failed Tests
(click on a test name to see its output)
### Clang
Clang.Driver/hexagon-toolchain-elf.c
```
Exit Code: 1
Command Output (stdout):
--
# RUN: at line 5
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang -###
--target=hexagon-unknown-elf-ccc-install-dir
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/Inputs/hexagon_tree/Tools/bin
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
2>&1 |
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck
-check-prefix=CHECK000
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
# executed command:
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang '-###'
--target=hexagon-unknown-elf -ccc-install-dir
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/Inputs/hexagon_tree/Tools/bin
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
# note: command had no output on stdout or stderr
# executed command:
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck
-check-prefix=CHECK000
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
# note: command had no output on stdout or stderr
# RUN: at line 9
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang
--driver-mode=g++ -### --target=hexagon-unknown-elf-ccc-install-dir
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/Inputs/hexagon_tree/Tools/bin
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
2>&1 |
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck
-check-prefix=CHECK001
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
# executed command:
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang
--driver-mode=g++ '-###' --target=hexagon-unknown-elf -ccc-install-dir
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/Inputs/hexagon_tree/Tools/bin
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
# note: command had no output on stdout or stderr
# executed command:
/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck
-check-prefix=CHECK001
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c
# .---command stderr
# |
/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c:11:14:
error: CHECK001: expected string not found in input
# | // CHECK001: "-cc1" {{.*}} "-internal-isystem"
"{{.*}}/Inputs/hexagon_tree/Tools/bin/../target/hexagon/include/c++"
# | ^
# | :1:1: note: scanning from here
# | clang version 22.0.0git (https://github.com/llvm/llvm-project
3337fe7b6b99a1c0fae891bfeb470569d6c57ed7)
# | ^
# | :7:979: note: possible intended match here
# |
"/home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang-22"
"-cc1" "-triple" "hexagon-unknown-unknown-elf" "-emit-obj" "-dumpdir" "a-"
"-disable-free" "-clear-ast-before-backend" "-main-file-name"
"hexagon-toolchain-elf.c" "-mrelocation-model" "pic" "-pic-level" "2"
"-pic-is-pie" "-mframe-pointer=all" "-fmath-errno" "-ffp-contract=on"
"-fno-rounding-math" "-mconstructor-aliases" "-fno-use-init-array"
"-target-cpu" "hexagonv68" "-target-feature" "-long-calls" "-mqdsp6-compat"
"-Wreturn-type" "-fshort-enums" "-mllvm" "-machine-sink-split=0"
"-debugger-tuning=gdb"
"-fdebug-compilation-dir=/home/gha/actions-runner/_work/llvm-project/llvm-project/build/tools/clang/test/Driver"
"-fcoverage-compilation-dir=/home/gha/actions-runner/_work/llvm-project/llvm-project/build/tools/clang/test/Driver"
"-resource-dir"
"/home/gha/actions-runner/_work/llvm-project/llvm-project/build/lib/clang/22"
"-internal-externc-isystem"
"/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/Inputs/hexagon_tree/Tools/bin/../target/hexagon/include"
"-fdeprecated-macro" "-ferror-limit" "19" "-fshort-enums" "-fno-signed-char"
"-fgnuc-version=4.2.1" "-fskip-odr-check-in-gmf" "-fcxx-exceptions"
"-fexceptions" "-faddrsig" "-fdwarf2-cfi-asm" "-o"
"/tmp/lit-tmp-8kd_s4id/hexagon-toolchain-elf-5f8f26.o" "-x" "c++"
"/home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/Driver/hexagon-toolchain-elf.c"
# |
