2

Can some please help me to understand this:-

Below is an extract from gdb. After my program crashed, I opened the binary and core file in gdb and issued the command info frame:

(gdb) info frame
Stack level 0, frame at 0xb75f7390:
 eip = 0x804877f in base::func() (testing.cpp:16); saved eip 0x804869a
 called by frame at 0xb75f73b0
 source language c++.
 Arglist at 0xb75f7388, args: this=0x0
 Locals at 0xb75f7388, Previous frame's sp is 0xb75f7390
 Saved registers:
  ebp at 0xb75f7388, eip at 0xb75f738c

What do the lines "ebp", "eip", "Locals at" and "Previous Frame's sp " mean? Please explain

scottt
  • 7,008
  • 27
  • 37
Dew
  • 2,993
  • 5
  • 17
  • 7
  • possible duplicate of [How to interpret GDB "info frame" output?](http://stackoverflow.com/questions/5144727/how-to-interpret-gdb-info-frame-output) – Employed Russian Mar 01 '11 at 04:37
  • Exact duplicate of http://stackoverflow.com/questions/5144727/how-to-interpret-gdb-info-frame-output. Why do you keep asking the same question? – Employed Russian Mar 01 '11 at 04:38
  • 3
    He is probably trying to get a more descriptive answer, probably didn't want to put the effort into reading all those wikipedia links. – anio Mar 01 '11 at 04:45

2 Answers2

6

This diagram from the Wikipedia article Call stack may help: Stack frame layout

GDB's info frame corresponds to functions being called in your program at run time. From the output, we can infer this about the stack frame layout:

  • 0xb75f7388: The 4 bytes starting here stores the old EBP value, 0xb75f73a8. The first value pushed by the function prologue of base::func()
  • 0xb75f738c: The 4 bytes starting here stores the return address, 0x804869a. Pushed by the call instruction in the previous frame
  • 0xb75f7390: The 4 bytes starting here stores the implicit this argument to base::func(), 0x00000000.

I'll explain the info frame output line by line:

Stack level 0, frame at 0xb75f7390:

Stack level 0 means this is the newest frame. The address after frame at is called the Canonical Frame Address (CFA). On x86, this is defined to be the value of the stack pointer (ESP) at the previous frame, before the call instruction is executed.

 eip = 0x804877f in base::func() (testing.cpp:16); saved eip 0x804869a

EIP is the x86 instruction pointer. saved eip is the return address. If you try to look up the function that contains 0x804869a with info symbol 0x804869a, it should point inside the function calling base::func().

 called by frame at 0xb75f73b0

called by shows the canonical frame address of the previous frame. We can see that the stack pointer advanced 32 bytes (0xb75f73b0 - 0xb75f7390 = 32) between the two frames.

 source language c++.

 Arglist at 0xb75f7388, args: this=0x0
 Locals at 0xb75f7388, Previous frame's sp is 0xb75f7390

The x86 ABI passes arguments on the stack. base::func() only has the single implicit this argument. The fact that it's 0x0 i.e. NULL bodes ill. On a side note, Arglist and Locals seem to always have the same value in info frame on x86 and x86-64.

 Saved registers:
  ebp at 0xb75f7388, eip at 0xb75f738c

Saved registers reflects the registers that were saved at function entry. It lists where the old register values are saved on the stack. Saved EIP is the return address so if you examine the address stored at 0xb75f738c with x/a 0xb75f738c it should give 0x804869a. The fact that EBP is listed here implies that your code probably was not compiled with -fomit-frame-pointer and has a standard function prologue:

push %ebp
movl %esp, %ebp

at the very begging of base::func() which sets up EBP to act as the frame pointer.

scottt
  • 7,008
  • 27
  • 37
0

To analyze core file, execute:

$gdb executable core

gdb$ bt -- backtrace

or gdb$ fr 0 -- the uppermost frame in the run-time stack gdb$ fr 1 & so on will give you the order of function calls which led to Seg Fault.

Here, gdb$info frame is providing you info about frame 0.

Sandeep Singh
  • 4,941
  • 8
  • 36
  • 56