gdb, btrace: fix family and model computation

  In gdb/nat/linux-btrace.c:btrace_this_cpu() we initialize the cpu
structure given to the libipt btrace decoder.

We only consider the extended model field for family 0x6 and forget about
family 0xf and we don't consider the extended family field.  Fix it.
---
 gdb/nat/linux-btrace.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
  

>>>>> "Markus" == Markus Metzger via Gdb-patches <gdb-patches@sourceware.org> writes:

Markus> In gdb/nat/linux-btrace.c:btrace_this_cpu() we initialize the cpu
Markus> structure given to the libipt btrace decoder.

Markus> We only consider the extended model field for family 0x6 and forget about
Markus> family 0xf and we don't consider the extended family field.  Fix it.

You should probably just self-approve this.

Markus>  	      cpu.family = (cpuid >> 8) & 0xf;
Markus> -	      cpu.model = (cpuid >> 4) & 0xf;
Markus> +	      if (cpu.family == 0xf)
Markus> +		cpu.family += (cpuid >> 20) & 0xff;
 
Markus> -	      if (cpu.family == 0x6)
Markus> +	      cpu.model = (cpuid >> 4) & 0xf;
Markus> +	      if ((cpu.family == 0x6) || ((cpu.family & 0xf) == 0xf))
Markus>  		cpu.model += (cpuid >> 12) & 0xf0;

I wonder if these magic numbers have #defines anywhere we could use.

Tom
  

Hello Tom,

>Markus>  	      cpu.family = (cpuid >> 8) & 0xf;
>Markus> -	      cpu.model = (cpuid >> 4) & 0xf;
>Markus> +	      if (cpu.family == 0xf)
>Markus> +		cpu.family += (cpuid >> 20) & 0xff;
>
>Markus> -	      if (cpu.family == 0x6)
>Markus> +	      cpu.model = (cpuid >> 4) & 0xf;
>Markus> +	      if ((cpu.family == 0x6) || ((cpu.family & 0xf) == 0xf))
>Markus>  		cpu.model += (cpuid >> 12) & 0xf0;
>
>I wonder if these magic numbers have #defines anywhere we could use.

In fact,

    bb368aad297 gprofng: a new GNU profiler

added the same functionality, so now we have two versions of it.  I tried
to unify them (attached) but wasn't able to pass gprofng tests on my box.
They already fail without my changes.

I could replace this patch with the attached two.  What do you think?

regards,
markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
  

> In fact,
>     bb368aad297 gprofng: a new GNU profiler
> added the same functionality, so now we have two versions of it.  I tried
> to unify them (attached) but wasn't able to pass gprofng tests on my box.
> They already fail without my changes.

> I could replace this patch with the attached two.  What do you think?

I wouldn't hold up your patch for this, but if you wanted to coordinate
with the gprofng folks and get this new patch in, it does seem better to
consolidate the code.

Tom
  

Thanks, Tom,

>> In fact,
>>     bb368aad297 gprofng: a new GNU profiler
>> added the same functionality, so now we have two versions of it.  I tried
>> to unify them (attached) but wasn't able to pass gprofng tests on my box.
>> They already fail without my changes.
>
>> I could replace this patch with the attached two.  What do you think?
>
>I wouldn't hold up your patch for this, but if you wanted to coordinate
>with the gprofng folks and get this new patch in, it does seem better to
>consolidate the code.

I'll push this patch, then, so we get the fix.  Then, I'll send out the other
two to consolidate if there is interest from gprofng.

regards,
markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928