GDB interactions with GCC

GDB interactions with GCC

[Jean Christophe Beyler]

Dear all,

I apologize if this is in the wrong mailing-list, I tried to determine
if this was more a GCC question than a GDB and decided to start out
with the GDB mailing list.

I'm currently helping a port of GDB to a new architecture and I am
having trouble understanding the interaction between GCC and GDB
regarding how GDB keeps track of what's on the stack, how to
backtrace, what variable is stored where.

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.

I admit I've never worked in the GDB-GCC interaction so I'm really
only starting to read documentation and understanding what does what.
I'm normally only in the GCC port so I've never ventured this far out.

Can anyone give me a simple break-down of what does what in this interaction?

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 ?
   - Does GCC need to output anything in particular to allow GDB to
give the information of the backtrace for example?

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.

- 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...

- Are there other documents than the GDB-internals and Bennet's HowTo ?

Thanks a lot,
Jc

Re: 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

Re: GDB interactions with GCC

[Jean Christophe Beyler]

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

Thanks, it's a start.

I am first gathering information and these seem to be like huge newbie
questions, for which I apologize. Can someone explain how GDB does to
remember what arguments were used in a backtrace ? Is it necessary
that they all reside on the stack or does GDB copy them somewhere for
later use, it the case of architectures that do not need to pass the
arguments on the stack?

Technically, on my architecture, if we had:

int bar (int a)
{
    return a;
}

int foo (int a, int b)
{
   return a + b;
}

the compiler would generate for foo something like:

...
add FirstInputRegister, FirstInputRegister, SecondInputRegister
call bar
...

Therefore, if I put a breakpoint at bar, if I look at
FirstInputRegister, I would have a+b but if I backtraced to foo, how
would GDB remember the values of a and b.

In this case, must GCC generate something like this instead :

...
store FirstInputRegister, 0(stack_pointer)
store SecondInputRegister, 8(stack_pointer)  #8 is just an offset,
let's suppose int is 8 bytes...
add FirstInputRegister, FirstInputRegister, SecondInputRegister
call bar
...

so that the arguments reside on the stack so that GDB can get them at
a later date ?

If so, doesn't that mean that if we want GDB on an architecture that
does not require any stack copies, we still have to generate those
uselessly (except for GDB ;-)) ?

Thanks again,
Jc

On Mon, Nov 2, 2009 at 6:16 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> 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
>
>

Re: GDB interactions with GCC

[Paul Pluzhnikov]

On Tue, Nov 3, 2009 at 9:22 AM, Jean Christophe Beyler
<jean.christophe.beyler@gmail.com> wrote:

> If so, doesn't that mean that if we want GDB on an architecture that
> does not require any stack copies, we still have to generate those
> uselessly (except for GDB ;-)) ?

You appear to be under mistaken assumption that GDB can only access stack
in the inferior process.

GDB can access *any* memory in the inferior, as well as registers. DWARF
debug info (which GCC generates) tells GDB where to find any variable. The
location (described by DWARF) could be "in register", "in memory at address
NNNN", or a complicated expression involving possibly multiple registers,
offsets and memory.

DWARF also describes how the register set changes when you step to
previous frame, so once you get to (say) frame #5, GDB knows the values
registers had in that frame, and can again (using DWARF debug info) tell you
values of parameters, locals, etc.

I think you should give http://dwarfstd.org/Dwarf3Std.php (and in particular
2.6: Location Descriptions) at least a quick read.

Cheers,
-- 
Paul Pluzhnikov

Re: GDB interactions with GCC

[Jean Christophe Beyler]

On Tue, Nov 3, 2009 at 12:38 PM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> On Tue, Nov 3, 2009 at 9:22 AM, Jean Christophe Beyler
> <jean.christophe.beyler@gmail.com> wrote:
>
>> If so, doesn't that mean that if we want GDB on an architecture that
>> does not require any stack copies, we still have to generate those
>> uselessly (except for GDB ;-)) ?
>
> You appear to be under mistaken assumption that GDB can only access stack
> in the inferior process.

Yes that I was aware of.

> GDB can access *any* memory in the inferior, as well as registers. DWARF
> debug info (which GCC generates) tells GDB where to find any variable. The
> location (described by DWARF) could be "in register", "in memory at address
> NNNN", or a complicated expression involving possibly multiple registers,
> offsets and memory.

Also, I know that, though I don't yet know how much GCC generates
automatically and how much work I must do in my port (but that's a GCC
issue).

> DWARF also describes how the register set changes when you step to
> previous frame, so once you get to (say) frame #5, GDB knows the values
> registers had in that frame, and can again (using DWARF debug info) tell you
> values of parameters, locals, etc.

My issue is this :

> so once you get to (say) frame #5, GDB knows the values registers had in that frame

How does it know if for example I do :

int foo (int a)
{
     return bar (a + 1);
}

On my architecture, I can have the code for foo reduced to :

add FirstInputRegister, FirstInputRegister, 1
call bar
branch return.

Therefore, once I'm in bar, the input register that foo had has been
lost since it's been incremented. The original value of a has been
lost since it is not in a particular register, was not spilled.

In this case, how does GDB handle it ? Is it still something that is
generated by DWARF ? Or is it now lost and if I want to support this
for my architecture, I must update the ABI to at least spill that
input register?

> I think you should give http://dwarfstd.org/Dwarf3Std.php (and in particular
> 2.6: Location Descriptions) at least a quick read.

I was reading this version
http://www.eagercon.com/dwarf/dwarf-2.0.0.pdf since I saw in GCC the
support of DWARF 2 :-). I'll read the section you speak of.

Thanks for your help,
Jc

Re: GDB interactions with GCC

[Daniel Jacobowitz]

On Tue, Nov 03, 2009 at 12:54:54PM -0500, Jean Christophe Beyler wrote:
> On my architecture, I can have the code for foo reduced to :
> 
> add FirstInputRegister, FirstInputRegister, 1
> call bar
> branch return.
> 
> Therefore, once I'm in bar, the input register that foo had has been
> lost since it's been incremented. The original value of a has been
> lost since it is not in a particular register, was not spilled.
> 
> In this case, how does GDB handle it ?

GDB will report that the value is not available.  If you compile
without optimization, GCC will generally save it in a stack slot, and
the value will be available.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB interactions with GCC

[Jean Christophe Beyler]

That is what I noticed as well. So you have confirmed that if we want
to retain that information, it needs to be stored on the stack even if
the optimization levels are used.

Thanks,
Jc

On Tue, Nov 3, 2009 at 1:01 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Nov 03, 2009 at 12:54:54PM -0500, Jean Christophe Beyler wrote:
>> On my architecture, I can have the code for foo reduced to :
>>
>> add FirstInputRegister, FirstInputRegister, 1
>> call bar
>> branch return.
>>
>> Therefore, once I'm in bar, the input register that foo had has been
>> lost since it's been incremented. The original value of a has been
>> lost since it is not in a particular register, was not spilled.
>>
>> In this case, how does GDB handle it ?
>
> GDB will report that the value is not available.  If you compile
> without optimization, GCC will generally save it in a stack slot, and
> the value will be available.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: GDB interactions with GCC

[Daniel Jacobowitz]

On Tue, Nov 03, 2009 at 01:09:04PM -0500, Jean Christophe Beyler wrote:
> That is what I noticed as well. So you have confirmed that if we want
> to retain that information, it needs to be stored on the stack even if
> the optimization levels are used.

Yes.  Most ABIs choose not to require this overhead, but there have
been some notable exceptions.

-- 
Daniel Jacobowitz
CodeSourcery