Commit Graph

17 Commits

Author SHA1 Message Date
Jonas Devlieghere 8b3af63b89 [NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135
2019-04-10 20:48:55 +00:00
Jim Ingham cdd4892f12 Use the multi-lockable form of std::lock for operator=
For = operators for lists that have mutexes, we were either
just taking the locks sequentially or hand-rolling a trick
to try to avoid lock inversion.  Use the std::lock mechanism
for this instead.

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

llvm-svn: 357276
2019-03-29 17:07:30 +00:00
Jim Ingham 1432b9780b Copy the breakpoint site owner's collection so we can drop
the collection lock before we iterate over the owners calling ShouldStop.

BreakpointSite::ShouldStop can do a lot of work, and might by chance hit the same breakpoint
site again on another thread.  So instead of holding the site's owners lock
while iterating over them calling ShouldStop, I make a local copy of the list, drop the lock 
and then iterate over the copy calling BreakpointLocation::ShouldStop.

It's actually quite difficult to make this cause problems because usually all the
action happens on the private state thread, and the lock is recursive.

I have a report where some code hit the ASAN error breakpoint, went to 
compile the ASAN error gathering expression, in the course of compiling
that we went to fetch the ObjC runtime data, but the state of the program
was such that the ObjC runtime grubbing function triggered an ASAN error and 
we were executing that function on another thread.  

I couldn't figure out a way to reproduce that situation in a test.  But this is an 
NFC change anyway, it just makes the locking strategy more narrowly focused.

<rdar://problem/49074093>

llvm-svn: 357141
2019-03-28 01:51:33 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Jonas Devlieghere ceff6644bb Remove header grouping comments.
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626
2018-11-11 23:17:06 +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
Jim Ingham 1cf8f5937a Lock the access to the BreakpointLocationCollection.
I was investigating an odd crash in lldb when the breakpoint site
goes to bump the hit counts of the locations it implements.  I noticed
that the BreakpointLocationCollection wasn't locking itself for access and
modification.  I don't see how that can cause the crash I'm seeing, but still
this is the right thing to do...

<rdar://problem/25178205>

llvm-svn: 270939
2016-05-26 23:55:04 +00:00
Tamas Berghammer 729dcfb7ee Fix BreakpointLocationCollection::ShouldStop to handle breakpoint removal
Differential revision: http://reviews.llvm.org/D9886

llvm-svn: 238308
2015-05-27 09:46:47 +00:00
Jim Ingham a672ecefef The breakpoint location hit counts were getting incremented in
BreakpointLocation::ShouldStop.  That worked but wasn't really right,
since there's nothing to guarantee that won't get called more than
once.  So this change moves that responsibility to the StopInfoBreakpoint
directly, and then it uses the BreakpointSite to actually do the bumping.

Also fix a test case that was assuming if you had many threads running some 
code with a breakpoint in it, the hit count when you stopped would always be
1.  Many of the threads could have hit it at the same time...

<rdar://problem/18577603>

llvm-svn: 220358
2014-10-22 01:54:17 +00:00
Jim Ingham 2995077d8a Add "target.process.stop-on-shared-library-events" setting, and make it work.
Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint
print that in the brief description if set.  Also print the kind - if set - in the breakpoint
listing.
Give kinds to a bunch of the internal breakpoints.
We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was
a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it.  Fixed that.

llvm-svn: 173555
2013-01-26 02:19:28 +00:00
Greg Clayton c7bece56fa <rdar://problem/13069948>
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.

llvm-svn: 173463
2013-01-25 18:06:21 +00:00
Jim Ingham e6bc6cb96f Send Breakpoint Changed events for all the relevant changes to breakpoints.
Also, provide and use accessors for the thread options on breakpoints so we
can control sending the appropriate events.

llvm-svn: 150057
2012-02-08 05:23:15 +00:00
Greg Clayton 4e78f60660 Added the ability to get more information on the SBThread's stop reason
by being able to get the data count and data. Each thread stop reason
has one or more data words that can help describe the stop. To do this
I added:

    size_t
	SBThread::GetStopReasonDataCount();

	uint64_t
	SBThread::GetStopReasonDataAtIndex(uint32_t idx);

llvm-svn: 119720
2010-11-18 18:52:36 +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
Greg Clayton c982c768d2 Merged Eli Friedman's linux build changes where he added Makefile files that
enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.

llvm-svn: 108009
2010-07-09 20:39:50 +00:00
Jim Ingham 1b54c88cc4 Add a "thread specification" class that specifies thread specific breakpoints by name, index, queue or TID.
Push this through all the breakpoint management code.  Allow this to be set when the breakpoint is created.
Fix the Process classes so that a breakpoint hit that is not for a particular thread is not reported as a 
breakpoint hit event for that thread.
Added a "breakpoint configure" command to allow you to reset any of the thread 
specific options (or the ignore count.)

llvm-svn: 106078
2010-06-16 02:00:15 +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