Skip to content
  1. Oct 08, 2010
  2. Oct 05, 2010
  3. Oct 01, 2010
    • Caroline Tice's avatar
      · deaab222
      Caroline Tice authored
      Modify command options to use the new arguments mechanism.  Now all command option
      arguments are specified in a standardized way, will have a standardized name, and
      have functioning help.
      
      The next step is to start writing useful help for all the argument types.
      
      llvm-svn: 115335
      deaab222
    • Caroline Tice's avatar
      · e139cf23
      Caroline Tice authored
      Add infrastructure for standardizing arguments for commands and
      command options; makes it easier to ensure that the same type of
      argument will have the same name everywhere, hooks up help for command
      arguments, so that users can ask for help when they are confused about
      what an argument should be; puts in the beginnings of the ability to
      do tab-completion for certain types of arguments, allows automatic
      syntax help generation for commands with arguments, and adds command
      arguments into command options help correctly.
      
      Currently only the breakpoint-id and breakpoint-id-range arguments, in
      the breakpoint commands, have been hooked up to use the new mechanism.
      The next steps will be to fix the command options arguments to use
      this mechanism, and to fix the rest of the regular command arguments
      to use this mechanism.  Most of the help text is currently missing or
      dummy text; this will need to be filled in, and the existing argument
      help text will need to be cleaned up a bit (it was thrown in quickly,
      mostly for testing purposes).
      
      Help command now works for all argument types, although the help may not
      be very helpful yet.
      
      Those commands that take "raw" command strings now indicate it in their
      help text.
      
      llvm-svn: 115318
      e139cf23
  4. Sep 18, 2010
    • Greg Clayton's avatar
      Fixed the way set/show variables were being accessed to being natively · a7015092
      Greg Clayton authored
      accessed by the objects that own the settings. The previous approach wasn't
      very usable and made for a lot of unnecessary code just to access variables
      that were already owned by the objects.
      
      While I fixed those things, I saw that CommandObject objects should really
      have a reference to their command interpreter so they can access the terminal
      with if they want to output usaage. Fixed up all CommandObjects to take
      an interpreter and cleaned up the API to not need the interpreter to be
      passed in.
      
      Fixed the disassemble command to output the usage if no options are passed
      down and arguments are passed (all disassebmle variants take options, there
      are no "args only").
      
      llvm-svn: 114252
      a7015092
  5. Sep 09, 2010
  6. Jul 07, 2010
  7. Jun 30, 2010
  8. Jun 24, 2010
  9. Jun 23, 2010
    • Greg Clayton's avatar
      Very large changes that were needed in order to allow multiple connections · 6611103c
      Greg Clayton authored
      to the debugger from GUI windows. Previously there was one global debugger
      instance that could be accessed that had its own command interpreter and
      current state (current target/process/thread/frame). When a GUI debugger
      was attached, if it opened more than one window that each had a console
      window, there were issues where the last one to setup the global debugger
      object won and got control of the debugger.
      
      To avoid this we now create instances of the lldb_private::Debugger that each 
      has its own state:
      - target list for targets the debugger instance owns
      - current process/thread/frame
      - its own command interpreter
      - its own input, output and error file handles to avoid conflicts
      - its own input reader stack
      
      So now clients should call:
      
          SBDebugger::Initialize(); // (static function)
      
          SBDebugger debugger (SBDebugger::Create());
          // Use which ever file handles you wish
          debugger.SetErrorFileHandle (stderr, false);
          debugger.SetOutputFileHandle (stdout, false);
          debugger.SetInputFileHandle (stdin, true);
      
          // main loop
          
          SBDebugger::Terminate(); // (static function)
          
      SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
      ensure nothing gets destroyed too early when multiple clients might be
      attached.
      
      Cleaned up the command interpreter and the CommandObject and all subclasses
      to take more appropriate arguments.
      
      llvm-svn: 106615
      6611103c
  10. Jun 15, 2010
  11. Jun 08, 2010
Loading