"Research on the principle of Coredump" Linux version x86 7.3 section list Object

Let's take a look at the example:

1 #include <list>  2   3 int main ()  4 {  5     std::list<int> lst;  6   7     lst.push_back (0x12345678);  8     Lst.push_front (0xabcdef01);  9     Lst.push_back (0x24242522);     return 0; 12}

Look at the assembly again:

(GDB) disassemble maindump of assembler code for function main:0x080485b4 <+0>:p ush%ebp 0x080485b5 <+1&gt ;: mov%esp,%ebp 0x080485b7 <+3>:and $0xfffffff0,%esp 0x080485ba <+6>:p ush%esi 0x080485bb <+7 >:p ush%ebx 0x080485bc <+8>:sub $0x38,%esp 0x080485bf <+11>:lea 0x1c (%ESP),%eax 0x080485c3 &L T;+15>:mov%eax, (%ESP) 0x080485c6 <+18>:call 0x8048674 <_ZNSt4listIiSaIiEEC2Ev> 0X080485CB <+23 &GT;:MOVL $0x12345678,0x24 (%ESP) 0x080485d3 <+31>:lea 0x24 (%ESP),%eax 0x080485d7 <+35>:mov%eax,0x 4 (%ESP) 0x080485db <+39>:lea 0x1c (%ESP),%eax 0x080485df <+43>:mov%eax, (%ESP) 0x080485e2 &LT;+46&G T;:call 0x80486de <_ZNSt4listIiSaIiEE9push_backERKi> 0x080485e7 <+51>:movl $0xabcdef01,0x28 (%ESP) 0x08 0485ef <+59>:lea 0x28 (%ESP),%eax 0x080485f3 <+63>:mov%eax,0x4 (%esp) 0x080485f7 <+67>:lea 0 X1C (%ESP),%eax 0x080485FB <+71>:mov%eax, (%ESP) 0x080485fe <+74>:call 0x8048714 <_ZNSt4listIiSaIiEE10push_frontERKi> 0x08048603 <+79>:movl $0x24242522,0x2c (%esp) 0x0804860b <+87>:lea 0x2c (%ESP),%eax 0x0804860f <+91&    Gt;:mov%eax,0x4 (%ESP)---Type <return> to continue, or Q <return> to quit---0x08048613 <+95>:lea 0x1c (%ESP),%eax 0x08048617 <+99>:mov%eax, (%ESP) 0x0804861a <+102>:call 0x80486de <_znst4listiis aiiee9push_backerki> 0x0804861f <+107>:mov $0x0,%ebx 0x08048624 <+112>:lea 0x1c (%ESP),%eax 0x08 048628 <+116>:mov%eax, (%ESP) 0x0804862b <+119>:call 0x8048660 <_ZNSt4listIiSaIiEED2Ev> 0x08048 630 <+124>:mov%ebx,%eax 0x08048632 <+126>:add $0x38,%esp 0x08048635 <+129>:p op%ebx 0x08 048636 <+130>:p op%esi 0x08048637 <+131>:mov%ebp,%esp 0x08048639 <+133>:p op%ebp 0x08048    63a <+134>:ret   0x0804863b <+135>:mov%edx,%ebx 0x0804863d <+137>:mov%eax,%esi 0x0804863f <+139>:lea 0x 1c (%ESP),%eax 0x08048643 <+143>:mov%eax, (%ESP) 0x08048646 <+146>:call 0x8048660 <_znst4listiisaii eed2ev> 0x0804864b <+151>:mov%esi,%eax 0x0804864d <+153>:mov%ebx,%edx 0x0804864f <+155> : mov%eax, (%ESP) 0x08048652 <+158>:call 0x80484e8 <[email protected]>end of assembler dump.

Seen by the assembly near 0x080485c6, this pointer is placed in the esp+0x1c

In 0x080485c6, 0x080485e2,0x080485fe, 0x0804861a, 0x0804862b break point

(GDB) b *0x080485c6breakpoint 1 at 0x80485c6 (GDB) b *0x080485e2breakpoint 2 at 0x80485e2 (GDB) b *0x080485febreakpoint 3 at 0x80485fe (GDB) b *0x0804861abreakpoint 4 at 0x804861a (GDB) b *0x0804862bbreakpoint 5 at 0x804862b

Let's take a look at how the list runs after the constructor.

Breakpoint 1, 0x080485c6 in Main () (GDB) x/8x $esp +0x1c0xbffff24c:0x08048aa90x028ea5500x0804832e0x000000000xbffff25c : 0x009faff40x08048a900x080485000x009faff4 (GDB) NI0X080485CB in Main () (GDB) x/8x $esp +0x1c0xbffff24c:0 Xbffff24c0xbffff24c0x0804832e0x000000000xbffff25c:0x009faff40x08048a900x080485000x009faff4

You can see that the list object has two members, and the values of the two members point to themselves. Visible, these two members are pointers.

Take a look at the first push_back.

Breakpoint 2, 0x080485e2 in Main () (GDB) x/8x $esp +0x1c0xbffff24c:0xbffff24c0xbffff24c0x123456780x000000000xbffff25c : 0x009faff40x08048a900x080485000x009faff4 (GDB) Ni0x080485e7 in Main () (GDB) x/8x $esp +0x1c0xbffff24c:0 X0804b0080x0804b0080x123456780x000000000xbffff25c:0x009faff40x08048a900x080485000x009faff4 (GDB) x/8x 0x0804b0080x804b008:0xbffff24c0xbffff24c0x123456780x00020ff10x804b018:0x000000000x000000000x000000000x00000000

The structure is represented as follows:

Look at Push_front again.

Breakpoint 3, 0x080485fe in Main () (GDB) x/8x $esp +0x1c0xbffff24c:0x0804b0080x0804b0080x123456780xabcdef010xbffff25c : 0x009faff40x08048a900x080485000x009faff4 (gdb) x/8x 0x0804b0080x804b008:0 xbffff24c0xbffff24c0x123456780x00020ff10x804b018:0x000000000x000000000x000000000x00000000 (GDB) ni0x08048603 in Main () (GDB) x/8x $esp +0x1c0xbffff24c:0x0804b0180x0804b0080x123456780xabcdef010xbffff25c:0 X009faff40x08048a900x080485000x009faff4 (GDB) x/8x 0x0804b0180x804b018:0 x0804b0080xbffff24c0xabcdef010x00020fe10x804b028:0x000000000x000000000x000000000x00000000 (GDB) x/8x 0x0804b0080x804b008:0xbffff24c0x0804b0180x123456780x000000110x804b018:0x0804b0080xbffff24c0xabcdef010x00020fe1

This is represented by a graphic (representing only the first member).

If you look at the second member of these three addresses, you will become such a graphic

The same observation of the second push_back, and the reference to the list of code, you will get this conclusion.

1. List has two members, the first member points to the head of the list, the second member points to the tail of the list

2. Each node of the list has three elements, the first _m_next, pointing to the next node. The second _m_prev points to the previous node. The value of the third _m_data storage node.

3. The list points to the list of _m_next of each node, the _m_prev pointer should not be empty, and must be to a valid address.

"Research on the principle of Coredump" Linux version x86 7.3 section list Object