Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Function Call view

> I'm having trouble imagining the specifics of the UI this early, so I'm curious of the benefits of having a new view?

After a conversation with a colleague we decided the view will act as a function parser with the added feature of calling the function if the current context supports it.  I thought about adding functionality to the _expression_ view, but in the end decided this would add too much clutter.  The initial design calls for a top panel with spaces to designate a buffer on the remote to write to (start address and size), with a label showing remaining available space, and a field to add the function name, a parse and a call/ print button. 

> Will the arguments be shown as children to the function name element shown in the view?

Under the top panel would be a tree viewer with two top-level nodes, args and return value, which will expand if appropriate.  This would closely resemble the tree viewer in the Expressions view, but the address column would be editable for pointers. 

 

This feature would be made much easier to accomplish with a few enhancements to gdb, making function arguments children of the Variable Object created for the function _expression_ (using -var-create), and allowing Variable Objects to be created on function arguments and local variable outside of a suspended context.  I sent an email to the gdb mailing list to get feedback/ suggestions for this.  But this could still be accomplished using info scope, ptype, and whatis (Dell Emc submitted enhancements to these to allow an at <location> flag, which will hopefully be picked up soon).

> When you need to create a new structure, will you need to free this memory at the end?

Yes.  But this would apply to local debugging only, where a convenience variable would be created using malloc.  But for remote debugging the ‘M’ packet would be used to write memory on the remote.  It would be up to the user to designate a space on the remote that may be safely written to.

> As an enhancement, you could (possibly) provide content-assist when the user types the function name. Gdb has a 'complete' (or something similar) command you can use.

Yes.  But of course this will return all symbols.

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Wednesday, September 21, 2016 11:05 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Function Call view

 

Sounds interesting!

I'm having trouble imagining the specifics of the UI this early, so I'm curious of the benefits of having a new view?

Will the arguments be shown as children to the function name element shown in the view?

When you need to create a new structure, will you need to free this memory at the end?

As an enhancement, you could (possibly) provide content-assist when the user types the function name. Gdb has a 'complete' (or something similar) command you can use.

Sounds exciting.


From: Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Sent: Sep 20, 2016 5:45 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Function Call view

 

Hi Stephen,

 

Your work on this sounds very interesting and will add value to CDT.

 

Presently, neither my colleague nor I have authorization to contribute to CDT, but we hope to remedy that soon.  

 

I assume this means that you need to get your contributor agreements sorted out?

 

> Our intention would be to make this available to the community if there is interest.

 

I think there is of interest and would be willing to be a reviewer when you are ready.

 

I don't have any other suggestions or criticisms at this point. The plan you outlined here seems good to me.

 

Jonah


~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

 

On 19 September 2016 at 17:47, Flynn, Stephen <Stephen.Flynn@xxxxxxxx> wrote:

  My colleague and I are currently implementing a view that should simplify the process of calling a function in Gdb.  The intent is to allow a user to enter a function name, resolve the function's arguments and provide a way for the user to set values (for basic inputs) and addresses (for all pointers and structures), as well as handle situations where a given argument does not exist, i.e. an argument is a pointer to a struct, but no such structure exists.

  The view would resolve the structure members and present them in the same manner the Expressions View does, which would allow the user to set values for the various members.  Prior to the function being called the structure would be created and the structure pointer passed to the function.

  The return value (if any) would be made available in the same view.

  Presently, neither my colleague nor I have authorization to contribute to CDT, but we hope to remedy that soon.  Our intention would be to make this available to the community if there is interest.

  In order to make this work properly, changes would need to first be made to gdb: Allow local and function argument variables to be resolved outside of a suspended context through the MI var-create command (My colleague David Taylor has already submitted changes that does this for CLI); when creating a Variable Object on a function, make the arguments to the function its children.  I have emailed the gdb mailing list for feedback on these proposals.

  Changes to the IExpressions service would come next to take advantage of those changes.

  I am looking for any and all suggestions and/ or criticisms.

Thanks,

Stephen Flynn
Software Engineer 2
508-249-9848 / (821) 49848


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


Back to the top