This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: backtrace
Vineet,
Hi All,
Where can i find the functions need for backtrace(implemetation),
which present implemetation is simplest to start with?
Essentially look at the front end function called get_prev_frame
and the frame id specific stuff in the backend. You would need to
implement some sort of frame id builder for the backend for the
same so that you can get the correct frame ids for the dummy frames.
Q2: My target has hardware stack(where it pushes the return address at
CALL)(it does not pushes the return address on software stack), now we have
two stack one software stack and onther hardware stack.
so how do i implement "next", it reuires the return address at either
register or frame(which is not possible) even with modified prologue.
next command : how is it implemented : All this is with respect
to the current cvs head.
As is any other gdb command the next command is implemented by
the function next_command defined in the file infcmd.c .
In turn calls step_1 with the parameters 1, 0 , count_string=0x0
step_1(skip_subroutines,single_inst, count_string)
step_1 basically is called with the option to skip_subroutines ,
with single instruction mode turned off and the count string with
the string representing the count of the number of lines to be
skipped as specified by the user.
-- enable the long jump breakpoint so that any call to longjmp
might be caught
-- within a loop that loops count number of times
clear_proceed_status which clears out all variables saying what
to do when inferior is continued.
-- frame = get_current_frame() // try to get the current frame
and in the process create a sentinel frame if needed(The sentinel
frame is the top level frame in the frame unwinding chain)
-- get the frame id
-- get the step_sp . The current stack pointer.
-- then find the step_range_start and the step_range_end .. the
range of the instructions to be stepped for this particular
source line
-- It asks the debugger to step_over_calls and step_multi
-- Then proceed ((CORE_ADDR)-1,TARGET_SIGNAL_DEFAULT,1);
proceed tries to continue with the debuggee, ADDR is the address
to resume at, or -1 for resume where stopped. SIGNAL is the
signal to give it, or 0 for none, or -1 for act according to how
it stopped. STEP is nonzero if should trap after one instruction.
within proceed further checks are made whether the stop_pc has
any breakpoints set at that location .
Expect a trace trap after one instruction. and continue it
automatically and insert breakpoints then .
Set up prev_pc to the current pc value ..
---- further calls resume(step=1,sig=SIGNAL_0)
This resumes the inferior but allows a quit . this is useful if
the user wants to interrupt some lengthy single stepping
operations. a value of step = 1 is to step and zero to continue a
value of sig is given to the inferior.
target_resume (resume_ptid,step ,sig);
The difference between a step and a next as above is mainly the
step parameter with which the function gets called. So
essentially the algorithm is the same the only dependent feature
being that the amount of step that has to happen...
So that brings us to the question with respect to the backend
specific stuff that you would need to implement :
You would need to implement the frame unwinder , the prologue
parser for your architecture, the register unwinder for your
architecture .Also a target specific frame cache has to be
implemented . This is ofcourse stuff in a nutshell that you
possibly are aware of already.
The prologue parser essentially helps in identifying the
different instruction patterns that are generated by gcc / your
compiler for the prologue and hence identify the stack locations
for saved registers, return addresses, register spill areas on
the stack .
Ofcourse this is very coarse and I hope it is correct and helps
you out.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (http://www.codito.com)