[0/2] Add more flexibility to inferior call

  Hi all,

The following two patches would add more flexibility to the infcalls
workflow by allowing targets to have their own implementations of:
	* value_arg_coerce: Enable the target to control arguments
	coercion whenever needed (e.g.  Coerce BOOL to UINT16_T
	instead of UINT32_T).
	* reserve_stack_space: Enable the target to decide how much
	space is needed for a type (e.g.  Targets might have a vectorized
	representation of variables).

Regards,
Mohamed

Mohamed Bouhaouel (2):
  gdb, gdbarch, infcall: Add value_arg_coerce method to gdbarch.
  gdb, gdbarch, infcall:  Add reserve_stack_space method to gdbarch

 gdb/gdbarch-gen.h         | 13 ++++++++++++
 gdb/gdbarch.c             | 44 +++++++++++++++++++++++++++++++++++++++
 gdb/gdbarch.h             |  1 +
 gdb/gdbarch_components.py | 26 +++++++++++++++++++++++
 gdb/infcall.c             | 32 +++++++++++-----------------
 gdb/infcall.h             | 17 +++++++++++++++
 6 files changed, 113 insertions(+), 20 deletions(-)
  

On 3/22/23 13:13, Mohamed Bouhaouel via Gdb-patches wrote:
> Hi all,
> 
> The following two patches would add more flexibility to the infcalls
> workflow by allowing targets to have their own implementations of:
> 	* value_arg_coerce: Enable the target to control arguments
> 	coercion whenever needed (e.g.  Coerce BOOL to UINT16_T
> 	instead of UINT32_T).
> 	* reserve_stack_space: Enable the target to decide how much
> 	space is needed for a type (e.g.  Targets might have a vectorized
> 	representation of variables).

Hi Mohamed,

Is there an end goal to this?  It doesn't really make sense to add
gdbarch methods but have no architecture use it.  If it's necessary for
some upcoming feature, then include these patches as preparatory patches
in the series that adds said feature.

Simon
  

Hi Simon,

Thanks for your feedback.  These patches are pre-requisite for an Intel architecture
that has not been yet up-streamed.  Waiting for the architecture to be introduced
first is likely more logical,  although, such flexibility might be useful for
other new architectures.

Should I submit a new version of those patches while considering your comments
or wait to post all together?

Thanks,
Mohamed

> -----Original Message-----
> From: Simon Marchi <simark@simark.ca>
> Sent: Wednesday, March 22, 2023 8:17 PM
> To: Bouhaouel, Mohamed <mohamed.bouhaouel@intel.com>; gdb-
> patches@sourceware.org
> Subject: Re: [PATCH 0/2] Add more flexibility to inferior call
> 
> On 3/22/23 13:13, Mohamed Bouhaouel via Gdb-patches wrote:
> > Hi all,
> >
> > The following two patches would add more flexibility to the infcalls
> > workflow by allowing targets to have their own implementations of:
> > 	* value_arg_coerce: Enable the target to control arguments
> > 	coercion whenever needed (e.g.  Coerce BOOL to UINT16_T
> > 	instead of UINT32_T).
> > 	* reserve_stack_space: Enable the target to decide how much
> > 	space is needed for a type (e.g.  Targets might have a vectorized
> > 	representation of variables).
> 
> Hi Mohamed,
> 
> Is there an end goal to this?  It doesn't really make sense to add
> gdbarch methods but have no architecture use it.  If it's necessary for
> some upcoming feature, then include these patches as preparatory patches
> in the series that adds said feature.
> 
> Simon


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
  

On 3/23/23 07:34, Bouhaouel, Mohamed wrote:
> Hi Simon,
> 
> Thanks for your feedback.  These patches are pre-requisite for an Intel architecture
> that has not been yet up-streamed.  Waiting for the architecture to be introduced
> first is likely more logical,  although, such flexibility might be useful for
> other new architectures.
> 
> Should I submit a new version of those patches while considering your comments
> or wait to post all together?

I think it's better to post it with the first architecture that uses it.
It helps illustrate what the method is for and how it works.  But also,
if your port never ends up upstream for whatever reason, it doesn't make
sense to have those methods with no users.

Simon
  

That makes sense, I will re-submit them once the new architecture is posted.

Thanks.
Mohamed


> -----Original Message-----
> From: Simon Marchi <simark@simark.ca>
> Sent: Friday, March 24, 2023 2:38 PM
> To: Bouhaouel, Mohamed <mohamed.bouhaouel@intel.com>; gdb-
> patches@sourceware.org
> Subject: Re: [PATCH 0/2] Add more flexibility to inferior call
> 
> On 3/23/23 07:34, Bouhaouel, Mohamed wrote:
> > Hi Simon,
> >
> > Thanks for your feedback.  These patches are pre-requisite for an Intel
> architecture
> > that has not been yet up-streamed.  Waiting for the architecture to be
> introduced
> > first is likely more logical,  although, such flexibility might be useful for
> > other new architectures.
> >
> > Should I submit a new version of those patches while considering your
> comments
> > or wait to post all together?
> 
> I think it's better to post it with the first architecture that uses it.
> It helps illustrate what the method is for and how it works.  But also,
> if your port never ends up upstream for whatever reason, it doesn't make
> sense to have those methods with no users.
> 
> Simon
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
  

Simon> I think it's better to post it with the first architecture that uses it.

Agreed.

Simon> It helps illustrate what the method is for and how it works.  But also,
Simon> if your port never ends up upstream for whatever reason, it doesn't make
Simon> sense to have those methods with no users.

Additionally, depending on exactly what it is needed for, there might be
some other solution, not involving new arch hooks, that we'd prefer.

Tom