Skip to content
  1. Oct 19, 2012
    • Greg Clayton's avatar
      Added the infrastructure necessary for plug-ins to be able to add their own... · e8cd0c98
      Greg Clayton authored
      Added the infrastructure necessary for plug-ins to be able to add their own settings instead of having settings added to existing ones. In particular "target.disable-kext-loading" was added to "target" where it should actually be specific to the the dynamic loader plugin. Now the plug-in manager has the ability to create settings at the root level starting with "plugin". Each plug-in type can add new sub dictionaries, and then each plug-in can register a setting dictionary under its own short name. For example the DynamicLoaderDarwinKernel plug-in now registers a setting dictionary at:
      
      plugin
          dynamic-loader
              macosx-kernel
                  (bool) disable-kext-loading
                  
      To settings can be set using:
      
      (lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true
      
      I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins.
      
      llvm-svn: 166294
      e8cd0c98
  2. Aug 22, 2012
  3. Jul 17, 2012
  4. Jan 30, 2012
    • Greg Clayton's avatar
      SBFrame is now threadsafe using some extra tricks. One issue is that stack · b9556acc
      Greg Clayton authored
      frames might go away (the object itself, not the actual logical frame) when
      we are single stepping due to the way we currently sometimes end up flushing
      frames when stepping in/out/over. They later will come back to life 
      represented by another object yet they have the same StackID. Now when you get
      a lldb::SBFrame object, it will track the frame it is initialized with until 
      the thread goes away or the StackID no longer exists in the stack for the 
      thread it was created on. It uses a weak_ptr to both the frame and thread and
      also stores the StackID. These three items allow us to determine when the
      stack frame object has gone away (the weak_ptr will be NULL) and allows us to
      find the correct frame again. In our test suite we had such cases where we
      were just getting lucky when something like this happened:
      
      1 - stop at breakpoint
      2 - get first frame in thread where we stopped
      3 - run an expression that causes the program to JIT and run code
      4 - run more expressions on the frame from step 2 which was very very luckily
          still around inside a shared pointer, yet, not part of the current 
          thread (a new stack frame object had appeared with the same stack ID and
          depth). 
          
      We now avoid all such issues and properly keep up to date, or we start 
      returning errors when the frame doesn't exist and always responds with
      invalid answers.
      
      Also fixed the UserSettingsController  (not going to rewrite this just yet)
      so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to
      track when the master controller has already gone away and this allowed me to
      pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer 
      needed.
      
      llvm-svn: 149231
      b9556acc
  5. Jan 27, 2012
  6. Jan 21, 2012
    • Johnny Chen's avatar
      o CommandObjectSettingsSet.cpp: · 98aceb08
      Johnny Chen authored
        Fix a bug where "settings set -r th" wouldn't complete.
      
      o UserSettingsController.cpp:
      
        Fix a bug where "settings set target.process." wouldn't complete.
      
      o test/functionalities/completion:
      
        Add various completion test cases related to 'settings set' command.
      
      llvm-svn: 148596
      98aceb08
  7. Dec 19, 2011
  8. Oct 26, 2011
    • Greg Clayton's avatar
      Cleaned up many error codes. For any who is filling in error strings into · 86edbf41
      Greg Clayton authored
      lldb_private::Error objects the rules are:
      - short strings that don't start with a capitol letter unless the name is a
        class or anything else that is always capitolized
      - no trailing newline character
      - should be one line if possible
      
      Implemented a first pass at adding "--gdb-format" support to anything that
      accepts format with optional size/count.
      
      llvm-svn: 142999
      86edbf41
  9. Oct 07, 2011
    • Greg Clayton's avatar
      Re-organized the contents of RangeMap.h to be more concise and also allow for... · cf0e4f0d
      Greg Clayton authored
      Re-organized the contents of RangeMap.h to be more concise and also allow for a Range, RangeArray, RangeData (range + data), or a RangeDataArray. We have many range implementations in LLDB and I will be converting over to using the classes in RangeMap.h so we can have one set of code that does ranges and searching  of ranges.
      
      Fixed up DWARFDebugAranges to use the new range classes.
      
      Fixed the enumeration parsing to take a lldb_private::Error to avoid a lot of duplicated code. Now when an invalid enumeration is supplied, an error will be returned and that error will contain a list of the valid enumeration values.
      
      llvm-svn: 141382
      cf0e4f0d
  10. Sep 20, 2011
  11. May 29, 2011
  12. Apr 23, 2011
    • Greg Clayton's avatar
      Fixed the SymbolContext::DumpStopContext() to correctly indent and dump · 7e14f91d
      Greg Clayton authored
      inline contexts when the deepest most block is not inlined.
      
      Added source path remappings to the lldb_private::Target class that allow it
      to remap paths found in debug info so we can find source files that are elsewhere
      on the current system.
      
      Fixed disassembly by function name to disassemble inline functions that are
      inside other functions much better and to show enough context before the
      disassembly output so you can tell where things came from.
      
      Added the ability to get more than one address range from a SymbolContext 
      class for the case where a block or function has discontiguous address ranges.
      
      llvm-svn: 130044
      7e14f91d
  13. Apr 22, 2011
    • Greg Clayton's avatar
      Did some work on the "register read" command to only show the first register · 385aa28c
      Greg Clayton authored
      set by default when dumping registers. If you want to see all of the register
      sets you can use the "--all" option:
      
      (lldb) register read --all
      
      If you want to just see some register sets, you can currently specify them
      by index:
      
      (lldb) register read --set 0 --set 2
      
      We need to get shorter register set names soon so we can specify the register
      sets by name without having to type too much. I will make this change soon.
      
      You can also have any integer encoded registers resolve the address values
      back to any code or data from the object files using the "--lookup" option.
      Below is sample output when stopped in the libc function "puts" with some
      const strings in registers:
      
      Process 8973 stopped
      * thread #1: tid = 0x2c03, 0x00007fff828fa30f libSystem.B.dylib`puts + 1, stop reason = instruction step into
        frame #0: 0x00007fff828fa30f libSystem.B.dylib`puts + 1
      (lldb) register read --lookup 
      General Purpose Registers:
        rax          = 0x0000000100000e98  "----------------------------------------------------------------------"
        rbx          = 0x0000000000000000
        rcx          = 0x0000000000000001  
        rdx          = 0x0000000000000000
        rdi          = 0x0000000100000e98  "----------------------------------------------------------------------"
        rsi          = 0x0000000100800000
        rbp          = 0x00007fff5fbff710
        rsp          = 0x00007fff5fbff280
        r8           = 0x0000000000000040  
        r9           = 0x0000000000000000
        r10          = 0x0000000000000000
        r11          = 0x0000000000000246  
        r12          = 0x0000000000000000
        r13          = 0x0000000000000000
        r14          = 0x0000000000000000
        r15          = 0x0000000000000000
        rip          = 0x00007fff828fa30f  libSystem.B.dylib`puts + 1
        rflags       = 0x0000000000000246  
        cs           = 0x0000000000000027  
        fs           = 0x0000000000000000
        gs           = 0x0000000000000000
      
      As we can see, we see two constant strings and the PC (register "rip") is 
      showing the code it resolves to.
      
      I fixed the register "--format" option to work as expected.
      
      Added a setting to disable skipping the function prologue when setting 
      breakpoints as a target settings variable:
      
      (lldb) settings set target.skip-prologue false
      
      Updated the user settings controller boolean value handler funciton to be able
      to take the default value so it can correctly respond to the eVarSetOperationClear
      operation.
      
      Did some usability work on the OptionValue classes.
      
      Fixed the "image lookup" command to correctly respond to the "--verbose" 
      option and display the detailed symbol context information when looking up
      line table entries and functions by name. This previously was only working
      for address lookups.
      
      llvm-svn: 129977
      385aa28c
  14. Apr 20, 2011
    • Greg Clayton's avatar
      General cleanup on the UserSettingsController stuff. There were 5 different · 4c20717a
      Greg Clayton authored
      places that were dumping values for the settings. Centralized all of the
      value dumping into a single place. When dumping values that aren't strings
      we no longer surround the value with single quotes. When dumping values that
      are strings, surround the string value with double quotes. When dumping array
      values, assume they are always string values, and don't put quotes around
      dictionary values.
      
      llvm-svn: 129826
      4c20717a
  15. Feb 19, 2011
    • Jim Ingham's avatar
      - Changed all the places where CommandObjectReturn was exporting a StreamString to just exporting · 85e8b814
      Jim Ingham authored
      a Stream, and then added GetOutputData & GetErrorData to get the accumulated data.
      - Added a StreamTee that will tee output to two provided lldb::StreamSP's.
      - Made the CommandObjectReturn use this so you can Tee the results immediately to
      the debuggers output file, as well as saving up the results to return when the command
      is done executing.
      - HandleCommands now uses this so that if you have a set of commands that continue the target
      you will see the commands come out as they are processed.
      - The Driver now uses this to output the command results as you go, which makes the interface
      more reactive seeming.
      
      llvm-svn: 126015
      85e8b814
  16. Feb 18, 2011
    • Greg Clayton's avatar
      Added new target instance settings for execution settings: · bfe5f3bf
      Greg Clayton authored
      Targets can now specify some additional parameters for when we debug 
      executables that can help with plug-in selection:
      
      target.execution-level = auto | user | kernel
      target.execution-mode  = auto | dynamic | static
      target.execution-os-type = auto | none | halted | live
      
      On some systems, the binaries that are created are the same wether you use
      them to debug a kernel, or a user space program. Many times inspecting an 
      object file can reveal what an executable should be. For these cases we can
      now be a little more complete by specifying wether to detect all of these
      things automatically (inspect the main executable file and select a plug-in
      accordingly), or manually to force the selection of certain plug-ins.
      
      To do this we now allow the specficifation of wether one is debugging a user
      space program (target.execution-level = user) or a kernel program 
      (target.execution-level = kernel).
      
      We can also specify if we want to debug a program where shared libraries
      are dynamically loaded using a DynamicLoader plug-in 
      (target.execution-mode = dynamic), or wether we will treat all symbol files
      as already linked at the correct address (target.execution-mode = static).
      
      We can also specify if the inferior we are debugging is being debugged on 
      a bare board (target.execution-os-type = none), or debugging an OS where
      we have a JTAG or other direct connection to the inferior stops the entire
      OS (target.execution-os-type = halted), or if we are debugging a program on
      something that has live debug services (target.execution-os-type = live).
      
      For the "target.execution-os-type = halted" mode, we will need to create 
      ProcessHelper plug-ins that allow us to extract the process/thread and other
      OS information by reading/writing memory.
      
      This should allow LLDB to be used for a wide variety of debugging tasks and
      handle them all correctly.
      
      llvm-svn: 125815
      bfe5f3bf
  17. Feb 04, 2011
  18. Jan 23, 2011
    • Greg Clayton's avatar
      Added a new variant of SBTarget::Launch() that deprectates the old one that · bd82a5d2
      Greg Clayton authored
      takes separate file handles for stdin, stdout, and stder and also allows for
      the working directory to be specified.
      
      Added support to "process launch" to a new option: --working-dir=PATH. We
      can now set the working directory. If this is not set, it defaults to that
      of the process that has LLDB loaded. Added the working directory to the
      host LaunchInNewTerminal function to allows the current working directory 
      to be set in processes that are spawned in their own terminal. Also hooked this
      up to the lldb_private::Process and all mac plug-ins. The linux plug-in had its
      API changed, but nothing is making use of it yet. Modfied "debugserver" and
      "darwin-debug" to also handle the current working directory options and modified
      the code in LLDB that spawns these tools to pass the info along.
      
      Fixed ProcessGDBRemote to properly pass along all file handles for stdin, stdout
      and stderr. 
      
      After clearing the default values for the stdin/out/err file handles for
      process to be NULL, we had a crasher in UserSettingsController::UpdateStringVariable
      which is now fixed. Also fixed the setting of boolean values to be able to
      be set as "true", "yes", "on", "1" for true (case insensitive) and "false", "no",
      "off", or "0" for false.
      
      Fixed debugserver to properly handle files for STDIN, STDOUT and STDERR that are not
      already opened. Previous to this fix debugserver would only correctly open and dupe
      file handles for the slave side of a pseudo terminal. It now correctly handles
      getting STDIN for the inferior from a file, and spitting STDOUT and STDERR out to
      files. Also made sure the file handles were correctly opened with the NOCTTY flag
      for terminals.
      
      llvm-svn: 124060
      bd82a5d2
  19. Dec 19, 2010
    • Greg Clayton's avatar
      Improved our argument parsing abilities to be able to handle stuff more like · 6ad07dd9
      Greg Clayton authored
      a shell would interpret it. A few examples that we now handle correctly
      
      INPUT: "Hello "world
      OUTPUT: "Hello World"
      
      INPUT: "Hello "' World'
      OUTPUT: "Hello World"
      
      INPUT: Hello" World"
      OUTPUT: "Hello World"
      
      This broke the setting of dictionary values for the "settings set" command
      for things like:
      
      (lldb) settings set target.process.env-vars ["MY_ENV_VAR"]=YES
      
      since we would drop the quotes. I fixed the user settings controller to use
      a regular expression so it can accept any of the following inputs for
      dictionary setting:
      
      settings set target.process.env-vars ["MY_ENV_VAR"]=YES
      settings set target.process.env-vars [MY_ENV_VAR]=YES
      settings set target.process.env-vars MY_ENV_VAR=YES
      
      We might want to eventually drop the first two syntaxes, but I won't make
      that decision right now.
      
      This allows more natural setting of the envirorment variables:
      
      settings set target.process.env-vars MY_ENV_VAR=YES ABC=DEF CWD=/tmp
      
      llvm-svn: 122166
      6ad07dd9
  20. Dec 10, 2010
    • Caroline Tice's avatar
      · 2d5289d6
      Caroline Tice authored
      Various fixes mostly relating to the User Settings stuff:
      
      - Added new utility function to Arg, GetQuotedCommandString, which re-assembles
      the args into a string, replacing quotes that were originally there.
      
      - Modified user settings stuff to always show individual elements when printing out
      arrays and dictionaries.
      
      - Added more extensive help to 'settings set', explaining more about dictionaries
      and arrays (including current dictionary syntax).
      
      - Fixed bug in user settings  where quotes were being stripped and lost, so that
      sometimes array or dictionary elements that ought to have been a single element
      were being split up.
      
      llvm-svn: 121438
      2d5289d6
  21. Nov 19, 2010
  22. Nov 11, 2010
  23. Oct 20, 2010
    • Johnny Chen's avatar
      For UserSettingsController::UpdateDictionaryVariable(), clear the dictionary · 73b4f711
      Johnny Chen authored
      if passed in a NULL new_value and the operation intended is eVarSetOperationAssign.
      This fixed a bug where in TestSettings.py:
      
              # Set the run-args and the env-vars.
              self.runCmd('settings set target.process.run-args A B C')
              self.runCmd('settings set target.process.env-vars ["MY_ENV_VAR"]=YES')
              # And add hooks to restore the settings during tearDown().
              self.addTearDownHook(
                  lambda: self.runCmd("settings set -r target.process.run-args"))
              self.addTearDownHook(
                  lambda: self.runCmd("settings set -r target.process.env-vars"))
      
      "settings set -r target.process.env-vars" was not restoring the original env-vars
      setting.
      
      llvm-svn: 116895
      73b4f711
  24. Sep 27, 2010
    • Caroline Tice's avatar
      · 1559a46b
      Caroline Tice authored
      Create more useful instance names for target, process and thread instances.
      
      Change default 'set' behavior so that all instance settings for the specified variable will be
      updated, unless the "-n" ("--no_override") command options is specified.
      
      llvm-svn: 114808
      1559a46b
  25. Sep 20, 2010
  26. Sep 19, 2010
    • Greg Clayton's avatar
      Added code that will allow completely customizable prompts for use in · 1b654882
      Greg Clayton authored
      replacing the "(lldb)" prompt, the "frame #1..." displays when doing
      stack backtracing and the "thread #1....". This will allow you to see 
      exactly the information that you want to see where you want to see it.
      This currently isn't hookup up to the prompts yet, but it will be soon.
      
      So what is the format of the prompts? Prompts can contain variables that
      have access to the current program state. Variables are text that appears
      in between a prefix of "${" and ends with a "}". Some of the interesting
      variables include:
      
      // The frame index (0, 1, 2, 3...)
      ${frame.index}
      
      // common frame registers with generic names
      ${frame.pc}
      ${frame.sp}
      ${frame.fp}
      ${frame.ra}
      ${frame.flags}
      
      // Access to any frame registers by name where REGNAME is any register name:
      ${frame.reg.REGNAME}
      
      // The current compile unit file where the frame is located
      ${file.basename}
      ${file.fullpath}
      
      // Function information
      ${function.name}
      ${function.pc-offset}
      
      // Process info
      ${process.file.basename}
      ${process.file.fullpath}
      ${process.id}
      ${process.name}
      
      // Thread info
      ${thread.id}
      ${thread.index}
      ${thread.name}
      ${thread.queue}
      ${thread.stop-reason}
      
      // Target information
      ${target.arch}
      
      // The current module for the current frame (the shared library or executable
      // that contains the current frame PC value):
      ${module.file.basename}
      ${module.file.fullpath}
      
      // Access to the line entry for where the current frame is when your thread
      // is stopped:
      ${line.file.basename}
      ${line.file.fullpath}
      ${line.number}
      ${line.start-addr}
      ${line.end-addr}
      
      Many times the information that you might have in your prompt might not be
      available and you won't want it to print out if it isn't valid. To take care
      of this you can enclose everything that must resolve into a scope. A scope
      is starts with '{' and ends with '}'. For example in order to only display
      the current file and line number when the information is available the format
      would be:
      
      "{ at {$line.file.basename}:${line.number}}"
      
      Broken down this is:
      
      start the scope: "{"
      
      format whose content will only be displayed if all information is available:
              "at {$line.file.basename}:${line.number}"
      
      end the scope: "}"
      
      We currently can represent the infomration we see when stopped at a frame:
      
      frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19
      
      with the following format:
      
      "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n"
      
      This breaks down to always print:
      
              "frame #${frame.index}: ${frame.pc} "
      
      only print the module followed by a tick if we have a valid module:
      
              "{${module.file.basename}`}"
              
      print the function name with optional offset:
              "{${function.name}{${function.pc-offset}}"
      
      print the line info if it is available:
              
              "{ at ${line.file.basename}:${line.number}}"
      
      then finish off with a newline:
      
              "\n"
      
      Notice you can also put newlines ("\n") and tabs and everything else you
      are used to putting in a format string when desensitized with the \ character.
      
      Cleaned up some of the user settings controller subclasses. All of them 
      do not have any global settings variables and were all implementing stubs
      for the get/set global settings variable. Now there is a default version
      in UserSettingsController that will do nothing.
      
      llvm-svn: 114306
      1b654882
  27. Sep 16, 2010
  28. Sep 15, 2010
    • Caroline Tice's avatar
      Modify "settings list" so you can specify a particular instance setting name, · 7d9edf67
      Caroline Tice authored
      or a settings prefix, and it will list information about the subset of settings
      you requested.  Also added tab-completion (now that it takes an optional argument).
      
      llvm-svn: 113952
      7d9edf67
    • Caroline Tice's avatar
      · ded2fa39
      Caroline Tice authored
      Remove all visible uses of "[DEFAULT]" instance name.
      
      Add ability to rename UserSettingsInstances after they have been created
      (via UserSettingsController::RenameInstanceSettings.
      
      llvm-svn: 113950
      ded2fa39
  29. Sep 09, 2010
  30. Sep 08, 2010
  31. Sep 07, 2010
  32. Sep 04, 2010
    • Caroline Tice's avatar
      · 3df9a8df
      Caroline Tice authored
      This is a very large commit that completely re-does the way lldb
      handles user settable internal variables (the equivalent of set/show
      variables in gdb).  In addition to the basic infrastructure (most of
      which is defined in UserSettingsController.{h,cpp}, there are examples
      of two classes that have been set up to contain user settable
      variables (the Debugger and Process classes).  The 'settings' command
      has been modified to be a command-subcommand structure, and the 'set',
      'show' and 'append' commands have been moved into this sub-commabnd
      structure.  The old StateVariable class has been completely replaced
      by this, and the state variable dictionary has been removed from the
      Command Interpreter.  Places that formerly accessed the state variable
      mechanism have been modified to access the variables in this new
      structure instead (checking the term-width; getting/checking the
      prompt; etc.)
      
      Variables are attached to classes; there are two basic "flavors" of
      variables that can be set: "global" variables (static/class-wide), and
      "instance" variables (one per instance of the class).  The whole thing
      has been set up so that any global or instance variable can be set at
      any time (e.g. on start up, in your .lldbinit file), whether or not
      any instances actually exist (there's a whole pending and default
      values mechanism to help deal with that).
      
      llvm-svn: 113041
      3df9a8df
Loading