GDB question - Linux

This is a discussion on GDB question - Linux ; Hai, sorry if this is the wrong place to ask this question but i dont know where to ask.. i compiled the following code and ran it in GDB, with the break point at main. #include int main() { static ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: GDB question

  1. GDB question

    Hai, sorry if this is the wrong place to ask this question but i dont
    know where to ask..
    i compiled the following code and ran it in
    GDB, with the break point at main.

    #include
    int main()
    {
    static int i=0;
    if (10 == i)
    return ;
    i++;
    main();
    printf("%d\n", i );

    }

    Whenever main is being called recursively , i did a "backstrace' , but
    instead of showing many frames of main, it always shows only one frame
    of main().. WHY?

  2. Re: GDB question

    victor wrote:

    > Hai, sorry if this is the wrong place to ask this question but i dont
    > know where to ask..
    > i compiled the following code and ran it in
    > GDB, with the break point at main.
    >
    > #include
    > int main()
    > {
    > static int i=0;
    > if (10 == i)
    > return ;
    > i++;
    > main();
    > printf("%d\n", i );
    >
    > }
    >
    > Whenever main is being called recursively , i did a "backstrace' , but
    > instead of showing many frames of main, it always shows only one frame
    > of main().. WHY?

    AFAIK, main() in reserved as the main entry point into the app. Perhaps it
    isn't seen as being recursive? Try putting the recursive code in its own
    function and have that function called by main().

    Alvin

  3. Re: GDB question

    "victor" writes:

    > Hai, sorry if this is the wrong place to ask this question but i dont
    > know where to ask..
    > i compiled the following code and ran it in
    > GDB, with the break point at main.
    >
    > #include
    > int main()
    > {
    > static int i=0;
    > if (10 == i)
    > return ;
    > i++;
    > main();
    > printf("%d\n", i );
    >
    > }
    >
    > Whenever main is being called recursively , i did a "backstrace' , but
    > instead of showing many frames of main, it always shows only one frame
    > of main().. WHY?
    >
    There's some relevant information at
    http://developer.apple.com/documenta...gdb/gdb_7.html
    Essentially, main() isn't really your program's first stack frame --
    there's some runtime systems stuff that goes on, that then calls
    main(). When gdb is doing a backtrace, it assumes when it hits main()
    that there isn't going to be anything more of any relevance and stops.

    In other words, it assumes you won't be doing anything so daft as to
    call main() recursively.
    --
    Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
    Department of Computer Science FAX -- (505) 646-1002
    New Mexico State University http://www.cs.nmsu.edu/~pfeiffer

  4. Re: GDB question

    victor wrote:
    > Hai, sorry if this is the wrong place to ask this question but i dont
    > know where to ask..
    > i compiled the following code and ran it in
    > GDB, with the break point at main.
    >
    > #include
    > int main()
    > {
    > static int i=0;
    > if (10 == i)
    > return ;
    > i++;
    > main();
    > printf("%d\n", i );
    >
    > }
    >
    > Whenever main is being called recursively , i did a "backstrace' , but
    > instead of showing many frames of main, it always shows only one frame
    > of main().. WHY?
    >

    Funny example !

    I had two theories:

    1) The way GDB is deciding who holds the initial frame is linked to the
    main() function.

    2) The binary contains some initialization that does not appear on the C
    side.

    But, 2) is wrong. Indeed, I did an "objdump -D" of the program and got:

    08048354
    :
    8048354: 8d 4c 24 04 lea 0x4(%esp),%ecx
    8048358: 83 e4 f0 and $0xfffffff0,%esp
    804835b: ff 71 fc pushl 0xfffffffc(%ecx)
    804835e: 55 push %ebp
    804835f: 89 e5 mov %esp,%ebp
    8048361: 51 push %ecx
    8048362: 83 ec 14 sub $0x14,%esp
    8048365: a1 b8 95 04 08 mov 0x80495b8,%eax
    804836a: 83 f8 0a cmp $0xa,%eax
    804836d: 74 25 je 8048394
    804836f: a1 b8 95 04 08 mov 0x80495b8,%eax
    8048374: 40 inc %eax
    8048375: a3 b8 95 04 08 mov %eax,0x80495b8
    804837a: e8 d5 ff ff ff call 8048354

    804837f: a1 b8 95 04 08 mov 0x80495b8,%eax
    8048384: 89 44 24 04 mov %eax,0x4(%esp)
    8048388: c7 04 24 a8 84 04 08 movl $0x80484a8,(%esp)
    804838f: e8 fc fe ff ff call 8048290
    8048394: 83 c4 14 add $0x14,%esp
    8048397: 59 pop %ecx
    8048398: 5d pop %ebp
    8048399: 8d 61 fc lea 0xfffffffc(%ecx),%esp
    804839c: c3 ret
    804839d: 90 nop
    804839e: 90 nop
    804839f: 90 nop

    So, the code jump directly to 8048354 (starting immediately main()) when
    main() is called (no initialization in between).

    But, indeed, the stack frame is changing (and the value of i):

    Breakpoint 1, main () at recur.c:5
    1: i = 0
    (tgdb) info frame
    Stack level 0, frame at 0xbfa86280:
    eip = 0x8048365 in main (recur.c:5); saved eip 0xb7dd6ea8
    source language c.
    Arglist at 0xbfa86278, args:
    Locals at 0xbfa86278, Previous frame's sp at 0xbfa86274
    Saved registers:
    ebp at 0xbfa86278, eip at 0xbfa8627c
    (tgdb) c
    Continuing.

    Breakpoint 1, main () at recur.c:5
    1: i = 1
    (tgdb) info frame
    Stack level 0, frame at 0xbfa86250:
    eip = 0x8048365 in main (recur.c:5); saved eip 0x804837f
    source language c.
    Arglist at 0xbfa86248, args:
    Locals at 0xbfa86248, Previous frame's sp at 0xbfa86244
    Saved registers:
    ebp at 0xbfa86248, eip at 0xbfa8624c

    Note that eip is still the same each time.

    So my conclusion is that "main" must be somehow linked to the frame #0
    for GDB.

    But, I would be pleased to have a more in depth explanation (if somebody
    has some stuff about it).

    Regards
    --
    Emmanuel Fleury | Office: 261
    Associate Professor, | Phone: +33 (0)5 40 00 69 34
    LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69
    351, Cours de la Libération | email: emmanuel.fleury@labri.fr
    33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury

  5. Re: GDB question



    On Jan 6, 1:35 am, Emmanuel Fleury wrote:
    > victor wrote:
    > > Hai, sorry if this is the wrong place to ask this question but i dont
    > > know where to ask..
    > > i compiled the following code and ran it in
    > > GDB, with the break point at main.
    >
    > > #include
    > > int main()
    > > {
    > > static int i=0;
    > > if (10 == i)
    > > return ;
    > > i++;
    > > main();
    > > printf("%d\n", i );
    >
    > > }
    >
    > > Whenever main is being called recursively , i did a "backstrace' , but
    > > instead of showing many frames of main, it always shows only one frame
    > > of main().. WHY?Funny example !
    >
    > I had two theories:
    >
    > 1) The way GDB is deciding who holds the initial frame is linked to the
    > main() function.
    >
    > 2) The binary contains some initialization that does not appear on the C
    > side.
    >
    > But, 2) is wrong. Indeed, I did an "objdump -D" of the program and got:
    >
    > 08048354
    :
    > 8048354: 8d 4c 24 04 lea 0x4(%esp),%ecx
    > 8048358: 83 e4 f0 and $0xfffffff0,%esp
    > 804835b: ff 71 fc pushl 0xfffffffc(%ecx)
    > 804835e: 55 push %ebp
    > 804835f: 89 e5 mov %esp,%ebp
    > 8048361: 51 push %ecx
    > 8048362: 83 ec 14 sub $0x14,%esp
    > 8048365: a1 b8 95 04 08 mov 0x80495b8,%eax
    > 804836a: 83 f8 0a cmp $0xa,%eax
    > 804836d: 74 25 je 8048394
    > 804836f: a1 b8 95 04 08 mov 0x80495b8,%eax
    > 8048374: 40 inc %eax
    > 8048375: a3 b8 95 04 08 mov %eax,0x80495b8
    > 804837a: e8 d5 ff ff ff call 8048354

    > 804837f: a1 b8 95 04 08 mov 0x80495b8,%eax
    > 8048384: 89 44 24 04 mov %eax,0x4(%esp)
    > 8048388: c7 04 24 a8 84 04 08 movl $0x80484a8,(%esp)
    > 804838f: e8 fc fe ff ff call 8048290
    > 8048394: 83 c4 14 add $0x14,%esp
    > 8048397: 59 pop %ecx
    > 8048398: 5d pop %ebp
    > 8048399: 8d 61 fc lea 0xfffffffc(%ecx),%esp
    > 804839c: c3 ret
    > 804839d: 90 nop
    > 804839e: 90 nop
    > 804839f: 90 nop
    >
    > So, the code jump directly to 8048354 (starting immediately main()) when
    > main() is called (no initialization in between).
    >
    > But, indeed, the stack frame is changing (and the value of i):
    >
    > Breakpoint 1, main () at recur.c:5
    > 1: i = 0
    > (tgdb) info frame
    > Stack level 0, frame at 0xbfa86280:
    > eip = 0x8048365 in main (recur.c:5); saved eip 0xb7dd6ea8
    > source language c.
    > Arglist at 0xbfa86278, args:
    > Locals at 0xbfa86278, Previous frame's sp at 0xbfa86274
    > Saved registers:
    > ebp at 0xbfa86278, eip at 0xbfa8627c
    > (tgdb) c
    > Continuing.
    >
    > Breakpoint 1, main () at recur.c:5
    > 1: i = 1
    > (tgdb) info frame
    > Stack level 0, frame at 0xbfa86250:
    > eip = 0x8048365 in main (recur.c:5); saved eip 0x804837f
    > source language c.
    > Arglist at 0xbfa86248, args:
    > Locals at 0xbfa86248, Previous frame's sp at 0xbfa86244
    > Saved registers:
    > ebp at 0xbfa86248, eip at 0xbfa8624c
    >
    > Note that eip is still the same each time.
    >
    > So my conclusion is that "main" must be somehow linked to the frame #0
    > for GDB.
    >
    > But, I would be pleased to have a more in depth explanation (if somebody
    > has some stuff about it).
    >
    AFAIK, gdb has two options to decide the backtrace path.
    1) If you compile your program with -g, this will produce DWARF2 info
    in your object file.
    2) If not compiled wilth -g, the gdb will try to guess the stack frame
    by prologue

    Obviously the main doesn't has prologue.

    Refer to gdb internals.

    > Regards
    > --
    > Emmanuel Fleury | Office: 261
    > Associate Professor, | Phone: +33 (0)5 40 00 69 34
    > LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69
    > 351, Cours de la Libération | email: emmanuel.fle...@labri.fr
    > 33405 Talence Cedex, France | URL:http://www.labri.fr/~fleury

+ Reply to Thread
« Measuring the sound level in a hobby room when drilling. | syslog.h »