This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Understanding GDB frames


Maxim Grigoriev <maxim@tensilica.com> writes:
>> It's worth pointing out that the 'PC' in a frame ID isn't the current
>> PC within the function.  It's always the PC of the function's entry
>> point, so that stepping within a function doesn't cause the frame ID
>> to change.  Usually it's a PC value returned by 'frame_func_unwind',
>> which takes care of calling get_pc_function_start for you.
>
> We've been using a function return address instead of the PC of the
> function's entry, and it works just fine.

Hmm.  Consider:

    void foo (void) { }
    void bar (void) { }

    main ()
    {
      int i;

      for (i = 0; i < 2; i++)
        {
          void (*f) (void) = i ? foo : bar;
          f ();
        }
    }

So, main will call bar first, then foo.  Both calls will have
identical incoming sp's, and identical return addresses.

Using the callee's entry point is more direct; there's less
opportunity for things to go wrong.  And the rest of GDB is already
working to cover up the shortcomings of that approach.  :)

> I think distinguishing frames can be improved by using the third
> argument of frame_id, which is a "special address". Most of the
> implementations don't use it.

What would you put there?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]