GDB interactions with GCC

[David Daney]

Jean Christophe Beyler wrote:
[...]
> 
> For example, on my architecture, the return address is passed in one
> register that the function can push on the stack if it's necessary (if
> a call happens) but not if it's a leaf function. The local variables
> are also sent via registers and therefore, potentially are never
> stored on the stack.

This is similar to MIPS which is supported by gdb.

[...]

> And if someone can answer these questions:
> 
> - It seems to me that GCC outputs debug information that helps GDB
> follow the course of the program:
>    - With this information, is GDB able to follow where the local
> variables are kept (register or stack) depending on what the program
> is doing ?

Usually.

>    - Does GCC need to output anything in particular to allow GDB to
> give the information of the backtrace for example?
> 

Yes.

> In other words:
> 
> - Does the ABI need to store the stack pointer for each frame in order
> for GDB to give all the backtrace, variable information? Or does GDB
> keep track of this independantly of the ABI.

For some (many) archectures, the compiler emits debug information 
describing the information needed to generate a backtrace.  Look at 
.debug_frame sections in DWARF for example.  Given a lack of frame 
meta-data, you can have target specific code that does ad hoc stack and 
code examination to try to generate a backtrace.


> 
> - Does GDB require that the ABI store arguments at some point on the
> stack in order to provide information about a function calls
> arguments? I would assume not because otherwise register-based ABIs
> would have to redundantly copy things on the stack for GDB use...
> 

The debug data emitted by the compiler should allow gdb to track 
variable locations.  For most Linux systems this is specified by DWARF.

That is an simplified answer based on my limited knowledge of the subject.

David Daney