"Research on the principle of Coredump" Linux x86 version 7.1 vector object

Let's take a look at the example:

  1 #include <vector>  2   3 int main ()  4 {  5     std::vector<int> Vec;  6     Vec.push_back (0xffeeffab);  7     Vec.push_back (0xabcdef01);  8     Vec.push_back (0x12345678);  9     return 0; 10}

Look at the assembly:

(GDB) b mainbreakpoint 1 at 0x8048697 (GDB) rstarting Program:/HOME/XUZHINA/CODE/S1/XUZHINA_DUMP_C07_S1 Breakpoint 1, 0x0 8048697 in Main () Missing separate debuginfos, Use:debuginfo-install glibc-2.12-1.149.el6_6.4.i686 libgcc-4.4.7-11.el6.i686 libstdc++-4.4.7-11.el6.i686 (GDB) disassemble Dump of assembler code for function main:0x080486 94 <+0>:p Ush%ebp 0x08048695 <+1>:mov%esp,%ebp=> 0x08048697 <+3>:and $0xfffffff0,%esp 0x  0804869a <+6>:p ush%esi 0x0804869b <+7>:p ush%ebx 0x0804869c <+8>:sub $0x38,%esp 0x0804869f <+11>:lea 0x18 (%ESP),%eax 0x080486a3 <+15>:mov%eax, (%ESP) 0x080486a6 <+18>:call 0x8048740 <_ZNSt6vectorIiSaIiEEC2Ev> 0x080486ab <+23>:movl $0xffeeffab,0x24 (%esp) 0x080486b3 <+31>:lea 0x (%ESP),%eax 0x080486b7 <+35>:mov%eax,0x4 (%esp) 0x080486bb <+39>:lea 0x18 (%ESP),%eax 0X080486BF <+43>:mov%eax, (%ESP) 0x080486c2 < +46>:call 0x80487b2 <_ZNSt6vectorIiSaIiEE9push_backERKi> 0x080486c7 <+51>:movl $0xabcdef01,0x28 (%es p) 0x080486cf <+59>:lea 0x28 (%ESP),%eax 0x080486d3 <+63>:mov%eax,0x4 (%esp) 0x080486d7 <+67> : Lea 0x18 (%ESP),%eax 0x080486db <+71>:mov%eax, (%ESP) 0x080486de <+74>:call 0x80487b2 <_znst6ve Ctoriisaiiee9push_backerki> 0x080486e3 <+79>:movl $0x12345678,0x2c (%esp) 0x080486eb <+87>:lea 0x2c (%ESP),%eax 0x080486ef <+91>:mov%eax,0x4 (%esp) 0x080486f3 <+95>:lea 0x18 (%ESP),%eax 0x080486f7 &L T;+99>:mov%eax, (%ESP) 0x080486fa <+102>:call 0x80487b2 <_ZNSt6vectorIiSaIiEE9push_backERKi> 0x080 486FF <+107>:mov $0x0,%ebx 0x08048704 <+112>:lea 0x18 (%ESP),%eax 0x08048708 <+116>:mov%eax , (%ESP) 0x0804870b <+119>:call 0x8048754 <_ZNSt6vectorIiSaIiEED2Ev> 0x08048710 <+124>:mov%ebx, %eax 0x08048712 <+126>:add $0x38,%esp 0x08048715 <+129>:p op%ebx 0x08048716 <+130>:p op%esi 0x08048717 <+131&     Gt;:mov%ebp,%esp 0x08048719 <+133>:p op%ebp 0x0804871a <+134>:ret 0x0804871b <+135>:mov %EDX,%EBX 0x0804871d <+137>:mov%eax,%esi 0x0804871f <+139>:lea 0x18 (%ESP),%eax 0x08048723 &lt ; +143>:mov%eax, (%ESP) 0x08048726 <+146>:call 0x8048754 <_ZNSt6vectorIiSaIiEED2Ev> 0x0804872b < +151>:mov%esi,%eax 0x0804872d <+153>:mov%ebx,%edx 0x0804872f <+155>:mov%eax, (%ESP) 0x0804 8732 <+158>:call 0x80485c8 <[email protected]>end of assembler dump.

by 0X080486A6,0X080486C2, 0x080486de, 0x080486fa, 0x0804870b near the address of the directive, the vector's this pointer is placed in esp+0x18.

In 0x080486a6,0x080486c2, 0x080486de, 0X080486FA, 0x0804870b break point to see how the this pointer points to how the content changes:

The constructor of the vector is called in 0X080486A6:

(GDB) Ccontinuing.breakpoint 2, 0x080486a6 in Main () (GDB) x/4x $esp +0x180xbffff248:0 XBFFFF2780X080491090X00210DF00X080483A4 (GDB) x/4x 0xbffff2780xbffff278:0xbffff2f80x0027ad360x000000010xbffff324 ( GDB) Ni0x080486ab in Main () (GDB) x/4x $esp +0x180xbffff248:0x000000000x000000000x000000000x080483a4

It is visible from above that a vector on the stack covers an area of three units.

After looking at the first push_back, what happened to the vector?

(GDB) Ccontinuing.breakpoint 3, 0x080486c2 in Main () (GDB) x/4x $esp +0x180xbffff248:0 X000000000x000000000x000000000xffeeffab (GDB) ni0x080486c7 in Main () (GDB) x/4x $esp +0x180xbffff248:0 X0804b0080x0804b00c0x0804b00c0xffeeffab (GDB) x/4x 0x0804b0080x804b008:0xffeeffab0x000000000x000000000x00020ff1

As you can see, the memory 0x0804b008 that the first member of the vector points to is exactly the first value 0xffeeffab that the push_back comes in. And the memory 0x0804b00c pointed to by the second member of the vector is exactly 4 bytes from the first member, is exactly the same as an int member in the vector.

Then take a look at the second push_back.

(GDB) Ccontinuing.breakpoint 4, 0x080486de in Main () (GDB) x/4x $esp +0x180xbffff248:0 X0804b0080x0804b00c0x0804b00c0xffeeffab (GDB) ni0x080486e3 in Main () (GDB) x/4x $esp +0x180xbffff248:0 X0804b0180x0804b0200x0804b0200xffeeffab (GDB) x/4x 0x0804b0180x804b018:0xffeeffab0xabcdef010x000000000x00020fe1

The values of the three members of the vector vary. The first member is changed from 0x0804b008 to 0x0804b018, but the contents of the first member point to the address are the same, or 0xffeeffab, and the neighboring unit is 0xabcdef01. Same as the value of the second vector. The second member differs from the first member by 8 bytes, which is exactly 2 int bytes, and the vector has exactly the same 2 members.

Take a look at the third push_back:

(GDB) Ccontinuing.breakpoint 5, 0x080486fa in Main () (GDB) x/4x $esp +0x180xbffff248:0 X0804b0180x0804b0200x0804b0200xffeeffab (GDB) ni0x080486ff in Main () (GDB) x/4x $esp +0x180xbffff248:0 X0804b0280x0804b0340x0804b0380xffeeffab (GDB) x/4x 0x0804b0280x804b028:0xffeeffab0xabcdef010x123456780x00000000

You can still get the first member pointing at the beginning of the vector element, and the second member is the next position at the end of the vector element. The difference between them and the element size quotient is just the number of elements.

If you re-examine char,short, long, float, double, array, struct, vector of the class object, and combine the definition of vector

(Refer to header file/usr/include/c++/4.4.7/bits/stl_vector.h) to get

"Research on the principle of Coredump" Linux x86 version 7.1 vector object