[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. -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Request for clarification of handling stack-passed parameters
In that case I shall create appropriate issues for the mentioned compilers in order to discuss the matter with them. I think I have found another issue with clang. In some cases it does not generate middle parameters: namely, it skipped the 2nd one yet included the 3rd one. It believe it does not match the standard (p91 line 6-7): "Call site parameter entries occur in the same order as the corresponding parameters in the source.", does it? On Jun 14, 2024, 15:11 +0300, Robinson, Paul , wrote: > 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 > 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. -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Request for clarification of handling stack-passed parameters
I have created the appropriate issues in case anyone is interested: clang not generating stack-passed parameters: https://github.com/llvm/llvm-project/issues/94986 clang skipping and intermingling parameters: https://github.com/llvm/llvm-project/issues/95645 GCC not generating stack-passed parameters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115543 On Jun 14, 2024 at 9:37 PM +0300, Robinson, Paul , wrote: > The spec does say they occur in the same order, which strongly implies that > there is a DW_TAG_call_site_parameter for each actual parameter. Although, > now that I say that, I have a memory of some discussion where a parameter > entry might be omitted entirely. I don’t remember the details, but Jakub > probably does. The spec does not clearly say that parameter entries can be > omitted, though. > --paulr > > From: Sergey > Sent: Friday, June 14, 2024 1:12 PM > To: dwarf-discuss@lists.dwarfstd.org; Robinson, Paul > Subject: RE: [Dwarf-discuss] Request for clarification of handling > stack-passed parameters > > In that case I shall create appropriate issues for the mentioned compilers in > order to discuss the matter with them. > > I think I have found another issue with clang. In some cases it does not > generate middle parameters: namely, it skipped the 2nd one yet included the > 3rd one. > It believe it does not match the standard (p91 line 6-7): "Call site > parameter entries occur in the same order as the corresponding parameters in > the source.", does it? > On Jun 14, 2024, 15:11 +0300, Robinson, Paul , wrote: > > > 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 > > 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. -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
