Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging.
Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function.
llvm-svn: 192491
line breakpoints past the prologue of functions so it can be shared between the
file & line breakpoint resolver, and the source pattern breakpoint resolver,
and then share it.
llvm-svn: 191478
"coalesce the line ranges for a file & line breakpoint to the first range in each block". We were still setting a silly number
of independent breakpoints sometimes, and until we get a compiler that emits trustworthy is_stmt flags in the line table, we
need to do something to reduce the noise.
<rdar://problem/14920404>
llvm-svn: 190380
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
and any breakpoints with section relative addresses won't resolve their load addresses so they will error out at that point.
<rdar://problem/13900130>
llvm-svn: 185170
doesn't return anything; that's great.
We should probably also return rather than
trying to access the nonexistent return value.
<rdar://problem/14009519>
llvm-svn: 184765
325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote.
That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly.
Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed.
llvm-svn: 183820
condition in two different processes (with the
same target) could cause crashes. Now the breakpoint
condition is always evaluated (and possibly parsed)
by one thread at a time.
<rdar://problem/14083737>
llvm-svn: 183440
Previously, the options for a breakopint or its
locations stored only the text of the breakpoint
condition (ironically, they used ClangUserExpression
as a glorified std::string) and, each time the condition
had to be evaluated in the StopInfo code, the expression
parser would be invoked via a static method to parse and
then execute the expression.
I made several changes here:
- Each breakpoint location now has its own
ClangUserExpressionSP containing a version of
the breakpoint expression compiled for that exact
location.
- Whenever the breakpoint is hit, the breakpoint
condition expression is simply re-run to determine
whether to stop.
- If the process changes (e.g., it's re-run) or
the source code of the expression changes (we use
a hash so as to avoid doing string comparisons)
the ClangUserExpressionSP is re-generated.
This should improve performance of breakpoint
conditions significantly, and takes advantage of
the recent expression re-use work.
llvm-svn: 179838
Symbol table function names should support lookups like symbols with debug info.
To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.
llvm-svn: 178608
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
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
Cleaned up the objective C name parsing code to use a class.
Now breakpoints that are set by name that are objective C methods without the leading '+' or '-' will resolve. We do this by expanding all the objective C names for a given string. For example:
(lldb) b [MyString cStringUsingEncoding:]
Will set a breakpoint with multiple possible names:
-[MyString cStringUsingEncoding:]
+[MyString cStringUsingEncoding:]
Also if you have a category, it will strip the category and set a breakpoint in all variants:
(lldb) [MyString(my_category) cStringUsingEncoding:]
Will resolve to the following names:
-[MyString(my_category) cStringUsingEncoding:]
+[MyString(my_category) cStringUsingEncoding:]
-[MyString cStringUsingEncoding:]
+[MyString cStringUsingEncoding:]
Likewise when we have:
(lldb) b -[MyString(my_category) cStringUsingEncoding:]
It will resolve to two names:
-[MyString(my_category) cStringUsingEncoding:]
-[MyString cStringUsingEncoding:]
llvm-svn: 173858
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
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
Setting breakpoints using "breakpoint set --selector <SEL>" previously didn't when there was no dSYM file.
Also fixed issues in the test suite that arose after fixing the bug.
Also fixed the log channels to properly ref count the log streams using weak pointers to the streams. This fixes a test suite problem that would happen when you specified a full path to the compiler with the "--compiler" option.
llvm-svn: 171816
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.
llvm-svn: 166472
enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing
Mutex::Locker(m_map_mutex);
This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately. Instead,
Mutex::Locker locker(m_map_mutex);
does what is intended. For some reason -Wshadow happened to
highlight these as shadowed variables.
I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>
llvm-svn: 165269
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
Previously we put a WatchpointSentry object within StopInfo.cpp to disable-and-then-enable the watchpoint itself
while we are performing the actions associated with the triggered watchpoint, which can cause the user-initiated
watchpoint disabling action to be negated.
Add a test case to verify that a watchpoint can be disabled during the callbacks.
llvm-svn: 162483
Watchpoint conditions were hitting watchpoint, smashing LLDB's stack.
Make sure watchpoint is properly disabled and subsequently enabled while performing watchpoint actions.
llvm-svn: 162322
do not take the sanpshot and forget about the stop info. It is possible that the variable expression has gone
out of scope, we'll revise the hit count due to the false alarms.
llvm-svn: 161892
Record the snapshot of our watched value when the watchpoint is set or hit.
And report the old/new values when watchpoint is triggered. Add some test scenarios.
llvm-svn: 161785
setting breakpoints. That's dangerous, since while we are setting a breakpoint,
the target might hit the dyld load notification, and start removing modules from
the list. This change adds a GetMutex accessor to the ModuleList class, and
uses it whenever we are accessing the target's ModuleList (as returned by GetImages().)
<rdar://problem/11552372>
llvm-svn: 157668
"break set" commands to set this per breakpoint. Also, some CreateBreakpoint API's in the lldb_private
namespace had "internal" first and "skip_prologue" second. "internal should always be last. Fixed that.
rdar://problem/11484729
llvm-svn: 157225
Jim Ingham