I will be releasing a v1.8.1 with this fix in the near future. I still
need to decide the names of the new CPUModelNumber fields [1] and see if
I can backport the easy x86 support to v1.8.1 too.
Rhanks for reporting the issue and testing the "patched winball"
Brice
[1]
Le 28/01/2014 14:31, Brice Goglin a écrit :
> Le 28/01/2014 13:00, Samuel Thibault a écrit :
>> Brice Goglin, le Tue 28 Jan 2014 12:46:24 +0100, a écrit :
>>> 42: xchg %ebx,%rbx
>>>
>>> I guess having both ebx and rbx on these lines isn't OK. On Linux, I get
>>> rsi instead of ebx, no problem.
Le 28/01/2014 13:00, Samuel Thibault a écrit :
> Brice Goglin, le Tue 28 Jan 2014 12:46:24 +0100, a écrit :
>> 42: xchg %ebx,%rbx
>>
>> I guess having both ebx and rbx on these lines isn't OK. On Linux, I get
>> rsi instead of ebx, no problem.
>>
>> Samuel, any idea?
> Mmm, IIRC, "unsigned long"
Brice Goglin, le Tue 28 Jan 2014 12:46:24 +0100, a écrit :
> 42: xchg %ebx,%rbx
>
> I guess having both ebx and rbx on these lines isn't OK. On Linux, I get
> rsi instead of ebx, no problem.
>
> Samuel, any idea?
Mmm, IIRC, "unsigned long" on windows may not be 64bit but 32bit?
Perhaps we
Le 28/01/2014 09:57, Brice Goglin a écrit :
> I will debug a bit more to see if it's actually a 64bit cpuid problem
> on windows.
The x86 backend is entirely disabled in the 64bit windows build because
configure fails to compile the cpuid assembly (in my mingw64 with gcc 4.7).
It says:
40:
Le 28/01/2014 09:46, Robin Scher a écrit :
> Hi, thanks for responding.
>
> The CPUModel is definitely available on this machine. A 32 bit process
> on the same machine correctly finds the model name using code that
> calls the cpuid inline assembly to get it, and the machine itself is a
> VM
Hi, thanks for responding.
The CPUModel is definitely available on this machine. A 32 bit process on the
same machine correctly finds the model name using code that calls the cpuid
inline assembly to get it, and the machine itself is a VM running on a Mac, and
I get the same model name from
Hi again.
I’m trying to use hwloc 1.8 on Windows, Linux and Mac to get the CPU model
string (e.g., “Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz”). Since hwloc on
different platforms seem to stash this in different objects, I’m using code
like this:
String name;
hwloc_obj_type_t objs[] = {
