Re: [PATCH v5 2/2] Implement pahole-like 'ptype /o' option

[Pedro Alves <palves@redhat.com>]

On 12/13/2017 08:36 PM, Sergio Durigan Junior wrote:
> On Wednesday, December 13 2017, I wrote:

>> OK, I'll confirm on PPC64BE.

Thanks.

> 
> It seems like the algorithm for calculating bitfield offsets is not
> working correctly on BE machines.  This is not only for "ptype /o", but
> also for regular print commands.  For example, consider this test:
> 
>   struct tyu
>   {
>     int a1 : 1;
> 
>     int a2 : 3;
> 
>     int a3 : 23;
> 
>     char a4 : 2;
> 
>     int64_t a5;
> 
>     int a6 : 5;
> 
>     int64_t a7 : 3;
>   };
> 
>   int
>   main (int argc, char *argv[])
>   {
>     struct tyu e;
> 
>     e.a1 = e.a2 = e.a3 = e.a4 = e.a6 = e.a7 = -1;
> 
>     return 0;
>   }
> 
> After stopping GDB at the "return 0;" line, here's what we see when we
> print "e" on x86_64:
> 
>   (gdb) p e
>   $1 = {a1 = -1, a2 = -1, a3 = -1, a4 = -1 '\377', a5 = 140737488344880, a6 = -1, a7 = -1}
> 
> While on PPC64BE:
> 
>   (gdb) p e
>   $1 = {a1 = -1, a2 = 3, a3 = 3, a4 = 3 '\003', a5 = 70367536153528, a6 = -1, a7 = -1}
> 

You didn't initialize e.a5, so even the x86_64 version looks
wrong at first.  You're seeing stack/register garbage in
the padding holes.

You should make that "e" a global to make sure all its
underlying bytes are clear, including padding.  Or memset it.
The former is easier.

a2, a3 and a4 in the PPC64 version do look odd.  Though
maybe that's something do to with the expression you used.

Does it make a difference if you initialize all fields
with separate statements, like:

 e.a1 = -1;
 e.a2 = -1;
 etc.

> As for "ptype /o", the offsets printed on x86_64 and PPC64BE are the
> same:

So it sounds like we could remove the x86-64 check in the 
testcase and let it run on all lp64 targets?  Does it pass
cleanly on PPC64?

Thanks,
Pedro Alves