What role stakeholders play in the control of a project in execution stage of the project cycle.
This question is far too broad to answer in any meaningful way. Industry, location, and type of project would yield different answers. So, too, would the breakdown and segmentation of the stakeholders. Based on how their segmented, each group would play a different role.
So the only feasible answer one could give now is, yes, they play several of many roles during the execution stage of a project.
EDIT: In general, stakeholders can participate in the design of the widget being built. They certainly participate in setting requirements or discussing changes or compromises to the requirements. Some groups would provide subject matter expertise that would be needed by the builders of the widget. All groups would require staying informed so they would play a communication receiving role. If user acceptance testing is required, then a segmented group would play in that QC activity. On some project, a stakeholder group would be at what I call level zero, meaning they are side by side with the project team on a daily basis, even part of the project team. I would consider them a stakeholder even though they are part of the team because I am typically in a seller/buyer project relationship where I am the seller.
Some stakeholder segments would be deployed as champions of change, meaning they would advocate to other segments about the change in order to reduce the likelihood of change resistance, a huge killer of project acceptance. Other stakeholder segments may have projects going on where your project and their project have one or many touch points, so coordination between the groups to resolve dependencies would need to occur.
...just some general ideas.
Stake holders play following key roles and many other 1.Stating requirements clearly 2.Clarification of requirements in all the phases of project 3.Validating POC or prototypes if there are any 4.Change controls if there are any and budget approvals 5.User Acceptance testing 6.Sign off for the developed piece of software 7.Production issues if there are any after product went live and follow up to rsolve 8.Feedback how it worked after the product is stable or mean time too