1. 21 3月, 2019 1 次提交
  2. 27 2月, 2019 1 次提交
  3. 05 1月, 2019 1 次提交
    • D
      *: Update import name to github.com/go-delve/delve · 4c9a72e4
      Derek Parker 提交于
      The repository is being switched from the personal account
      github.com/derekparker/delve to the organization account
      github.com/go-delve/delve. This patch updates imports and docs, while
      preserving things which should not be changed such as my name in the
      CHANGELOG and in TODO comments.
      4c9a72e4
  4. 10 11月, 2018 1 次提交
    • A
      proc: Improve performance of loadMap on very large sparse maps · 89c8da65
      aarzilli 提交于
      Users can create sparse maps in two ways, either by:
      a) adding lots of entries to a map and then deleting most of them, or
      b) using the make(mapType, N) expression with a very large N
      
      When this happens reading the resulting map will be very slow
      because loadMap needs to scan many buckets for each entry it finds.
      
      Technically this is not a bug, the user just created a map that's
      very sparse and therefore very slow to read. However it's very
      annoying to have the debugger hang for several seconds when trying
      to read the local variables just because one of them (which you
      might not even be interested into) happens to be a very sparse map.
      
      There is an easy mitigation to this problem: not reading any
      additional buckets once we know that we have already read all
      entries of the map, or as many entries as we need to fulfill the
      MaxArrayValues parameter.
      
      Unfortunately this is mostly useless, a VLSM (Very Large Sparse Map)
      with a single entry will still be slow to access, because the single
      entry in the map could easily end up in the last bucket.
      
      The obvious solution to this problem is to set a limit to the
      number of buckets we read when loading a map. However there is no
      good way to set this limit.
      If we hardcode it there will be no way to print maps that are beyond
      whatever limit we pick.
      We could let users (or clients) specify it but the meaning of such
      knob would be arcane and they would have no way of picking a good
      value (because there is no objectively good value for it).
      
      The solution used in this commit is to set an arbirtray limit on
      the number of buckets we read but only when loadMap is invoked
      through API calls ListLocalVars and ListFunctionArgs. In this way
      `ListLocalVars` and `ListFunctionArgs` (which are often invoked
      automatically by GUI clients) remain fast even in presence of a
      VLSM, but the contents of the VLSM can still be inspected using
      `EvalVariable`.
      89c8da65
  5. 20 10月, 2018 1 次提交
    • D
      *: Show return values on CLI trace · 3129aa73
      Derek Parker 提交于
      This patch allows the `trace` CLI subcommand to display return values of
      a function. Additionally, it will also display information on where the
      function exited, which could also be helpful in determining the path
      taken during function execution.
      
      Fixes #388
      3129aa73
  6. 16 10月, 2018 2 次提交
  7. 25 9月, 2018 1 次提交
  8. 20 9月, 2018 1 次提交
  9. 31 8月, 2018 1 次提交
    • A
      proc,service,terminal: information about stack trace truncation · ac74944d
      aarzilli 提交于
      Add a flag to Stackframe that indicates where the stack frame is the
      bottom-most frame of the stack. This allows clients to know whether the
      stack trace terminated normally or if it was truncated because the
      maximum depth was reached.
      Add a truncation message to the 'stack' command.
      ac74944d
  10. 25 7月, 2018 1 次提交
    • A
      proc,service,terminal: read defer list · 8f1fc63d
      aarzilli 提交于
      Adds -defer flag to the stack command that decorates the stack traces
      by associating each stack frame with its deferred calls.
      
      Reworks proc.next to use this feature instead of using proc.DeferPC,
      laying the groundwork to implement #1240.
      8f1fc63d
  11. 14 7月, 2018 1 次提交
  12. 10 7月, 2018 1 次提交
  13. 29 6月, 2018 1 次提交
  14. 27 6月, 2018 1 次提交
    • A
      proc,terminal,service: let headless instances run without connected clients · 9a216211
      aarzilli 提交于
      This pull request makes several changes to delve to allow headless
      instancess that are started with the --accept-multiclient flag to
      keep running even if there is no connected client. Specifically:
      
      1. Makes a headless instance started with --accept-multiclient quit
          after one of the clients sends a Detach request (previously they
          would never ever quit, which was a bug).
      2. Changes proc/gdbserial and proc/native so that they mark the
          Process as exited after they detach, even if they did not kill the
          process during detach. This prevents bugs such as #1231 where we
          attempt to manipulate a target process after we detached from it.
      3. On non --accept-multiclient instances do not kill the target
          process unless we started it or the client specifically requests
          it (previously if the client did not Detach before closing the
          connection we would kill the target process unconditionally)
      4. Add a -c option to the quit command that detaches from the
          headless server after restarting the target.
      5. Change terminal so that, when attached to --accept-multiclient,
          pressing ^C will prompt the user to either disconnect from the
          server or pause the target process. Also extend the exit prompt to
          ask if the user wants to keep the headless server running.
      
      Implements #245, #952, #1159, #1231
      9a216211
  15. 12 6月, 2018 1 次提交
    • A
      proc,service: display return values when stepping out of a function · 60c58acb
      aarzilli 提交于
      Displays the return values of the current function when we step out of
      it after executing a step, next or stepout command.
      
      Implementation of this feature is tricky: when the function has
      returned the return variables are not in scope anymore. Implementing
      this feature requires evaluating variables that are out of scope, using
      a stack frame that doesn't exist anymore.
      
      We can't calculate the address of these variables when the
      next/step/stepout command is initiated either, because between that
      point and the time where the stepout breakpoint is actually hit the
      goroutine stack could grow and be moved to a different memory address.
      60c58acb
  16. 24 4月, 2018 1 次提交
  17. 20 3月, 2018 1 次提交
  18. 19 1月, 2018 1 次提交
  19. 21 12月, 2017 1 次提交
  20. 14 12月, 2017 2 次提交
  21. 08 12月, 2017 2 次提交
  22. 29 11月, 2017 1 次提交
  23. 21 11月, 2017 1 次提交
    • A
      proc: next should not skip lines with conditional bps · 1ced7c3a
      aarzilli 提交于
      Conditional breakpoints with unmet conditions would cause next and step
      to skip the line.
      
      This breakpoint changes the Kind field of proc.Breakpoint from a single
      value to a bit field, each breakpoint object can represent
      simultaneously a user breakpoint and one internal breakpoint (of which
      we have several different kinds).
      
      The breakpoint condition for internal breakpoints is stored in the new
      internalCond field of proc.Breakpoint so that it will not conflict with
      user specified conditions.
      
      The breakpoint setting code is changed to allow overlapping one
      internal breakpoint on a user breakpoint, or a user breakpoint on an
      existing internal breakpoint. All other combinations are rejected. The
      breakpoint clearing code is changed to clear the UserBreakpoint bit and
      only remove the phisical breakpoint if no other bits are set in the
      Kind field. ClearInternalBreakpoints does the same thing but clearing
      all bits that aren't the UserBreakpoint bit.
      
      Fixes #844
      1ced7c3a
  24. 04 11月, 2017 1 次提交
  25. 25 10月, 2017 1 次提交
    • A
      proc/eval: support more type casts · 8f16b371
      aarzilli 提交于
      * string to []rune
      * string to []byte
      * []rune to string
      * []byte to string
      * any pointer to uintptr
      
      The string, []rune, []byte conversion pairs aligns this to the go
      language.
      The pointer -> uintptr conversion pair is symmetric to the uintptr ->
      pointer that we already have.
      
      Also lets the user specify any size for byte array types instead of
      just the ones already used by the program, this can be used to read
      arbitrary memory.
      
      Fixes #548, #867
      8f16b371
  26. 12 9月, 2017 1 次提交
  27. 31 8月, 2017 1 次提交
  28. 02 8月, 2017 3 次提交
  29. 27 7月, 2017 1 次提交
  30. 30 6月, 2017 2 次提交
    • A
      proc/variables: dereference concrete value of interface variables (#905) · 293c5087
      Alessandro Arzilli 提交于
      The concrete value of an interface is always stored as a pointer inside
      an interface variable. So far we have followed the memory layout and
      reported the type of the 'data' attribute of interfaces as a pointer,
      however this makes it impossible to distinguish interfaces with
      concrete value of type 'A' from interfaces of concrete value of type
      '*A'.
      
      With this changeset when we autodereference pointers when the concrete
      type of an interface is not a pointer.
      293c5087
    • F
      Fix various issues detected by megacheck (#880) · 32a005de
      Florin Pățan 提交于
      * Fix various issues detected by megacheck
      
      I've ran honnef.co/go/tools/cmd/megacheck and fixed a few of the
      things that came up there.
      
      * Cleanup using Gogland
      32a005de
  31. 21 6月, 2017 1 次提交
    • A
      api: add FrameOffset to Stackframe (#864) · 04c4b019
      Alessandro Arzilli 提交于
      Other debuggers can be instructed to decorate the stacktrace with the
      value of SP. Our SP equivalent is the frame offset, since we can add it
      to the Stackframe structure without incurring into added costs we
      should, so that frontends can use it if they want.
      04c4b019
  32. 06 5月, 2017 1 次提交
  33. 22 4月, 2017 2 次提交
    • A
      proc: refactoring: merge target into proc · b6fe5aeb
      aarzilli 提交于
      - moved target.Interface into proc as proc.Process
      - rename proc.IThread to proc.Thread
      - replaced interfaces DisassembleInfo, Continuable and
        EvalScopeConvertible with Process.
      - removed superfluous Gdbserver prefix from types in the gdbserial
        backend.
      - removed superfluous Core prefix from types in the core backend.
      b6fe5aeb
    • A
      proc: refactoring: split backends to separate packages · 15bac719
      aarzilli 提交于
      - move native backend to pkg/proc/native
      - move gdbserver backend to pkg/proc/gdbserial
      - move core dumps backend to pkg/proc/core
      15bac719