Brain fart alert

Brain fart alert

[Nicolas]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

Hello,

I tried using pahole, but I get a brain fart alert with the file
attached (which is an extract from stdio.h). I'm running dwarves 1.10,
libdw1 0.152 and g++ 4.6.1, on i386.

Here is what I get:

$ g++ -Wall -g -c brainfart.cpp -o brainfart.o && pahole brainfart.o
class ios_base {
	enum _Ios_Openmodeconst    in;                   /*     0     4 */
	typedef enum _Ios_Fmtflags fmtflags;


	/* size: 1, cachelines: 1, members: 1 */
	/* padding: 65533 */
	/* last cacheline: 1 bytes */

	/* BRAIN FART ALERT! 1 != 4 + 0(holes), diff = -3 */

};

Moreover, on amd64, pahole segfaults if I do the same (with dwarves
1.10, libdw1 0.152, g++ 4.6.3).

Any ideas?

Thanks a lot,
Nicolas

[-- Attachment #2: brainfart.cpp --]
[-- Type: text/x-c++src, Size: 289 bytes --]

namespace std
{
  enum _Ios_Fmtflags
    {
      a = 1,
    };
  enum _Ios_Openmode
    {
      _S_in = 1L << 3,
    };
  class ios_base
  {
  public:
    typedef _Ios_Fmtflags fmtflags;
    static const _Ios_Openmode in = _S_in;
  };
  void setiosflags(ios_base::fmtflags __mask)  {  }
}

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Sat, Jul 21, 2012 at 08:22:33PM +0200, Nicolas escreveu:
> Hello,
> 
> I tried using pahole, but I get a brain fart alert with the file
> attached (which is an extract from stdio.h). I'm running dwarves 1.10,
> libdw1 0.152 and g++ 4.6.1, on i386.
> 
> Here is what I get:
> 
> $ g++ -Wall -g -c brainfart.cpp -o brainfart.o && pahole brainfart.o
> class ios_base {
> 	enum _Ios_Openmodeconst    in;                   /*     0     4 */
> 	typedef enum _Ios_Fmtflags fmtflags;
> 
> 
> 	/* size: 1, cachelines: 1, members: 1 */
> 	/* padding: 65533 */
> 	/* last cacheline: 1 bytes */
> 
> 	/* BRAIN FART ALERT! 1 != 4 + 0(holes), diff = -3 */
> 
> };
> 
> Moreover, on amd64, pahole segfaults if I do the same (with dwarves
> 1.10, libdw1 0.152, g++ 4.6.3).

that is strange, I just tried it on rhel6, x86_64, and just reproduced
what you describe on i386:

[acme@sandy pahole]$ uname -a
Linux sandy.ghostprotocols.net 3.6.0-rc1+ #13 SMP Fri Aug 10 12:42:33 BRT 2012 x86_64 x86_64 x86_64 GNU/Linux
[acme@sandy pahole]$ g++ -Wall -g -c brainfart.cpp -o brainfart.o && pahole brainfart.o
class ios_base {
	enum _Ios_Openmodeconst    in;                   /*     0     4 */
	typedef enum _Ios_Fmtflags fmtflags;


	/* size: 1, cachelines: 1, members: 1 */
	/* padding: 65533 */
	/* last cacheline: 1 bytes */

	/* BRAIN FART ALERT! 1 != 4 + 0(holes), diff = -3 */

};
[acme@sandy pahole]$ file brainfart.o
brainfart.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
[acme@sandy pahole]$

will try to fix this on the plane later today,

thanks for reporting and sorry for the late response,

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Wed, Aug 15, 2012 at 02:56:47PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sat, Jul 21, 2012 at 08:22:33PM +0200, Nicolas escreveu:
> > Hello,
> > 
> > I tried using pahole, but I get a brain fart alert with the file
> > attached (which is an extract from stdio.h). I'm running dwarves 1.10,
> > libdw1 0.152 and g++ 4.6.1, on i386.
> > 
> > Here is what I get:
> > 
> > $ g++ -Wall -g -c brainfart.cpp -o brainfart.o && pahole brainfart.o
> > class ios_base {
> > 	enum _Ios_Openmodeconst    in;                   /*     0     4 */
> > 	typedef enum _Ios_Fmtflags fmtflags;
> > 
> > 
> > 	/* size: 1, cachelines: 1, members: 1 */
> > 	/* padding: 65533 */
> > 	/* last cacheline: 1 bytes */
> > 
> > 	/* BRAIN FART ALERT! 1 != 4 + 0(holes), diff = -3 */
> > 
> > };
> > 
> > Moreover, on amd64, pahole segfaults if I do the same (with dwarves
> > 1.10, libdw1 0.152, g++ 4.6.3).
> 
> that is strange, I just tried it on rhel6, x86_64, and just reproduced
> what you describe on i386:
> 
> [acme@sandy pahole]$ uname -a
> Linux sandy.ghostprotocols.net 3.6.0-rc1+ #13 SMP Fri Aug 10 12:42:33 BRT 2012 x86_64 x86_64 x86_64 GNU/Linux
> [acme@sandy pahole]$ g++ -Wall -g -c brainfart.cpp -o brainfart.o && pahole brainfart.o
> class ios_base {
> 	enum _Ios_Openmodeconst    in;                   /*     0     4 */
> 	typedef enum _Ios_Fmtflags fmtflags;
> 
> 
> 	/* size: 1, cachelines: 1, members: 1 */
> 	/* padding: 65533 */
> 	/* last cacheline: 1 bytes */
> 
> 	/* BRAIN FART ALERT! 1 != 4 + 0(holes), diff = -3 */
> 
> };

So the problem is that 'in' is (from the .cpp file):

static const _Ios_Openmode in = _S_in;

 <2><82>: Abbrev Number: 10 (DW_TAG_member)
    <83>   DW_AT_name        : in       
    <86>   DW_AT_decl_file   : 1        
    <87>   DW_AT_decl_line   : 15       
    <88>   DW_AT_type        : <0x9b>   
    <8c>   DW_AT_external    : 1        
    <8d>   DW_AT_declaration : 1        
    <8e>   DW_AT_const_value : 8

So 'in' type is...

 <1><9b>: Abbrev Number: 12 (DW_TAG_const_type)
    <9c>   DW_AT_type        : <0x49>

That links to:

 <2><49>: Abbrev Number: 3 (DW_TAG_enumeration_type)
    <4a>   DW_AT_name        : (indirect string, offset: 0xa9): _Ios_Openmode   
    <4e>   DW_AT_byte_size   : 4        
    <4f>   DW_AT_decl_file   : 1        
    <50>   DW_AT_decl_line   : 7        

So it thinks that the size is 4 bytes:

65533 == (unsigned short)((short)(1 - 4))

I need to capture the fact that it is a static const, and investigate
the C++ structure encoding rules, why is that it takes 1 byte when it
has no per instance members?

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Mark Wielaard]

On Thu, Aug 16, 2012 at 04:52:24PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Aug 15, 2012 at 02:56:47PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Sat, Jul 21, 2012 at 08:22:33PM +0200, Nicolas escreveu:
> So the problem is that 'in' is (from the .cpp file):
> 
> static const _Ios_Openmode in = _S_in;
> 
>  <2><82>: Abbrev Number: 10 (DW_TAG_member)
>     <83>   DW_AT_name        : in       
>     <86>   DW_AT_decl_file   : 1        
>     <87>   DW_AT_decl_line   : 15       
>     <88>   DW_AT_type        : <0x9b>   
>     <8c>   DW_AT_external    : 1        
>     <8d>   DW_AT_declaration : 1        
>     <8e>   DW_AT_const_value : 8

Although I cannot find it said explicitly in the DWARF spec I think
you can assume that any member with a const_value (and without a
data_member_location) doesn't occupy space.

> I need to capture the fact that it is a static const, and investigate
> the C++ structure encoding rules, why is that it takes 1 byte when it
> has no per instance members?

That is by definition in C++, in C it is a GNU extension to allow empty
structs. Depending on whether you compile an empty struct with gcc or g++
it will have a size on zero or one.
http://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html

Cheers,

Mark
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Dodji Seketeli]

Arnaldo Carvalho de Melo <acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
a écrit:

> I need to capture the fact that it is a static const, and investigate
> the C++ structure encoding rules,

The DWARF 4 spec reads in 5.5.6 - Data Member Entries:

    The member entry corresponding to a data member that is defined in a
    structure, union or class may have either a
    DW_AT_data_member_location attribute or a DW_AT_data_bit_offset
    attribute.

It turns out that for DW_TAG_member DIEs representing non-static data
members, GCC emits the DW_AT_data_member_location attribute.  If it's
not present, I guess you can safely assume the DIE is for a static data
member and that it does not contribute to the size of its enclosing
class.

-- 
		Dodji

--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Mon, Aug 20, 2012 at 03:45:51PM +0200, Dodji Seketeli escreveu:
> Arnaldo Carvalho de Melo <acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> a écrit:
> 
> > I need to capture the fact that it is a static const, and investigate
> > the C++ structure encoding rules,
> 
> The DWARF 4 spec reads in 5.5.6 - Data Member Entries:
> 
>     The member entry corresponding to a data member that is defined in a
>     structure, union or class may have either a
>     DW_AT_data_member_location attribute or a DW_AT_data_bit_offset
>     attribute.
> 
> It turns out that for DW_TAG_member DIEs representing non-static data
> members, GCC emits the DW_AT_data_member_location attribute.  If it's
> not present, I guess you can safely assume the DIE is for a static data

Right, unless it is in an union, ok.

> member and that it does not contribute to the size of its enclosing
> class.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Sat, Jul 21, 2012 at 08:22:33PM +0200, Nicolas escreveu:
> I tried using pahole, but I get a brain fart alert with the file
> attached (which is an extract from stdio.h). I'm running dwarves 1.10,
> libdw1 0.152 and g++ 4.6.1, on i386.
> 
> Here is what I get:
> 
> $ g++ -Wall -g -c brainfart.cpp -o brainfart.o && pahole brainfart.o
> class ios_base {
> 	enum _Ios_Openmodeconst    in;                   /*     0     4 */
> 	typedef enum _Ios_Fmtflags fmtflags;
> 
> 	/* size: 1, cachelines: 1, members: 1 */
> 	/* padding: 65533 */
> 	/* last cacheline: 1 bytes */
> 
> 	/* BRAIN FART ALERT! 1 != 4 + 0(holes), diff = -3 */

Can you please clone my git tree and try it from there?

git clone git://git.kernel.org/pub/scm/devel/pahole/pahole
cd pahole
mkdir build
cd build
cmake ..
cd ..
make -C build
build/pahole brainfart.o

Now I'm getting:

[acme@sandy pahole]$ build/pahole brainfart.o 
class ios_base {
	static enum _Ios_Openmodeconst    in = 8;        /*     0     0 */
	typedef enum _Ios_Fmtflags fmtflags;


	/* size: 1, cachelines: 0, members: 0, static members: 1 */
	/* last cacheline: 1 bytes */
};
[acme@sandy pahole]$

I still need to get the 'const' there, from the fact that it has a
DW_AT_const_value, that is already captured, just forgot to add the
'const' there, will do after some errands here.

Also I'll check that the member type is an enum, will lookup the
enumerator entry that has the DW_AT_const_value and replace that '8'
with it.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Mon, Aug 20, 2012 at 03:02:16PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sat, Jul 21, 2012 at 08:22:33PM +0200, Nicolas escreveu:
> > I tried using pahole, but I get a brain fart alert with the file
> > attached (which is an extract from stdio.h). I'm running dwarves 1.10,
> > libdw1 0.152 and g++ 4.6.1, on i386.
> > 
> > Here is what I get:
> > 
> > $ g++ -Wall -g -c brainfart.cpp -o brainfart.o && pahole brainfart.o
> > class ios_base {
> > 	enum _Ios_Openmodeconst    in;                   /*     0     4 */
> > 	typedef enum _Ios_Fmtflags fmtflags;
> > 
> > 	/* size: 1, cachelines: 1, members: 1 */
> > 	/* padding: 65533 */
> > 	/* last cacheline: 1 bytes */
> > 
> > 	/* BRAIN FART ALERT! 1 != 4 + 0(holes), diff = -3 */
> 
> Can you please clone my git tree and try it from there?
> 
> git clone git://git.kernel.org/pub/scm/devel/pahole/pahole
> cd pahole
> mkdir build
> cd build
> cmake ..
> cd ..
> make -C build
> build/pahole brainfart.o
> 
> Now I'm getting:
> 
> [acme@sandy pahole]$ build/pahole brainfart.o 
> class ios_base {
> 	static enum _Ios_Openmodeconst    in = 8;        /*     0     0 */
> 	typedef enum _Ios_Fmtflags fmtflags;
> 
> 
> 	/* size: 1, cachelines: 0, members: 0, static members: 1 */
> 	/* last cacheline: 1 bytes */
> };
> [acme@sandy pahole]$
> 
> I still need to get the 'const' there, from the fact that it has a
> DW_AT_const_value, that is already captured, just forgot to add the
> 'const' there, will do after some errands here.
> 
> Also I'll check that the member type is an enum, will lookup the
> enumerator entry that has the DW_AT_const_value and replace that '8'
> with it.

I also noticed that there is a problem when the static member is not the
first, related to bitfield hole detection, will fix it too.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Nicolas]

Hello,

> Can you please clone my git tree and try it from there?

I just gave it a try, and it seems to work for me, except that the
ios_base class has a size of 0 here (on amd64 with g++ 4.7). Thanks a
lot for fixing this!

On my i386 box, pahole segfaults in dwfl_module_getelf (in libdw.so.1,
version 0.153), but the problem may be on elfutils' side.

Nicolas
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Mark Wielaard]

On Thu, 2012-08-30 at 18:35 +0200, Nicolas wrote:
> On my i386 box, pahole segfaults in dwfl_module_getelf (in libdw.so.1,
> version 0.153), but the problem may be on elfutils' side.

I cannot replicate that on i386 with 0.152 or 0.155 (so it might be
0.153 specific). But could you give a bit more details, and/or supply
the binaries you tried to pahole, a core file or backtrace when this
happens?

Thanks,

Mark
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Nicolas]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

Hello,

I can't reproduce the segfault on i386 anymore (I updated my system
since last time I tried), but I got a new brain fart alert, with the
attached example.

As previously to reproduce: g++ -g -c brainfart2.cpp -o brainfart2.o &&
pahole brainfart2.o

Thanks a lot,
Nicolas


On 03/09/2012 14:22, Mark Wielaard wrote:
> On Thu, 2012-08-30 at 18:35 +0200, Nicolas wrote:
>> On my i386 box, pahole segfaults in dwfl_module_getelf (in libdw.so.1,
>> version 0.153), but the problem may be on elfutils' side.
> 
> I cannot replicate that on i386 with 0.152 or 0.155 (so it might be
> 0.153 specific). But could you give a bit more details, and/or supply
> the binaries you tried to pahole, a core file or backtrace when this
> happens?
> 
> Thanks,
> 
> Mark
> 


[-- Attachment #2: brainfart2.cpp --]
[-- Type: text/x-c++src, Size: 345 bytes --]

using namespace std;
namespace std
{
  template<class _CharT> struct char_traits;
  template<typename _CharT, typename _Traits = char_traits<_CharT> > class basic_ostream;
  typedef basic_ostream<char> ostream;
}
class A  {};
class B: public A {};
class C: public B
{
  virtual void f(std::ostream& os) const;
};
void C::f(ostream& os) const {}

Re: Brain fart alert

[Nicolas]

Hello,

Just pinging the list, about the alert triggered by the example in my
last email (brainfart2.cpp).

Cheers,
Nicolas


2012/9/25 Nicolas <nikos42-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Hello,
>
> I can't reproduce the segfault on i386 anymore (I updated my system
> since last time I tried), but I got a new brain fart alert, with the
> attached example.
>
> As previously to reproduce: g++ -g -c brainfart2.cpp -o brainfart2.o &&
> pahole brainfart2.o
>
> Thanks a lot,
> Nicolas
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Mark Wielaard]

On Tue, 2013-02-26 at 02:50 +0100, Nicolas wrote:
> Hello,
> 
> Just pinging the list, about the alert triggered by the example in my
> last email (brainfart2.cpp).

The issue is:

 [    69]    class_type
             name                 (string) "C"
             byte_size            (data1) 8
             decl_file            (data1) 1
             decl_line            (data1) 11
             containing_type      (ref4) [    69]
             sibling              (ref4) [    aa]
 [    77]      inheritance
               type                 (ref4) [    57]
               data_member_location (sdata) 0
               accessibility        (data1) public (1)
 [    7e]      member
               name                 (strp) "_vptr.C"
               type                 (ref4) [    bc]
               data_member_location (sdata) 0
               artificial           (flag) Yes

class__fprintf sees the inheritance and member at the same
data_member_location and skips the member (which contains the real
size).

You could work around it with the following patch:

diff --git a/dwarves_fprintf.c b/dwarves_fprintf.c
index 23da5b1..90d830a 100644
--- a/dwarves_fprintf.c
+++ b/dwarves_fprintf.c
@@ -1386,8 +1386,7 @@ size_t class__fprintf(struct class *class, const
struct cu
                ++printed;
 
                /* XXX for now just skip these */
-               if (tag_pos->tag == DW_TAG_inheritance &&
-                   pos->virtuality == DW_VIRTUALITY_virtual)
+               if (tag_pos->tag == DW_TAG_inheritance)
                        continue;
 
                /*

Just ignoring the virtuality. But I don't really understand the special
casing and sizing issues around inheritance. So why this works is a
mystery to me atm.

Cheers,

Mark

--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Tue, Feb 26, 2013 at 11:56:03AM +0100, Mark Wielaard escreveu:
> On Tue, 2013-02-26 at 02:50 +0100, Nicolas wrote:
> > Hello,
> > 
> > Just pinging the list, about the alert triggered by the example in my
> > last email (brainfart2.cpp).
> 
> The issue is:

Right, I don't recall why this was problematic, so I'm just doing what
you suggest and adding URL for this message in two mailing list archives
for the dwarves-u79uwXL29TY76Z2rM5mHXA@public.gmane.org mailing list.

Will try running again my regression tests on all the debuginfo packages
in a recent Fedora to check if this changes the behavior in some object.

- Arnaldo
 
>  [    69]    class_type
>              name                 (string) "C"
>              byte_size            (data1) 8
>              decl_file            (data1) 1
>              decl_line            (data1) 11
>              containing_type      (ref4) [    69]
>              sibling              (ref4) [    aa]
>  [    77]      inheritance
>                type                 (ref4) [    57]
>                data_member_location (sdata) 0
>                accessibility        (data1) public (1)
>  [    7e]      member
>                name                 (strp) "_vptr.C"
>                type                 (ref4) [    bc]
>                data_member_location (sdata) 0
>                artificial           (flag) Yes
> 
> class__fprintf sees the inheritance and member at the same
> data_member_location and skips the member (which contains the real
> size).
> 
> You could work around it with the following patch:
> 
> diff --git a/dwarves_fprintf.c b/dwarves_fprintf.c
> index 23da5b1..90d830a 100644
> --- a/dwarves_fprintf.c
> +++ b/dwarves_fprintf.c
> @@ -1386,8 +1386,7 @@ size_t class__fprintf(struct class *class, const
> struct cu
>                 ++printed;
>  
>                 /* XXX for now just skip these */
> -               if (tag_pos->tag == DW_TAG_inheritance &&
> -                   pos->virtuality == DW_VIRTUALITY_virtual)
> +               if (tag_pos->tag == DW_TAG_inheritance)
>                         continue;
>  
>                 /*
> 
> Just ignoring the virtuality. But I don't really understand the special
> casing and sizing issues around inheritance. So why this works is a
> mystery to me atm.
> 
> Cheers,
> 
> Mark
> 
> --
> To unsubscribe from this list: send the line "unsubscribe dwarves" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Brain fart alert

[David Sterba]

Hi,

with current git version 1.10 (79536f4f9587703c7136d2654824630689880f5c):

struct btrfs_path {
        struct extent_buffer *     nodes[8];             /*     0    64 */
        /* --- cacheline 1 boundary (64 bytes) --- */
        int                        slots[8];             /*    64    32 */
        int                        locks[8];             /*    96    32 */
        /* --- cacheline 2 boundary (128 bytes) --- */
        u8                         reada;                /*   128     1 */
        u8                         lowest_level;         /*   129     1 */

        /* Bitfield combined with previous fields */

        unsigned int               search_for_split:1;   /*   128:15  4 */
        unsigned int               keep_locks:1;         /*   128:14  4 */
        unsigned int               skip_locking:1;       /*   128:13  4 */
        unsigned int               leave_spinning:1;     /*   128:12  4 */
        unsigned int               search_commit_root:1; /*   128:11  4 */
        unsigned int               need_commit_sem:1;    /*   128:10  4 */
        unsigned int               skip_release_on_error:1; /*   128: 9  4 */

        /* size: 136, cachelines: 3, members: 12 */
        /* padding: 4 */
        /* bit_padding: 25 bits */
        /* last cacheline: 8 bytes */

        /* BRAIN FART ALERT! 136 != 136 + 0(holes), diff = 0 */

};

Looks like it's the bitfield combining.

$ gcc --version
gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]

binutils-2.23.2

Let me know if you need more information.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Wed, Nov 11, 2015 at 07:26:18PM +0100, David Sterba escreveu:
> Hi,
> 
> with current git version 1.10 (79536f4f9587703c7136d2654824630689880f5c):
> 
> struct btrfs_path {
>         struct extent_buffer *     nodes[8];             /*     0    64 */
>         /* --- cacheline 1 boundary (64 bytes) --- */
>         int                        slots[8];             /*    64    32 */
>         int                        locks[8];             /*    96    32 */
>         /* --- cacheline 2 boundary (128 bytes) --- */
>         u8                         reada;                /*   128     1 */
>         u8                         lowest_level;         /*   129     1 */
> 
>         /* Bitfield combined with previous fields */
> 
>         unsigned int               search_for_split:1;   /*   128:15  4 */
>         unsigned int               keep_locks:1;         /*   128:14  4 */
>         unsigned int               skip_locking:1;       /*   128:13  4 */
>         unsigned int               leave_spinning:1;     /*   128:12  4 */
>         unsigned int               search_commit_root:1; /*   128:11  4 */
>         unsigned int               need_commit_sem:1;    /*   128:10  4 */
>         unsigned int               skip_release_on_error:1; /*   128: 9  4 */
> 
>         /* size: 136, cachelines: 3, members: 12 */
>         /* padding: 4 */
>         /* bit_padding: 25 bits */
>         /* last cacheline: 8 bytes */
>         /* BRAIN FART ALERT! 136 != 136 + 0(holes), diff = 0 */
> };
 
> Looks like it's the bitfield combining.
 
> $ gcc --version
> gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
 
> binutils-2.23.2
 
> Let me know if you need more information.

Ok, so with:

[acme@zoo linux]$ pahole -C btrfs_path ../build/v4.3.0+/fs/btrfs/btrfs.o
die__process_function: tag not supported 0x4109 (GNU_call_site)!
struct btrfs_path {
	struct extent_buffer *     nodes[8];             /*     0    64 */
	/* --- cacheline 1 boundary (64 bytes) --- */
	int                        slots[8];             /*    64    32 */
	int                        locks[8];             /*    96    32 */
	/* --- cacheline 2 boundary (128 bytes) --- */
	int                        reada;                /*   128     4 */
	int                        lowest_level;         /*   132     4 */
	unsigned int               search_for_split:1;   /*   136:31  4 */
	unsigned int               keep_locks:1;         /*   136:30  4 */
	unsigned int               skip_locking:1;       /*   136:29  4 */
	unsigned int               leave_spinning:1;     /*   136:28  4 */
	unsigned int               search_commit_root:1; /*   136:27  4 */
	unsigned int               need_commit_sem:1;    /*   136:26  4 */
	unsigned int               skip_release_on_error:1; /*   136:25  4 */

	/* size: 144, cachelines: 3, members: 12 */
	/* padding: 4 */
	/* bit_padding: 25 bits */
	/* last cacheline: 16 bytes */
};
[acme@zoo linux]$

Ok, but then 'reada' and 'lowest_level' are both int in my file, lemme try
converting it and rebuilding...

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[David Sterba]

On Wed, Nov 11, 2015 at 05:11:51PM -0300, Arnaldo Carvalho de Melo wrote:
> > struct btrfs_path {
...
> >         u8                         reada;                /*   128     1 */
> >         u8                         lowest_level;         /*   129     1 */
...
> > };

> [acme@zoo linux]$ pahole -C btrfs_path ../build/v4.3.0+/fs/btrfs/btrfs.o
> die__process_function: tag not supported 0x4109 (GNU_call_site)!
> struct btrfs_path {
> 	struct extent_buffer *     nodes[8];             /*     0    64 */
> 	/* --- cacheline 1 boundary (64 bytes) --- */
> 	int                        slots[8];             /*    64    32 */
> 	int                        locks[8];             /*    96    32 */
> 	/* --- cacheline 2 boundary (128 bytes) --- */
> 	int                        reada;                /*   128     4 */
> 	int                        lowest_level;         /*   132     4 */
> 	unsigned int               search_for_split:1;   /*   136:31  4 */
> 	unsigned int               keep_locks:1;         /*   136:30  4 */
> 	unsigned int               skip_locking:1;       /*   136:29  4 */
> 	unsigned int               leave_spinning:1;     /*   136:28  4 */
> 	unsigned int               search_commit_root:1; /*   136:27  4 */
> 	unsigned int               need_commit_sem:1;    /*   136:26  4 */
> 	unsigned int               skip_release_on_error:1; /*   136:25  4 */
> 
> 	/* size: 144, cachelines: 3, members: 12 */
> 	/* padding: 4 */
> 	/* bit_padding: 25 bits */
> 	/* last cacheline: 16 bytes */
> };
> [acme@zoo linux]$
> 
> Ok, but then 'reada' and 'lowest_level' are both int in my file, lemme try
> converting it and rebuilding...

Yes, they're both 'int' in current git versions, I'm trying to reduce
size of the structure and using pahole to see the result. When both
members were switched to u8 the warning appeared. Sorry for confusion.
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Wed, Nov 11, 2015 at 10:05:19PM +0100, David Sterba escreveu:
> On Wed, Nov 11, 2015 at 05:11:51PM -0300, Arnaldo Carvalho de Melo wrote:
> > > struct btrfs_path {
> ...
> > >         u8                         reada;                /*   128     1 */
> > >         u8                         lowest_level;         /*   129     1 */
> ...
> > > };
...
> > 	int                        reada;                /*   128     4 */
> > 	int                        lowest_level;         /*   132     4 */
> > 	unsigned int               search_for_split:1;   /*   136:31  4 */
> > 	unsigned int               keep_locks:1;         /*   136:30  4 */
...
> > Ok, but then 'reada' and 'lowest_level' are both int in my file, lemme try
> > converting it and rebuilding...
 
> Yes, they're both 'int' in current git versions, I'm trying to reduce
> size of the structure and using pahole to see the result. When both
> members were switched to u8 the warning appeared. Sorry for confusion.

So, I did the change and got the same BFA, with:

gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) 

I'm trying to figure out how this can make sense:

	u8                reada;                   /*   128     1 */
	u8                lowest_level;            /*   129     1 */

	/* Bitfield combined with previous fields */

	unsigned int      search_for_split:1;      /*   128:15  4 */
	unsigned int      keep_locks:1;            /*   128:14  4 */
	unsigned int      skip_locking:1;          /*   128:13  4 */
	unsigned int      leave_spinning:1;        /*   128:12  4 */
	unsigned int      search_commit_root:1;    /*   128:11  4 */
	unsigned int      need_commit_sem:1;       /*   128:10  4 */
	unsigned int      skip_release_on_error:1; /*   128: 9  4 */

I.e. it is like skip_release_on_error uses the first bit of 'lowest_level',
i.e. the ninth bit starting at byte offset 128... I was expecting it to be:

	u8                reada;                   /*   128     1 */
	u8                lowest_level;            /*   129     1 */

	/* Bitfield combined with previous fields */

	unsigned int      search_for_split:1;      /*   128:22  4 */
	unsigned int      keep_locks:1;            /*   128:21  4 */
	unsigned int      skip_locking:1;          /*   128:20  4 */
	unsigned int      leave_spinning:1;        /*   128:19  4 */
	unsigned int      search_commit_root:1;    /*   128:18  4 */
	unsigned int      need_commit_sem:1;       /*   128:17  4 */
	unsigned int      skip_release_on_error:1; /*   128:16  4 */

Because by combining the bitfield with the two u8 before it, it would read as:

	unsigned int      reada:8;                 /*   128:0   4 */
	unsigned int      lowest_level:8;          /*   128:8   4 */


:-\

Looking at the readelf output now...

- Arnaldo

--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

Em Wed, Nov 11, 2015 at 07:13:40PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Nov 11, 2015 at 10:05:19PM +0100, David Sterba escreveu:
> > On Wed, Nov 11, 2015 at 05:11:51PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > struct btrfs_path {
> > ...
> > > >         u8                         reada;                /*   128     1 */
> > > >         u8                         lowest_level;         /*   129     1 */
> > ...
> > > > };
> ...
> > > 	int                        reada;                /*   128     4 */
> > > 	int                        lowest_level;         /*   132     4 */
> > > 	unsigned int               search_for_split:1;   /*   136:31  4 */
> > > 	unsigned int               keep_locks:1;         /*   136:30  4 */
> ...
> > > Ok, but then 'reada' and 'lowest_level' are both int in my file, lemme try
> > > converting it and rebuilding...
>  
> > Yes, they're both 'int' in current git versions, I'm trying to reduce
> > size of the structure and using pahole to see the result. When both
> > members were switched to u8 the warning appeared. Sorry for confusion.
> 
> So, I did the change and got the same BFA, with:
> 
> gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) 
> 
> I'm trying to figure out how this can make sense:
> 
> 	u8                reada;                   /*   128     1 */
> 	u8                lowest_level;            /*   129     1 */
> 
> 	/* Bitfield combined with previous fields */
> 
> 	unsigned int      search_for_split:1;      /*   128:15  4 */
> 	unsigned int      keep_locks:1;            /*   128:14  4 */
> 	unsigned int      skip_locking:1;          /*   128:13  4 */
> 	unsigned int      leave_spinning:1;        /*   128:12  4 */
> 	unsigned int      search_commit_root:1;    /*   128:11  4 */
> 	unsigned int      need_commit_sem:1;       /*   128:10  4 */
> 	unsigned int      skip_release_on_error:1; /*   128: 9  4 */
> 
> I.e. it is like skip_release_on_error uses the first bit of 'lowest_level',
> i.e. the ninth bit starting at byte offset 128... I was expecting it to be:
> 
> 	u8                reada;                   /*   128     1 */
> 	u8                lowest_level;            /*   129     1 */
> 
> 	/* Bitfield combined with previous fields */
> 
> 	unsigned int      search_for_split:1;      /*   128:22  4 */
> 	unsigned int      keep_locks:1;            /*   128:21  4 */
> 	unsigned int      skip_locking:1;          /*   128:20  4 */
> 	unsigned int      leave_spinning:1;        /*   128:19  4 */
> 	unsigned int      search_commit_root:1;    /*   128:18  4 */
> 	unsigned int      need_commit_sem:1;       /*   128:17  4 */
> 	unsigned int      skip_release_on_error:1; /*   128:16  4 */
> 
> Because by combining the bitfield with the two u8 before it, it would read as:
> 
> 	unsigned int      reada:8;                 /*   128:0   4 */
> 	unsigned int      lowest_level:8;          /*   128:8   4 */
> 
> 
> :-\
> 
> Looking at the readelf output now...

So, it seems to be a BFA, but on gcc's part, I'll try to cook a test...

 <2><10cb7>: Abbrev Number: 34 (DW_TAG_member)
    <10cb8>   DW_AT_name        : (indirect string, offset: 0x10d67): reada     
    <10cbf>   DW_AT_type        : <0xad>        
    <10cc3>   DW_AT_data_member_location: 128   
 <2><10cc4>: Abbrev Number: 34 (DW_TAG_member)
    <10cc5>   DW_AT_name        : (indirect string, offset: 0xfbc0): lowest_level       
    <10ccc>   DW_AT_type        : <0xad>        
    <10cd0>   DW_AT_data_member_location: 129   
 <2><10cd1>: Abbrev Number: 55 (DW_TAG_member)
    <10cd2>   DW_AT_name        : (indirect string, offset: 0xff9a): search_for_split   
    <10cd9>   DW_AT_type        : <0x78>        
    <10cdd>   DW_AT_byte_size   : 4     
    <10cde>   DW_AT_bit_size    : 1     
    <10cdf>   DW_AT_bit_offset  : 15    
    <10ce0>   DW_AT_data_member_location: 128   
 <2><10ce1>: Abbrev Number: 55 (DW_TAG_member)
    <10ce2>   DW_AT_name        : (indirect string, offset: 0x7278): keep_locks 
    <10ce9>   DW_AT_type        : <0x78>        
    <10ced>   DW_AT_byte_size   : 4     
    <10cee>   DW_AT_bit_size    : 1     
    <10cef>   DW_AT_bit_offset  : 14    
    <10cf0>   DW_AT_data_member_location: 128   
 <2><10cf1>: Abbrev Number: 55 (DW_TAG_member)
    <10cf2>   DW_AT_name        : (indirect string, offset: 0x8d9a): skip_locking       
    <10cf9>   DW_AT_type        : <0x78>        
    <10cfd>   DW_AT_byte_size   : 4     
    <10cfe>   DW_AT_bit_size    : 1     
    <10cff>   DW_AT_bit_offset  : 13    
    <10d00>   DW_AT_data_member_location: 128   
 <2><10d01>: Abbrev Number: 55 (DW_TAG_member)
    <10d02>   DW_AT_name        : (indirect string, offset: 0x1297b): leave_spinning    
    <10d09>   DW_AT_type        : <0x78>        
    <10d0d>   DW_AT_byte_size   : 4     
    <10d0e>   DW_AT_bit_size    : 1     
    <10d0f>   DW_AT_bit_offset  : 12    
    <10d10>   DW_AT_data_member_location: 128   
 <2><10d11>: Abbrev Number: 55 (DW_TAG_member)
    <10d12>   DW_AT_name        : (indirect string, offset: 0x1837): search_commit_root 
    <10d19>   DW_AT_type        : <0x78>        
    <10d1d>   DW_AT_byte_size   : 4     
    <10d1e>   DW_AT_bit_size    : 1     
    <10d1f>   DW_AT_bit_offset  : 11    
    <10d20>   DW_AT_data_member_location: 128   
 <2><10d21>: Abbrev Number: 55 (DW_TAG_member)
    <10d22>   DW_AT_name        : (indirect string, offset: 0x1205c): need_commit_sem   
    <10d29>   DW_AT_type        : <0x78>        
    <10d2d>   DW_AT_byte_size   : 4     
    <10d2e>   DW_AT_bit_size    : 1     
    <10d2f>   DW_AT_bit_offset  : 10    
    <10d30>   DW_AT_data_member_location: 128   
 <2><10d31>: Abbrev Number: 55 (DW_TAG_member)
    <10d32>   DW_AT_name        : (indirect string, offset: 0xcc1e): skip_release_on_error      
    <10d39>   DW_AT_type        : <0x78>        
    <10d3d>   DW_AT_byte_size   : 4     
    <10d3e>   DW_AT_bit_size    : 1     
    <10d3f>   DW_AT_bit_offset  : 9     
    <10d40>   DW_AT_data_member_location: 128   

--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Brain fart alert

[Arnaldo Carvalho de Melo]

ok, so its pahole that is getting this wrong, i.e. the offset is from
the end, so, if all would be represented as bitfields, it would be:

 	unsigned int      reada:8;                 /*   128:24  4 */
 	unsigned int      lowest_level:8;          /*   128:16  4 */
 
 	/* Bitfield combined with previous fields */
 
 	unsigned int      search_for_split:1;      /*   128:15  4 */
 	unsigned int      keep_locks:1;            /*   128:14  4 */
 	unsigned int      skip_locking:1;          /*   128:13  4 */
 	unsigned int      leave_spinning:1;        /*   128:12  4 */
 	unsigned int      search_commit_root:1;    /*   128:11  4 */
 	unsigned int      need_commit_sem:1;       /*   128:10  4 */
 	unsigned int      skip_release_on_error:1; /*   128: 9  4 */

And the bits from 0 to 8, 9 bits, would be the bit hole, well, in this
case, as it is at the end, bit padding, would be of just 9 bits, since
we're using 23 bits, I'll try fixing this.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html