From eager@eagerm.com  Wed Jun  6 15:29:46 2012
From: eager@eagerm.com (Michael Eager)
Date: Wed, 06 Jun 2012 08:29:46 -0700
Subject: [Dwarf-Discuss] Fw: Extending calling convention information in
 DWARF output for x86
In-Reply-To: <1338990023.9681.YahooMailNeo@web110315.mail.gq1.yahoo.com>
References: <1338989518.85676.YahooMailNeo@web110301.mail.gq1.yahoo.com>
	<1338990023.9681.YahooMailNeo@web110315.mail.gq1.yahoo.com>
Message-ID: <4FCF776A.3080004@eagerm.com>

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 at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



From roger_r_cruz@yahoo.com  Wed Jun  6 16:28:26 2012
From: roger_r_cruz@yahoo.com (Roger Cruz)
Date: Wed, 6 Jun 2012 09:28:26 -0700 (PDT)
Subject: [Dwarf-Discuss] Fw: Extending calling convention information in
	DWARF output for x86
In-Reply-To: <4FCF776A.3080004@eagerm.com>
References: <1338989518.85676.YahooMailNeo@web110301.mail.gq1.yahoo.com>
	<1338990023.9681.YahooMailNeo@web110315.mail.gq1.yahoo.com>
	<4FCF776A.3080004@eagerm.com>
Message-ID: <1339000106.37581.YahooMailNeo@web110304.mail.gq1.yahoo.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 at yahoo.com>
Cc: "gcc at gcc.gnu.org" <gcc at gcc.gnu.org>; Dwarf-Discuss at 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 at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306? 650-325-8077




From eager@eagerm.com  Wed Jun  6 17:27:07 2012
From: eager@eagerm.com (Michael Eager)
Date: Wed, 06 Jun 2012 10:27:07 -0700
Subject: [Dwarf-Discuss] Fw: Extending calling convention information in
 DWARF output for x86
In-Reply-To: <1339000106.37581.YahooMailNeo@web110304.mail.gq1.yahoo.com>
References: <1338989518.85676.YahooMailNeo@web110301.mail.gq1.yahoo.com>
	<1338990023.9681.YahooMailNeo@web110315.mail.gq1.yahoo.com>
	<4FCF776A.3080004@eagerm.com>
	<1339000106.37581.YahooMailNeo@web110304.mail.gq1.yahoo.com>
Message-ID: <4FCF92EB.9050005@eagerm.com>

On 06/06/2012 09:28 AM, Roger Cruz wrote:
> 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.

Usually, syntactic tags like "_stdcall" or "_cdecl" are represented by
an attribute in the appropriate (in this case, DW_TAG_subprogram) DIE.
This can be used by the debugger to print out the tag as well as do
whatever different semantic processing may be needed.

You might add attributes for "_stdcall" or "_cdecl" as user extensions.

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

The DWARF Call Frame Information (CFI) specified in Section 6.4 describes
how to unwind the stack from any arbitrary location in a function to
find the previous stack frame.  The CFI can be used to determine the value
of the stack pointer at the entry to the function.

The CFI is designed to track the (real or virtual) frame pointer, not
the stack pointer, so it will not tell you how the calling function modifies
the stack before or after the call.

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



From roger_r_cruz@yahoo.com  Wed Jun  6 22:39:55 2012
From: roger_r_cruz@yahoo.com (Roger Cruz)
Date: Wed, 6 Jun 2012 15:39:55 -0700 (PDT)
Subject: [Dwarf-Discuss] Fw: Extending calling convention information in
	DWARF output for x86
In-Reply-To: <4FCF92EB.9050005@eagerm.com>
References: <1338989518.85676.YahooMailNeo@web110301.mail.gq1.yahoo.com>
	<1338990023.9681.YahooMailNeo@web110315.mail.gq1.yahoo.com>
	<4FCF776A.3080004@eagerm.com>
	<1339000106.37581.YahooMailNeo@web110304.mail.gq1.yahoo.com>
	<4FCF92EB.9050005@eagerm.com>
Message-ID: <1339022395.21786.YahooMailNeo@web110308.mail.gq1.yahoo.com>

Thanks Michael.? So it sounds like DWARF won't help me in determining how a called function should (or should not) clean up the stack and also if I want to determine the calling convention, I would have to modify GCC itself to produce those user extensions.

Roger



________________________________
 From: Michael Eager <eager at eagerm.com>
To: Roger Cruz <roger_r_cruz at yahoo.com> 
Cc: "gcc at gcc.gnu.org" <gcc at gcc.gnu.org>; "Dwarf-Discuss at lists.dwarfstd.org" <Dwarf-Discuss at lists.dwarfstd.org> 
Sent: Wednesday, June 6, 2012 1:27 PM
Subject: Re: Fw: Extending calling convention information in DWARF output for x86
 
On 06/06/2012 09:28 AM, Roger Cruz wrote:
> 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.

Usually, syntactic tags like "_stdcall" or "_cdecl" are represented by
an attribute in the appropriate (in this case, DW_TAG_subprogram) DIE.
This can be used by the debugger to print out the tag as well as do
whatever different semantic processing may be needed.

You might add attributes for "_stdcall" or "_cdecl" as user extensions.

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

The DWARF Call Frame Information (CFI) specified in Section 6.4 describes
how to unwind the stack from any arbitrary location in a function to
find the previous stack frame.? The CFI can be used to determine the value
of the stack pointer at the entry to the function.

The CFI is designed to track the (real or virtual) frame pointer, not
the stack pointer, so it will not tell you how the calling function modifies
the stack before or after the call.

-- Michael Eager??? eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306? 650-325-8077
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20120606/6d560007/attachment.htm>


