| 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 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> 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
~~~ 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. |