This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077