Re: [PATCH uci 1/2] fuzz: Compile using libstd++
Hauke Mehrtens [2023-03-09 00:18:09]: Hi, > It looks like libfuzzer is compiled using libstd++ on Debian Bookworm > and not libc++. Using libc++ causes linking errors, use libstd++ > instead. so maybe this should be detected and decided at runtime? Otherwise this seems to just support Bookworm from now and thus fail to compile elsewhere? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Reusable Github Actions and containers [Was: Re: [PATCH uci 2/2] CI: Add github action]
Hauke Mehrtens [2023-03-09 00:18:10]: Hi, thanks for taking care, LGTM for a start. I'll just provide my past experience, something to consider as we're likely going to bump into those in the long term, so ideally take them into the account in the long term. > clang 14 generates debug information in DWARF 5 format, but valgrind > 19.0 does not support that. Install valgrind 20.0 from experimental > which supports it. IMO we should aim for reproducible results, thus we should likely provide tools containers with a known versions inside, so anyone is able to get same results using the source code Git hash and tool container version. Your current approach is highly dynamic, so if you're lucky enough, you might get a green CI light in the PR branch as the pipeline was run for example 7 days ago, so you're going to merge it into the upstream branch, but then it's going to fail as meanwhile Debian has bumped several packages and you're going to get a CI pipeline failure. IMO there should be a tools container Git repository, where we could build, test and provide versioned containers, for example: ghcr.io/openwrt/ci-tools/native-testing/clang14:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang15:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-8:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-11:20230305 ghcr.io/openwrt/ci-tools/native-testing/gcc-12:20230305 We want to test with with multiple compiler versions as those tested changes might be backported into stable branches, we should even consider to have stable branches in every project so we could CI test them there as well, folks would simply create a backport PR in the respective project. > +++ b/.github/workflows/test.yml > @@ -0,0 +1,83 @@ > +name: 'Run tests' We've like 30+ C projects which we should likely cover in the end, thus considering possible additional 2 stable branches in each, it's around 60+ of similar workflow files duplicated in various repositories. I would consider this future maintenance overhead (imagine just a simple change or a fix being propagated into 60+ repositories/branches), so I would recommend to create a shareable Github Action instead: uses: openwrt/gh-actions-ci-native env: CI_NATIVE_TOOLCHAIN: clang14 uses: openwrt/gh-actions-ci-sdk env: CI_TARGET_SDK_RELEASE: master CI_TARGET_SDK: ath79-generic CI_TARGET_BUILD_DEPENDS: uci You can take a look at the ucode project for a very dated, but still working GitHub example, some bits are even present in uci repsitory in the .gitlab-ci.yml file. > + - name: Checkout libubox > +uses: actions/checkout@v3 > +with: > + repository: openwrt/libubox > + path: libubox This looks like another source of unreliability, similar to the toolchain versions above. For the start, I would simply include all those dependencies in the native toolchain container, thus we would need to have separate containers for each branch: ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-22.03:20230305 ghcr.io/openwrt/ci-tools/native-testing/clang14_openwrt-21.02:20230305 ghcr.io/openwrt/ci-tools/native-testing/distro_snapshot:20230305 (distro default gcc12) ghcr.io/openwrt/ci-tools/native-testing/distro_21.02:20230305 (gcc8) ghcr.io/openwrt/ci-tools/native-testing/distro_22.03:20230305 (gcc11) So in the end, ideally, interested developer can have the same CI failure/result locally and debug/fix it faster: $ git clone https://github.com/openwrt/uci && cd uci $ wget -q https://github.com/openwrt/some-project/raw/master/Makefile -O Makefile.ci $ make ci-prepare -f Makefile.ci $ podman run --rm --tty --interactive --volume $(pwd):/home/build/openwrt \ ghcr.io/openwrt/ci-tools/native-testing/clang14_snapshot:20230305 \ make ci-native-build -f Makefile.ci Have a nice weekend. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uqmi v2] uqmi: avoid gcc-12.x false error reporting (storing the address of local variable 'complete' in '*req.complete')
Avoid gcc-12.x false error reporting (req->complete is later reset to NULL
in case of use of local complete):
dev.c:217:23: error: storing the address of local variable 'complete' in
'*req.complete' [-Werror=dangling-pointer=]
217 | req->complete = &complete;
| ~~^~~
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- apply pragma ignored only for gcc >= 12.x (as the warning
'-Wdangling-pointer' was introduced with gcc-12.x)
---
dev.c | 12
1 file changed, 12 insertions(+)
diff --git a/dev.c b/dev.c
index bd10207..dbd42d4 100644
--- a/dev.c
+++ b/dev.c
@@ -203,6 +203,15 @@ void qmi_request_cancel(struct qmi_dev *qmi, struct
qmi_request *req)
__qmi_request_complete(qmi, req, NULL);
}
+/* avoid gcc-12.x false error reporting:
+ * dev.c:217:23: error: storing the address of local variable ‘complete’ in
‘*req.complete’ [-Werror=dangling-pointer=]
+ * 217 | req->complete = &complete;
+ * | ~~^~~
+ */
+#if __GNUC__ >= 12
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdangling-pointer"
+#endif
int qmi_request_wait(struct qmi_dev *qmi, struct qmi_request *req)
{
bool complete = false;
@@ -231,6 +240,9 @@ int qmi_request_wait(struct qmi_dev *qmi, struct
qmi_request *req)
return req->ret;
}
+#if __GNUC__ >= 12
+#pragma GCC diagnostic pop
+#endif
struct qmi_connect_request {
struct qmi_request req;
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: hpe_1920-8g: add phy-handle for SFP ports
The switch driver actually expects every port to have a PHY handle, and
several branches in the code determine if a port is valid by checking
for a non-zero phy field.
Signed-off-by: Jan Hoffmann
---
target/linux/realtek/dts-5.10/rtl8380_hpe_1920-8g.dts | 2 ++
target/linux/realtek/dts-5.15/rtl8380_hpe_1920-8g.dts | 2 ++
2 files changed, 4 insertions(+)
diff --git a/target/linux/realtek/dts-5.10/rtl8380_hpe_1920-8g.dts
b/target/linux/realtek/dts-5.10/rtl8380_hpe_1920-8g.dts
index b51c75f35524..6ddb2d8dcc60 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_hpe_1920-8g.dts
+++ b/target/linux/realtek/dts-5.10/rtl8380_hpe_1920-8g.dts
@@ -87,6 +87,7 @@
port@24 {
reg = <24>;
label = "lan9";
+ phy-handle = <&phy24>;
phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <&sfp0>;
@@ -95,6 +96,7 @@
port@26 {
reg = <26>;
label = "lan10";
+ phy-handle = <&phy26>;
phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <&sfp1>;
diff --git a/target/linux/realtek/dts-5.15/rtl8380_hpe_1920-8g.dts
b/target/linux/realtek/dts-5.15/rtl8380_hpe_1920-8g.dts
index b51c75f35524..6ddb2d8dcc60 100644
--- a/target/linux/realtek/dts-5.15/rtl8380_hpe_1920-8g.dts
+++ b/target/linux/realtek/dts-5.15/rtl8380_hpe_1920-8g.dts
@@ -87,6 +87,7 @@
port@24 {
reg = <24>;
label = "lan9";
+ phy-handle = <&phy24>;
phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <&sfp0>;
@@ -95,6 +96,7 @@
port@26 {
reg = <26>;
label = "lan10";
+ phy-handle = <&phy26>;
phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <&sfp1>;
--
2.39.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
