[Dwarf-discuss] Request for clarification of handling stack-passed parameters

Robinson, Paul paul.robinson@sony.com
Fri Jun 14 12:11:34 GMT 2024


I believe this is an issue with the implementations, although it is a bit odd that both gcc and clang behave the same way. There should be a DW_TAG_call_site_parameter for each parameter. DW_AT_location should describe the stack slot where the parameter is passed. It should not be a problem for the compiler to do that, the location description would be evaluated in the context of the caller.
--paulr

From: Dwarf-discuss <dwarf-discuss-bounces+paul.robinson=sony.com@lists.dwarfstd.org> On Behalf Of Sergey via Dwarf-discuss
Sent: Wednesday, June 12, 2024 9:57 AM
To: dwarf-discuss@lists.dwarfstd.org
Subject: [Dwarf-discuss] Request for clarification of handling stack-passed parameters

# Request for clarification of handling stack-passed parameters

## Background

I came across this while parsing parameters of a variadic function in C. Formal parameters are not sufficient for my case, since all the variadic arguments are described with a single `DW_TAG_unspecified_parameters`, whereas reading `DW_TAG_call_site_parameter` allows to get their locations and values.

## Overview

When generating a DWARF5 of a C function with **more than 6** parameters, the generated `DW_TAG_call_site` contains only **first 6** `DW_TAG_call_site_parameter`s (function's `DW_TAG_formal_parameter`s contain all of them).

Something I have noticed is that the parameters, which do not get `DW_TAG_call_site_parameter` generated, are all **passed through stack**(whereas first 6 through registers), as evident by function's `DW_TAG_formal_parameter`'s `DW_AT_location` containing `DW_OP_fbreg`.

## Request for clarification

It happens both with gcc and clang, however I was unable to find any information in the standard regarding generation of only registed-passed parameters.

I request clarification on whether it is an issue with implementations, or is there something in the standard which justifies the described behaviour.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240614/e54b80b6/attachment.htm>


More information about the Dwarf-discuss mailing list