This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]