This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFD: Testsuite cases for inferior function calls
- To: orjan dot friberg at axis dot com (Orjan Friberg)
- Subject: Re: RFD: Testsuite cases for inferior function calls
- From: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Date: Mon, 18 Sep 2000 22:21:26 MET DST
- Cc: gdb-patches at sourceware dot cygnus dot com
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