Re: Fw: Extending calling convention information in DWARF output for x86

[Roger Cruz <roger_r_cruz at yahoo dot com>]

Hi Michael,

Thanks for replying to my questions.

What I like to obtain somehow is the calling convention of each routine so I can tell who is responsible for cleaning off the stack.? Two calling conventions of interest to me are: _stdcall and _cdecl which deal with the arguments in a slightly different way.? With _cdecl, the default calling convention for C and C++ programs, the calling function is responsible for cleaning off the stack (ie, adjusting SP by the number of bytes that were pushed onto the stack by the caller).? With _stdcall, it is the called function that is responsible for cleaning up the stack.? So I need to know the calling convention to know who is responsible for cleaning up the stack and by how many bytes.? In reality, I just need to know how much to move the SP after one of these functions is executed (emulated), the calling convention just helped detect which functions would have to have their stack pointer manipulated.


Now, you say that DWARF may already give me enough information to know how to unwind the stack.? Given what I have described here, what fields in DWARF can I use to determine when and by how much to manipulate the stack pointer?? Here is an example of the DWARF information I have available for each of the two types of calling convention:


A _cdecl function

<1><2641c>: Abbrev Number: 39 (DW_TAG_subprogram)
??? <2641d>?? DW_AT_name??????? : (indirect string, offset: 0x61d4): CLIPBOARD_SetClipboardOwner??????? 
??? <26421>?? DW_AT_decl_file?? : 2???? 
??? <26422>?? DW_AT_decl_line?? : 81??? 
??? <26423>?? DW_AT_prototyped? : 1???? 
??? <26424>?? DW_AT_type??????? : <0x1a430>???? 
??? <26428>?? DW_AT_low_pc????? : 0x25edc?????? 
??? <2642c>?? DW_AT_high_pc???? : 0x25fe0?????? 
??? <26430>?? DW_AT_frame_base? : 0xfa4 (location list)
??? <26434>?? DW_AT_sibling???? : <0x264c5>???? 

<2><26438>: Abbrev Number: 40 (DW_TAG_formal_parameter)
??? <26439>?? DW_AT_name??????? : (indirect string, offset: 0x868): hWnd??????? 
??? <2643d>?? DW_AT_decl_file?? : 2???? 
??? <2643e>?? DW_AT_decl_line?? : 81??? 
??? <2643f>?? DW_AT_type??????? : <0x1a659>???? 
??? <26443>?? DW_AT_location??? : 3 byte block: 91 ec 7e??????? (DW_OP_fbreg: -148)

?<2><26447>: Abbrev Number: 42 (DW_TAG_variable)
??? <26448>?? DW_AT_name??????? : (indirect string, offset: 0x62ac): bRet?????? 
??? <2644c>?? DW_AT_decl_file?? : 2???? 
??? <2644d>?? DW_AT_decl_line?? : 83??? 
??? <2644e>?? DW_AT_type??????? : <0x1a430>???? 
??? <26452>?? DW_AT_location??? : 2 byte block: 91 64?? (DW_OP_fbreg: -28)

?<2><26455>: Abbrev Number: 43 (DW_TAG_variable)
??? <26456>?? DW_AT_name??????? : (indirect string, offset: 0x461): __FUNCTION__??????? 
??? <2645a>?? DW_AT_type??????? : <0x264d5>???? 
??? <2645e>?? DW_AT_artificial? : 1???? 
??? <2645f>?? DW_AT_location??? : 5 byte block: 3 ec 51 e 0???? (DW_OP_addr: e51ec)

?<2><26465>: Abbrev Number: 44 (DW_TAG_lexical_block)
??? <26466>?? DW_AT_low_pc????? : 0x25f08?????? 
??? <2646a>?? DW_AT_high_pc???? : 0x25f48?????? 
??? <2646e>?? DW_AT_sibling???? : <0x2648f>???? 

?<3><26472>: Abbrev Number: 42 (DW_TAG_variable)
??? <26473>?? DW_AT_name??????? : (indirect string, offset: 0x5a5): __dbch????? 
??? <26477>?? DW_AT_decl_file?? : 2???? 
??? <26478>?? DW_AT_decl_line?? : 85??? 
??? <26479>?? DW_AT_type??????? : <0x264da>???? 
??? <2647d>?? DW_AT_location??? : 2 byte block: 91 74?? (DW_OP_fbreg: -12)

?<3><26480>: Abbrev Number: 42 (DW_TAG_variable)
??? <26481>?? DW_AT_name??????? : (indirect string, offset: 0x861): __dbcl????? 
??? <26485>?? DW_AT_decl_file?? : 2???? 
??? <26486>?? DW_AT_decl_line?? : 85??? 
??? <26487>?? DW_AT_type??????? : <0x264df>???? 
??? <2648b>?? DW_AT_location??? : 2 byte block: 91 70?? (DW_OP_fbreg: -16)




A _stdcall function:

? <267a9>?? DW_AT_name??????? : (indirect string, offset: 0x674b): RegisterClipboardFormatW?? 
??? <267ad>?? DW_AT_decl_file?? : 2???? 
??? <267ae>?? DW_AT_decl_line?? : 216?? 
??? <267af>?? DW_AT_prototyped? : 1???? 
??? <267b0>?? DW_AT_type??????? : <0x1a45c>???? 
??? <267b4>?? DW_AT_low_pc????? : 0x2643c?????? 
??? <267b8>?? DW_AT_high_pc???? : 0x26464?????? 
??? <267bc>?? DW_AT_frame_base? : 0x10ac??????? (location list)
??? <267c0>?? DW_AT_sibling???? : <0x267d3>???? 
?
<2><267c4>: Abbrev Number: 40 (DW_TAG_formal_parameter)
??? <267c5>?? DW_AT_name??????? : (indirect string, offset: 0x117d6): name????? 
??? <267c9>?? DW_AT_decl_file?? : 2???? 
??? <267ca>?? DW_AT_decl_line?? : 216?? 
??? <267cb>?? DW_AT_type??????? : <0x1a509>???? 
??? <267cf>?? DW_AT_location??? : 2 byte block: 91 74?? (DW_OP_fbreg: -12)

How can the above information be used to discern how to change the stack pointer if these routines' stack behavior were to be emulated?

Kind regards and thanks in advance for any insight you or anyone else can provide.

Roger


----- Original Message -----
From: Michael Eager <eager@eagerm.com>
To: Roger Cruz <roger_r_cruz@yahoo.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>; Dwarf-Discuss@lists.dwarfstd.org
Sent: Wednesday, June 6, 2012 11:29 AM
Subject: Re: Fw: Extending calling convention information in DWARF output for x86

On 06/06/2012 06:40 AM, Roger Cruz wrote:

Adding dwarf-discuss@ to CC.

> 
> I am interested in parsing DWARF debug output in order to know the calling convention of each
> function.? Reading the spec for DWARF-4, I can see that there is an attribute
> DW_AT_calling_convention but its only defined values are (pg 52):
> 
> DW_CC_normal
> DW_CC_program
> DW_CC_nocall

The DW_CC_nocall attribute are used tell a debugger that the common calling conventions,
say for saving/restoring registers or passing arguments, are not being followed,
for example, by a function which is intended to be called as an interrupt handler.

Almost everything about calling functions is described in DWARF, including
where the arguments are saved and how to unwind the stack.

What are you trying to describe?

> The spec also allows compilers to generate their own extensions (pg 153) which can be used to
> enhanced that attribute's information.

Yes, DWARF can add extensions.

> My questions are:? Is there a way to coax GCC to use these extensions to spell out the calling
> convention for each function for an x86 target?? If not, has anyone added these extensions for
> other targets which I can use to add support for x86?? Can someone estimate how big of an effort
> it would be for someone who has no knowledge of GCC's internals but may be able to use another
> target as a template?

What do you mean by "calling conventions"??  What information do you want that is not available?

The general answer to the question "how much effort for someone who doesn't know GCC internals"
is "lots".

-- Michael Eager??? eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306? 650-325-8077