Re: [RFA] Deal with get ecs->stop_func_end fail

[teawater <teawater@gmail.com>]

OK. Thanks Michael.

Hui

On Fri, Oct 24, 2008 at 09:18, Michael Snyder <msnyder@vmware.com> wrote:
> teawater wrote:
>>
>> Hi Michael,
>>
>> I try a program and got:
>> (gdb) start
>> Temporary breakpoint 1 at 0x80483c1: file 1.c, line 20.
>> Starting program: /media/disk/a.out
>>
>> Temporary breakpoint 1, main () at 1.c:20
>> 20             int     b = 0;
>> (gdb) rec
>> (gdb) n
>> 21             int     c = 1;
>> (gdb)
>> 24              printf ("a = %d b = %d c = %d\n", a, b, c);
>> (gdb)
>> a = 0 b = 0 c = 1
>> 25             b = cool ();
>> (gdb) rn
>>
>> No more reverse-execution history.
>> main () at 1.c:20
>> 20             int     b = 0;
>>
>>
>> It's clear that "rn" got error.
>> This is because:
>>  find_pc_partial_function (stop_pc, &ecs->stop_func_name,
>>                            &ecs->stop_func_start, &ecs->stop_func_end);
>> This part get ecs->stop_func_end is 0.
>
> Aha.  This is because we have stepped backward into
> a shared-library trampoline.  You understand trampoline?
>
> It means that this was the first time the program calls
> "printf", which is in a shared library, so the program
> jumps into a jump table which causes the dymanic runtime
> resolver (ld-linux.so) to be called.
>
> We actually succeeded in "nexting" backward through printf,
> and then we succeeded in "nexting" backward thru _dl_runtime_resolver,
> but we failed when we hit the trampoline (backward).
>
> Give me some time, I need to figure out how to handle
> trampolines backward!   ;-)
>
> Meanwhile, this is obviously a problem in infrun, so
> it does not need to affect your work on record/replay.
>
> Leave this to me.   ;-)
>
>