This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: RFD: Testsuite cases for inferior function calls


This seems to be a flaw with generic_push_dummy_frame, and I currently have
no idea how to fix it as well.

From a user perspective (User doesn't care where the breakpoint was hit, and
finish should work as expected), I'd say that this is a FAIL and should
stay a FAIL till it gets fixed (probably saying `known problem with...').

As the usage of XFAILs throughout the testsuite increased during the last
two years, you might as well XFAIL the test on the affected targets.

> Ok, I've tried them out and I have a few comments regarding the finish
> command issued inside a dummy function.
> 
> Issuing a finish command from within a call dummy gets us to the
> following statement in finish_command:
> 
> frame = get_prev_frame (selected_frame);
> 
> When setting up the dummy call hand_function_call () calls
> PUSH_DUMMY_FRAME. In my target definiton, as well as in about 10 others,
> PUSH_DUMMY_FRAME is mapped to generic_push_dummy_frame () which is
> preceded by the following comment:
> 
> /* Save all the registers on the dummy frame stack.  Most ports save the
>    registers on the target stack.  This results in lots of unnecessary
> memory
>    references, which are slow when debugging via a serial line. 
> Instead, we
>    save all the registers internally, and never write them to the
> stack.  The
>    registers get restored when the called function returns to the entry
> point,
>    where a breakpoint is laying in wait.  */
> 
> This means that the dummy stack is totally disconnected from the real
> stack, and
> consequently, when I do a finish I get:
> 
>    "finish" not meaningful in the outermost frame.
> 
> Consequently, issuing a backtrace inside the dummy only shows the dummy
> function call; not main () or anything else. 
> 
> As for the solution to this, I don't have one. It would not be enough
> for finish_command to check if pc is in a call dummy, since that doesn't
> reveal the relation between the call dummy stack and the real stack.
> XFAIL for !is_native would probably be assuming too much.
> 
> -- 
> Orjan Friberg              E-mail: orjan.friberg@axis.com
> Axis Communications AB     Phone:  +46 46 272 17 68

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de

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