A study of the principle of coredump Problem Linux x86 6.2 section C + + style data structure memory layout of a class with member variables

The above section has explored the identification of this pointer, and the contents of the class can be seen by the this pointer. Here, it is up to the this pointer to see how the member variables of the class are arranged.

Let's look at an example.

  1 #include <stdio.h>  2 class Xuzhina_dump_c06_s2  3 {  4     private:  5 short         m_c;  6         char m_d;  7         int m_e;  8   9     public:10         xuzhina_dump_c06_s2 (int a, int b) Each         {             M_c = (short) (A + B);             m_d = ' d '; M_e = A A-             B; +         void print ()             page {printf ("member%d,%c,%d\n", M_c, M_d, m_e); 19< c23/>} 20}; The  int main ()     is {xuzhina_dump_c06_s2 Test (2, 3);     test.print (); +     return 0; 27}

Assembly Code:

(GDB) disassemble maindump of assembler code for function main:0x08048570 <+0>: Push%EBP 0x08048571 < +1&GT: mov%esp,%ebp 0x08048573 <+3>: and $0xfffffff0,%esp 0x08048576 <+6>: Sub $0x2 0,%esp 0x08048579 <+9>: Movl $0x3,0x8 (%ESP) 0x08048581 <+17>: Movl $0x2,0x4 (%ESP) 0x08048589   <+25&gt: Lea 0x18 (%ESP),%eax 0x0804858d <+29>: mov%eax, (%ESP) 0x08048590 <+32>: Call 0X80485B2 <_ZN19xuzhina_dump_c06_s2C2Eii> 0x08048595 <+37>: Lea 0x18 (%ESP),%eax 0x08048599 <+41& GT: mov%eax, (%ESP) 0x0804859c <+44>: Call 0x80485de <_ZN19xuzhina_dump_c06_s25printEv> 0x0804 85A1 <+49>: mov $0x0,%eax 0x080485a6 <+54>: jmp 0x80485b0 <main+64> 0x080485a8 &LT;+56&G t;: mov%eax, (%ESP) 0x080485ab <+59>: Call 0x8048460 <[email protected]> 0x080485b0 <+6 4>: Leave 0x080485B1 <+65>: ret End of assembler dump. 

It is known from the above code that when the test is constructed, the value of its three members is 5, ' d ', -1 (0xFFFFFFFF), and it is learned from the previous section that when the member function of the class is called, the this pointer is placed in the stack as the first argument.

So, you can see at the command address 0x0804859c break point, when the function runs to the breakpoint, ECX points to the memory is how to store 5, ' d ', -1 of these three values.

(GDB) Tbreak *0x0804859ctemporary Breakpoint 1 at 0x804859c (GDB) rstarting program:/HOME/BUCKXU/WORK/6/2/XUZHINA_DUMP_ C6_s2 Temporary breakpoint 1, 0x0804859c in Main () (GDB) x/8x $esp +0x180xbffff478:     0x08640005      0xFFFFFFFF      0x 08048620      0x000000000xbffff488:     0x00000000      0x4362f635      0x00000001      0xbffff524 (gdb) x/c 0xbffff47a0xbffff47a:     ' d '

You can see the contents of this pointer pointing to memory according to the order from low to High is 5, D,-1 respectively. Because of M_c, m_d are char,short types respectively, so they are squeezed into the same 32-bit unit for memory alignment.

It can be concluded that there is no difference between the member variable arrangement of a class and the struct body, except that when the member function is called, the this pointer is placed on the stack as the first parameter of the member function. That is, to locate the coredump problem, look at the first parameter when invoking the class member function, find the this pointer, and then view the value of each member variable of the class according to the this pointer.

At the same time, it can be seen that the difference between invoking a class member function and calling a normal function is that the this pointer is passed as the first parameter each time the class member function is called. This distinction should be the reason that a class member function can invoke a class member variable directly, because the first argument can be used as a base address to access the variable.

You can look at the assembly of the print function for class Xuzhina_dump_c06_s2:

(gdb) Shell c++filt _zn19xuzhina_dump_c06_s25printevxuzhina_dump_c06_s2::p rint () (GDB) Disassemble _zn19xuzhina_dump _c06_s25printevdump of assembler code for function _ZN19XUZHINA_DUMP_C06_S25PRINTEV:0X080485DE <+0>: Push%     EBP 0x080485df <+1>: mov%esp,%ebp 0x080485e1 <+3>: Sub $0x18,%esp 0x080485e4 <+6>:     mov 0x8 (%EBP),%eax//this pointer 0x080485e7 <+9>: mov 0x4 (%eax),%ecx//m_e 0x080485ea <+12>: mov 0x8 (%EBP),%eax//this pointer 0x080485ed <+15>: Movzbl 0x2 (%eax),%eax//m_d 0x080485f1 <+19>: MOVSBL%a L,%edx 0x080485f4 <+22>: mov 0x8 (%EBP),%eax//this pointer 0x080485f7 <+25>: Movzwl (%eax),%eax//m_c 0 X080485FA <+28>: Cwtl 0x080485fb <+29>: mov%ecx,0xc (%ESP) 0x080485ff <+33>: mov% edx,0x8 (%ESP) 0x08048603 <+37>: mov%eax,0x4 (%ESP) 0x08048607 <+41>: Movl $0x80486b4, (%ESP) 0 X0804860E <+48>: Call  0x8048440 <[email protected]> 0x08048613 <+53>: Leave 0x08048614 <+54>: ret End of Assembler dump.

As you can see, the class member function and the normal difference really lie in the use of the this pointer as the first parameter of the member function. This should also be why the class member function pointer declares the name of the class to be specified. Modify the source code of the example to verify this conclusion

  1 #include <stdio.h>  2 class Xuzhina_dump_c06_s2  3 {  4     private:  5 short         m_c;  6         char m_d;  7         int m_e;  8   9     public:10         xuzhina_dump_c06_s2 (int a, int b) Each         {             M_c = (short) (A + B);             m_d = ' d '; M_e = A A-             B; +         void print ()             page {printf ("member%d,%c,%d\n", M_c, M_d, m_e); 19< c23/>} 20}; typedef void (XUZHINA_DUMP_C06_S2::* func_ptr) (); the int main ()     is {xuzhina_dump_c06_s2 Test (2, 3);     func_ptr clsfuncptr = &xuzhina_dump_c06_s2::p rint ; (     test.*clsfuncptr) ();     0; 28}

Take a look at the assembly of the main function:

(GDB) disassemble maindump of assembler code for function main:0x08048570 <+0>: Push%EBP 0x08048571 < +1&GT: mov%esp,%ebp 0x08048573 <+3>: and $0xfffffff0,%esp 0x08048576 <+6>: Sub $0x2 0,%esp 0x08048579 <+9>: Movl $0x3,0x8 (%ESP) 0x08048581 <+17>: Movl $0x2,0x4 (%ESP) 0x08048589   <+25&gt: Lea 0x18 (%ESP),%eax 0x0804858d <+29>: mov%eax, (%ESP) 0x08048590 <+32>: Call 0x80485ee <_ZN19xuzhina_dump_c06_s2C2Eii> 0x08048595 <+37>: Movl $0x804861a,0x10 (%ESP) 0x0804859d &L    T;+45&gt: Movl $0x0,0x14 (%ESP) 0x080485a5 <+53>: mov 0x10 (%ESP),%eax 0x080485a9 <+57>: and   $0x1,%eax 0x080485ac <+60>: Test%eax,%eax 0x080485ae <+62>: jne 0x80485b6 <main+70> 0x080485b0 <+64>: mov 0x10 (%ESP),%eax 0x080485b4 <+68>: jmp 0x80485cd <main+93> 0x08048 5b6 <+70>: mov   0x14 (%ESP),%eax 0x080485ba <+74>: Lea 0x18 (%ESP),%edx 0x080485be <+78>: Add%edx,%eax 0x0    80485C0 <+80>: mov (%EAX),%edx 0x080485c2 <+82>: mov 0x10 (%ESP),%eax 0x080485c6 <+86>: Sub $0x1,%eax 0x080485c9 <+89>: add%edx,%eax 0X080485CB <+91>: mov (%EAX),%eax 0x08048   5CD <+93>: mov 0x14 (%ESP),%edx 0x080485d1 <+97>: Lea 0x18 (%ESP),%ecx 0x080485d5 <+101>: Add%ecx,%edx 0x080485d7 <+103>: mov%edx, (%ESP) 0x080485da <+106>: Call *%eax 0X080485DC    &LT;+108&GT: mov $0x0,%eax 0x080485e1 <+113>: jmp 0x80485eb <main+123> 0x080485e3 <+115>: mov%eax, (%ESP) 0x080485e6 <+118>: Call 0x8048460 <[email protected]> 0x080485eb &LT;+123&G t;: Leave 0X080485EC <+124>: ret End of assembler dump.

As can be seen, the use of a class member function pointer, like a class member function, takes the this pointer as the first parameter of a member function. This is also why you would specify an object or an object pointer when calling a class member function. As in this example

(TEST.*CLSFUNCPTR) ();

A study of the principle of coredump Problem Linux x86 6.2 section C + + style data structure memory layout of a class with member variables