On Di, 14.05.19 08:03, Ulrich Windl (Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx) wrote: > >> > cpuid has *nothing* to do with /proc/cpuinfo > >> > > >> > https://en.wikipedia.org/wiki/CPUID > >> > The CPUID instruction (identified by a CPUID opcode) is a processor > >> > supplementary instruction > >> > >> Isn't it about to check a CPU's feature depending on the CPU model? > > > > Ulrich, please understand that __get_cpuid() (which the discussion > > here is about) is a gcc and llvm/clang feature weare are just making > > use of. It used by various Linux software, and apparently doesn't work > > entirely correctly on all CPUs in some corner case. The discussion is > > about fixing gcc accordingly, and making it work, so that systemd all > > all other software can work correctly. > > > > If you think that gcc/llvm are bad for "reimplementing /proc/cpuinfo" > > then please bring that up with those communities, but please stop > > these fruitless discussions here. > > The point I was trying to make was: "CPUID" and the model-specific registers > (thus the name) depend very much on the CPU being used. While the kernel makes > grat efforts to get things right, I wondered whether it's the best idea whether > to repeat that effort in an application program. A compiler is hardly an "application program". There's also a bit of a chicken and egg problem: shared library linking support mechanisms for dynamically altering the function resolution slightly depending on the available CPU features, i.e. so that you get an SSE-enabled memcpy() if your CPU does SSE and a plain one otherwise. If you want to open /proc/cpuinfo you need to call libc's open() call and a number of other libc API calls. And hence you might end up calling into libc in order to call into libc in order to call into libc in order to libc and so on forever until your stack overruns. These problems are all neatly avoided by simply using __get_cpuid() provided by gcc so that you can just shortcut all this... Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel