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


"Peter.Schauer" wrote:
> 
> Fernando Nasser wrote:
> > Probably because there is no testcase for this... (hint hint hint)
> 
> I have spent some time to come up with testsuite cases for this,
> and fixing all the GDB bugs that turned up in the targets I have access to
> (Solaris sparc, Solaris x86, AIX 4.3, Linux x86).
> 
> I suspect that many more targets might fail on these testcases, so before I
> go to all the trouble for submitting proper RFAs for the changes (adding
> more comments and ChangeLog entries), is there any chance that the new
> testsuite cases get accepted ?
> 
> I'd also be interested in the test results on other targets for the new
> testcases.
> 

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

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