Commit Graph

26 Commits

Author SHA1 Message Date
Adrian Prantl 05097246f3 Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.

FYI, the script I used was:

import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
  header = ""
  text = ""
  comment = re.compile(r'^( *//) ([^ ].*)$')
  special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
  for line in f:
      match = comment.match(line)
      if match and not special.match(match.group(2)):
          # skip intentionally short comments.
          if not text and len(match.group(2)) < 40:
              out.write(line)
              continue

          if text:
              text += " " + match.group(2)
          else:
              header = match.group(1)
              text = match.group(2)

          continue

      if text:
          filled = textwrap.wrap(text, width=(78-len(header)),
                                 break_long_words=False)
          for l in filled:
              out.write(header+" "+l+'\n')
              text = ""

      out.write(line)

os.rename(tmp, sys.argv[1])

Differential Revision: https://reviews.llvm.org/D46144

llvm-svn: 331197
2018-04-30 16:49:04 +00:00
Zachary Turner 6f9e690199 Move Log from Core -> Utility.
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.

Differential Revision: https://reviews.llvm.org/D30559

llvm-svn: 296909
2017-03-03 20:56:28 +00:00
Zachary Turner bf9a77305f Move classes from Core -> Utility.
This moves the following classes from Core -> Utility.

ConstString
Error
RegularExpression
Stream
StreamString

The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes.  So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.

Differential Revision: https://reviews.llvm.org/D29427

llvm-svn: 293941
2017-02-02 21:39:50 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

    find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
    find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Greg Clayton fdbad6d5d8 Improve logging a bit by printing the exception or signal type description.
llvm-svn: 202423
2014-02-27 19:35:12 +00:00
Jim Ingham 60c4118c88 If ThreadPlanCallFunction hasn't set its notion of the "real stop info" yet, just return the current PrivateStopInfo.
Also renamed a few more places where we were using StopReason in functions that were returning StopInfo's.

<rdar://problem/14042692>

llvm-svn: 183177
2013-06-04 01:40:51 +00:00
Jim Ingham 221d51cf84 Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached
value.  This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop because they were at their "run to here" breakpoint, then deleted
that breakpoint, so when they got asked again, doh!  I had done this for a couple of plans
in an ad hoc fashion, this just formalizes it.

Also add a "ResumeRequested" in Process so that the code in the completion handlers can
tell the ShouldStop logic they want to resume rather than just directly resuming.  That allows 
us to handle resuming in a more controlled fashion.

Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when
the target was immediately restarted.
--This line, and those below , will be ignored--

M    test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py
M    include/lldb/Target/ThreadList.h
M    include/lldb/Target/ThreadPlanStepOut.h
M    include/lldb/Target/Thread.h
M    include/lldb/Target/ThreadPlanBase.h
M    include/lldb/Target/ThreadPlanStepThrough.h
M    include/lldb/Target/ThreadPlanStepInstruction.h
M    include/lldb/Target/ThreadPlanStepInRange.h
M    include/lldb/Target/ThreadPlanStepOverBreakpoint.h
M    include/lldb/Target/ThreadPlanStepUntil.h
M    include/lldb/Target/StopInfo.h
M    include/lldb/Target/Process.h
M    include/lldb/Target/ThreadPlanRunToAddress.h
M    include/lldb/Target/ThreadPlan.h
M    include/lldb/Target/ThreadPlanCallFunction.h
M    include/lldb/Target/ThreadPlanStepOverRange.h
M    source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
M    source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
M    source/Target/StopInfo.cpp
M    source/Target/Process.cpp
M    source/Target/ThreadPlanRunToAddress.cpp
M    source/Target/ThreadPlan.cpp
M    source/Target/ThreadPlanCallFunction.cpp
M    source/Target/ThreadPlanStepOverRange.cpp
M    source/Target/ThreadList.cpp
M    source/Target/ThreadPlanStepOut.cpp
M    source/Target/Thread.cpp
M    source/Target/ThreadPlanBase.cpp
M    source/Target/ThreadPlanStepThrough.cpp
M    source/Target/ThreadPlanStepInstruction.cpp
M    source/Target/ThreadPlanStepInRange.cpp
M    source/Target/ThreadPlanStepOverBreakpoint.cpp
M    source/Target/ThreadPlanStepUntil.cpp
M    lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme

llvm-svn: 181381
2013-05-08 00:35:16 +00:00
Daniel Malea 7f3859538f Revert 180829 as it causes hangs in TestTypeCompletion.py on 2 Linux buildbots:
http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/3810
http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang/builds/2754

llvm-svn: 180870
2013-05-01 19:14:30 +00:00
Jim Ingham 2d386b35eb Make "process handle -n true -s false" actually notifies of the signal.
rdar://problem/12020085

llvm-svn: 180829
2013-04-30 23:42:24 +00:00
Greg Clayton 5160ce5c72 <rdar://problem/13521159>
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191
2013-03-27 23:08:40 +00:00
Jim Ingham 9b620f341a The thread plans run before the event is broadcast, so they should be calling ShouldStopSynchronous on any Stop Info's
they want to check.  The full ShouldStop should only be called on the public side of the event system.

llvm-svn: 175922
2013-02-22 21:23:43 +00:00
Jim Ingham 0161b49cba Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug 
session.

<rdar://problem/12993641>

llvm-svn: 174793
2013-02-09 01:29:05 +00:00
Andrew Kaylor f85defaea5 Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.
llvm-svn: 170800
2012-12-20 23:08:03 +00:00
Greg Clayton 90ba81150e <rdar://problem/12649160>
Added the ability to debug through your process exec'ing itself to the same architecture.

llvm-svn: 169340
2012-12-05 00:16:59 +00:00
Daniel Malea d01b2953fa Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

llvm-svn: 168945
2012-11-29 21:49:15 +00:00
Jim Ingham cf274f910e Rework how master plans declare themselves. Also make "PlanIsBasePlan" not rely only on this being the bottom plan in the stack, but allow the plan to declare itself as such.
llvm-svn: 154351
2012-04-09 22:37:39 +00:00
Greg Clayton 81c22f6104 Moved lldb::user_id_t values to be 64 bit. This was going to be needed for
process IDs, and thread IDs, but was mainly needed for for the UserID's for
Types so that DWARF with debug map can work flawlessly. With DWARF in .o files
the type ID was the DIE offset in the DWARF for the .o file which is not
unique across all .o files, so now the SymbolFileDWARFDebugMap class will
make the .o file index part (the high 32 bits) of the unique type identifier
so it can uniquely identify the types.

llvm-svn: 142534
2011-10-19 18:09:39 +00:00
Johnny Chen fd158f411a StopInfoWatchpoint should override the StopInfo::ShouldStop() virtual method and delegate to
the WatchpointLocation object to check whether it should stop and allow it to update the hit
count, among other bookkeepings.

llvm-svn: 140279
2011-09-21 22:47:15 +00:00
Jim Ingham 0f16e73a76 Rework the RunThreadPlan event handling to use Event Hijacking not stopping the event thread. Also clarify the logic of the function.
llvm-svn: 125083
2011-02-08 05:20:59 +00:00
Jim Ingham 444586b5d2 More useful STEP logging.
Be sure to clear out the base plan's m_report_run and m_report_stop each time we resume so we don't use stale values.

llvm-svn: 124113
2011-01-24 06:34:17 +00:00
Jim Ingham 773d981ce2 The thread plan destructors may call Thread virtual methods. That means they have to get cleaned up in the derived class's destructor. Make sure that happens.
llvm-svn: 119675
2010-11-18 02:47:07 +00:00
Jim Ingham 06e827cc43 Add ThreadPlanTracer class to allow instruction step tracing of execution.
Also changed eSetVarTypeBool to eSetVarTypeBoolean to make it consistent with eArgTypeBoolean.

llvm-svn: 118824
2010-11-11 19:26:09 +00:00
Jim Ingham b15bfc753c Don't cache the public stop reason, since it can change as plan completion gets processed. That means GetStopReason needs to return a shared pointer, not a pointer to the thread's cached version. Also allow the thread plans to get and set the thread private stop reason - that is usually more appropriate for the logic the thread plans need to do.
llvm-svn: 116892
2010-10-20 00:39:53 +00:00
Greg Clayton f4b47e1579 Abtracted the old "lldb_private::Thread::StopInfo" into an abtract class.
This will allow debugger plug-ins to make any instance of "lldb_private::StopInfo"
that can completely describe any stop reason. It also provides a framework for
doing intelligent things with the stop info at important times in the lifetime
of the inferior. 

Examples include the signal stop info in StopInfoUnixSignal. It will check with
the process to see that the current action is for the signal. These actions
include wether to stop for the signal, wether the notify that the signal was
hit, and wether to pass the signal along to the inferior process. The 
StopInfoUnixSignal class overrides the "ShouldStop()" method of StopInfo and
this allows the stop info to determine if it should stop at the signal or 
continue the process. 


StopInfo subclasses must override the following functions:

    virtual lldb::StopReason
    GetStopReason () const = 0;

    virtual const char *
    GetDescription () = 0;


StopInfo subclasses can override the following functions:


    // If the subclass returns "false", the inferior will resume. The default
    // version of this function returns "true" which means the default stop
    // info will stop the process. The breakpoint subclass will check if
    // the breakpoint wants us to stop by calling any installed callback on
    // the breakpoint, and also checking if the breakpoint is for the current
    // thread. Signals will check if they should stop based off of the 
    // UnixSignal settings in the process.
    virtual bool
    ShouldStop (Event *event_ptr);

    // Sublasses can state if they want to notify the debugger when "ShouldStop"
    // returns false. This would be handy for breakpoints where you want to
    // log information and continue and is also used by the signal stop info
    // to notify that a signal was received (after it checks with the process
    // signal settings).
    virtual bool
    ShouldNotify (Event *event_ptr)
    {
        return false;
    }

    // Allow subclasses to do something intelligent right before we resume.
    // The signal class will figure out if the signal should be propagated
    // to the inferior process and pass that along to the debugger plug-ins.
    virtual void
    WillResume (lldb::StateType resume_state)
    {
        // By default, don't do anything
    }


The support the Mach exceptions was moved into the lldb/source/Plugins/Process/Utility
folder and now doesn't polute the lldb_private::Thread class with platform
specific code.

llvm-svn: 110184
2010-08-04 01:40:35 +00:00
Jim Ingham b01e742af7 Two changes in this checkin. Added a ThreadPlanKind so that I can do some reasoning based on the kind of thread plan
without having to use RTTI.
Removed the ThreadPlanContinue and replaced with a ShouldAutoContinue query that serves the same purpose.  Having to push
another plan to assert that if there's no other indication the target should continue when this plan is popped was flakey
and error prone.  This method is more stable, and fixed problems we were having with thread specific breakpoints.

llvm-svn: 106378
2010-06-19 04:45:32 +00:00
Chris Lattner 30fdc8d841 Initial checkin of lldb code from internal Apple repo.
llvm-svn: 105619
2010-06-08 16:52:24 +00:00