On Di, 14.05.19 08:03, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 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
> 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
Lennart Poettering, Berlin
systemd-devel mailing list