Support for freestanding targets

[brvtalcake]

I do not know how feasible it is, but as an idea/feature request, it would be nice to make at least parts of the library freestanding (for example, for people doing osdev or embedded programming).

[TheTumultuousUnicornOfDarkness]

Hello,

I have no experience at all with freestanding libraries. This library is small and does not have any external dependencies.
What is happening when you build with -ffreestanding?

[brvtalcake]

Hello !

What is happening when you build with -ffreestanding?

Usually, you also pass -nostdlib and/or some other useful flags to avoid linking with libc or any hosted dependencies, and to avoid the start files (eg crt.o etc) which are normally automatically linked. And you also basically give up any header not in the « Fully freestanding » list of headers (+ the headers with the platform specific intrinsics, e.g. the __cpuid_count macros/functions).
Most of the time, any freestanding project has to define memset, memcpy, memmove and memcmp, since (at least) GCC requires them even in freestanding generated code. That means that :

1. the library can almost always assume these are here (even if these are not required in a freestanding implementation per the standard), provide a dummy declaration, and use them undefined (calls will be resolved by the linker when linking libcpuid.a to the final executable, if the user provides them)
2. the library can also provide your own implementation as a weak symbol and repeat the previous steps (never done that but I think it's fine ?). This way:
   • if the user finds some way to tell GCC not to generate calls to these functions, well, you still have them for use in the library, if necessary
   • if the user defines them, they will override the library's definitions

But otherwise the library also has to give up any kind of standard IO, threads, thread-local storage, and would need to be limited to the informations from raw CPU instructions, and could not rely on any Linux/BSDs/... kernel module. I guess it's fine since osdev/embedded projects usually run in ring 0, so you can execute basically any valid (even privileged) instruction.

I can try to look into the parts that could be interesting for freestanding projects (typically cpu features detection, and things related to MSRs, for x86), and see how it could maybe be re-arranged to (optionally) support freestanding targets.

This library is small and does not have any external dependencies.

All the more reason to support freestanding targets, since this is basically the kind of things you want ! Though I totally understand that you want to keep it small and not too bloated

I personally started to write an x86-64 kernel in C (that I'm restarting because I prefer to write it in both Rust and C, but that's off-topic), and I generally compile my C code with a x86_64-unknown-none-elf GCC toolchain and with these flags : -ffreestanding -fno-stack-protector -fno-stack-check -m64 -mno-mmx -march=x86-64 -mno-sse -mno-sse2 -mno-red-zone -mno-avx -mno-avx2 -mno-avx512f -nodefaultlibs -nostdlib -nostartfiles (I omitted the ones that aren't necessary, but the ones remaining are good defaults for x86-64 osdev I think) (maybe the stack-protector-related flags are too much though)
Otherwise Clang can be quite useful, since it is basically designed to act as a cross-compiler. With a similar set of options as well, plus --target=x86_64-unknown-none-elf or whatever target you want.

[brvtalcake]

I have no experience at all with freestanding libraries.

I do not have a lot either, but I thought cpu features detection shouldn't be too long/too hard to port to freestanding targets.

I can not tell you I will do it now, but if you're ok, then I can try to take a deeper look at the code and see how bad (or hopefully, how good) of a guesser I am

[TheTumultuousUnicornOfDarkness]

Nice, thank you for the explanation, it is very useful and it helps me to understand what we need to do.

IMHO, it makes sense to support freestanding targets, I have no doubt that this library can avoid to reinvent the wheel in such scenarios.
I have very little experience with kernel programming (I played a little bit with Xv6) and very little experience with embedded projects (simple projects in Arduino) so I cannot work on such feature, but I think I can provide a quick overview:

• to get the raw data for each CPU core (cpuid_get_raw_data_core()), libcpuid relies on specific-OS functions to set CPU affinity. But if affinity cannot be set, it will only provide raw data for current core (e.g. core 0).
• x86 MSRs relies on the kernel to read these registers, but I think this part can be skipped to start.
• all stuff about kernel modules is for CPU MSRs (x86) and identification register (ARM).

Contributors are welcome, so feel free to submit PR, I can review them.
If I can give an advice: start small, and work in an iterative way. I think cpuid_get_raw_data() and cpu_identify() will be a good starting point to have data for only one CPU core.

And I can try to answer to questions (I do not known everything about this library, I am just a contributor 😄).