search

au-ts / sddf

A collection of interfaces, libraries and tools for writing device drivers for seL4 that allow accessing devices securely and with low overhead.
Other
23 stars 18 forks source link

fix: clang compiler in devShell #285

Closed wucke13 closed 1 week ago

wucke13 commented 2 weeks ago

This fix makes the unwrapped clang capable to use its built-in headers. Further it tidies up the mkShell call a little.

@Ivan-Velickovic Please review, and let me know if the lengthy comment is at least halfway understandable.

midnightveil commented 2 weeks ago

A similar thing should be possible for GCC, right? Then we wouldn't need the hardening disable because we wouldn't have the cc-wrapper anywhere?

Or is GCC a little different — I know clang is broken because for whatever reason Nix builds clang with a specific lib-dir for things and then moves it after build.

wucke13 commented 2 weeks ago

@midnightveil I skimmed through the outputs listed by nix-build '<nixpkgs>' --no-out-link --no-build-output --attr gcc-unwrapped.all ~but could no find any header files there, so it seems they are not part of the gcc package?~ and sure enough they are already part of the base gcc-unwrapped package!

So for gcc, no such tricks should be necessary. However, I don't know the mechanism used by gcc to find those includes, so only because they are there in the adjacent folder does not necessarily mean they are picked up.

In particular, I would recommend using the unwrapped gcc flavours, as I do over there: https://github.com/DLR-FT/seL4-nix-utils/blob/71a31e0ad711e6d435be0af7735380017b2fe288/flake.nix#L482-L485 . That at least works in my Nix expression for the microkit-sdk: https://github.com/DLR-FT/seL4-nix-utils/blob/71a31e0ad711e6d435be0af7735380017b2fe288/pkgs/microkit-sdk.nix#L70-L76

midnightveil commented 2 weeks ago

Hm. That might not be fine since some of the sDDF examples need libc.

If it's the headers the reason (iirc) clang is broken is because nixpkgs decided to move the lib folder out from where it tells the build system, which I didn't think they did for gcc.

I mean, if everything builds with the unwrapped versions as you did for the microkit SDK it'd be nice to not deal with cc-wrapper shenanigans.

wucke13 commented 2 weeks ago

Hm. That might not be fine since some of the sDDF examples need libc.

What libc, and what specifically of it? Authoritative information that goes beyond the "whatever comes with the gcc arm embedded package on my distro seems to work" would be information highly appreciated by me.

If it's the headers the reason (iirc) clang is broken is because nixpkgs decided to move the lib folder out from where it tells the build system, which I didn't think they did for gcc.

That matches my understanding. However, I'd like to add that this is for good reason, normally when compiling for glibc (default for applications on Linux) you likely don't want to mix-in compiler built-in headers. Gcc even comes with some heuristic in the install scripts to merge system headers with the built-in headers (and a warning that these might fail). Just splitting of the built-in headers likely is a good choice for a robust application development environment targeting Linux. It just breaks things for such niche use-cases the likes of us nag about :laughing:

I mean, if everything builds with the unwrapped versions as you did for the microkit SDK it'd be nice to not deal with cc-wrapper shenanigans.

That depends on the answer to the question about which libc is needed. If indeed a specific libc is needed, I'm convinced it is the right thing to create a wrapped toolchain, that supplies that very libc to the compiler. If however no libc is needed, and the built-in headers from gcc & clang do fine, then I concur with your statement that not dealing with cc-wrapper shenanigans is the sweet thing to do.

midnightveil commented 2 weeks ago

What libc, and what specifically of it? Authoritative information that goes beyond the "whatever comes with the gcc arm embedded package on my distro seems to work" would be information highly appreciated by me

I'm not sure personally, @Ivan-Velickovic would know. The echo server example needs to be compiled with gcc because it relies on libc in some form or another but what precisely I don't know.

Ivan-Velickovic commented 2 weeks ago

The requirement is due to the echo server being used to benchmark networking the sub-system and hence needs optimised versions of standard library functions for the lwIP client. We’ve tried using simple memcpy etc implementations but it significantly degrades performance.

So for now we just default to using the newlibc from the embedded toolchain until we sort out our own libc or add optimised versions of the functions lwIP expects to sDDF.

Ivan-Velickovic commented 2 weeks ago

The requirement is due to the echo server being used to benchmark networking the sub-system and hence needs optimised versions of standard library functions for the lwIP client. We’ve tried using simple memcpy etc implementations but it significantly degrades performance.

So for now we just default to using the newlibc from the embedded toolchain until we sort out our own libc or add optimised versions of the functions lwIP expects to sDDF.

I will add this to the README so it lets others know why the echo server is an exception.

wucke13 commented 2 weeks ago

Then it would be also possible to wrap both a gcc and a clang with the newlibc. It's already packaged in Nix... Your pick :smile:

(Though not depending on any libc and shipping necessary functionality yourself is the more sexy thing to do)

Ivan-Velickovic commented 1 week ago

Then it would be also possible to wrap both a gcc and a clang with the newlibc. It's already packaged in Nix... Your pick

I just want the Nix environment to be as close as possible to native so we'll stick with newlibc with GCC for now (which I believe is the current case in the flake).