This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] -stack-select-frame


Hi Nick,

You wrote:

I'm not aware of anyone using this command - I don't see how they currently
could really. I think its less likely to break existing behaviour than this
change:

Xcode uses stack-select-frame -- I'm not sure how a real GUI could avoid using stack-select-frame.



On Jun 15, 2005, at 8:37 PM, Nick Roberts wrote:


Here, hopefully, is a much more sensible one. The idea is the same: that
-stack-select-frame tells the frontend what the current or selected frame
is.

I don't care, really, but isn't necessary in our experience at Apple. The first thing a GUI has to do when execution has stopped is get the current stack. It shows the stack to the developer, and then the developer decides that stack frame 2 is of interest to her, so she clicks there and the GUI sends stack-select-frame. The GUI already has the stack-list-frames output from when it stopped -- it knows very well what's at frame 2.


If the GUI has short term memory problems, stack-list-frames is always at its disposal.

    * mi/mi-cmd-stack.c (mi_cmd_stack_select_frame): Don't test for
    stack.  Print frame details.

  enum mi_cmd_result
  mi_cmd_stack_select_frame (char *command, char **argv, int argc)
  {
-   if (!target_has_stack)
-     error (_("mi_cmd_stack_select_frame: No stack."));
-

Why are you suggesting this change? If the GUI is requesting a stack when the inferior isn't running, that's an error.


Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]