backtrace

backtrace

[Vineet Sharma, Noida]

Hi All,
         Where can i find the functions need for backtrace(implemetation),
which present implemetation is simplest to start with?

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. 


Any oone faced this problem,  any suggestions?


Regards
Vineet

Re: backtrace

[Ramana Radhakrishnan]

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)