This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
register name for DW_AT_frame_base value
- From: Jerome Guitton <guitton at adacore dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 19 Apr 2005 18:29:27 +0200
- Subject: register name for DW_AT_frame_base value
A Dwarf interpretation question:
We have a problem to make GCC-compiled code interact with the HP
native debugger, and it looks like it is caused by the way the
attribute DW_AT_frame_base is interpreted. Apparently, when a frame
pointer can be found in a register, the value generated by GCC for the
DW_AT_frame_base of the corresponding subroutine is a register name
(i.e. DW_OP_reg<some_number>). Is it really allowed by the dwarf 2
standard? I would tend to think that it is not.
The "definition" of DW_AT_frame_base is:
"A subroutine or entry point entry may also have a DW_AT_frame_base
attribute, whose value is a location description that computes the
frame base for the subroutine or entry point."
OK. So, it is a location description. A location description can be
either a register name or an addressing operation, so at first glance
it is correct. But if the value is a "location description that
computes the frame base", when evaluated it should be an address;
so it cannot be a register name, IMHO.
I think it is even clearer when you read the definition of DW_OP_fbreg:
"The DW_OP_fbreg operation provides a signed LEB128 offset from the
address specified by the location description in the DW_AT_frame_base
attribute of the current function. (This is typically a stack pointer
register plus or minus some offset. On more sophisticated systems it
might be a location list that adjusts the offset according to changes
in the stack pointer as the PC changes.)"
I really looks like the behavior of DW_OP_fbreg is not specified when
the value of DW_AT_frame_base is a register name. And the example of
DW_OP_fbreg makes it quite clear, I think:
DW_OP_fbreg -50
Given an DW_AT_frame_base value of OPBREG31 64, this example computes
the address of a local variable that is -50 bytes from a logical frame
pointer that is computed by adding 64 to the current stack pointer
(register 31).
So, when a frame pointer is stored into a register <regno>, I would
say that the value of DW_AT_frame_base should be something like
"DW_OP_bregx <regno> 0" instead of something like "DW_OP_regx <regno>".
Opinions/thoughts? If we agree on that, I should be able to submit a
patch pretty soon; it should be quite easy to fix (provided that there
is something to fix).
--
Jerome