summaryrefslogtreecommitdiffstats
path: root/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFC] Remove strange bool parameter from Searcher::SearchCallbackRaphael Isemann2019-10-101-4/+2
| | | | | | | | | | | | | | | | | | | Summary: The SearchCallback has a bool parameter that we always set to false, we never use in any callback implementation and that also changes its name from one file to the other (either `containing` and `complete`). It was added in the original LLDB check in, so there isn't any history what this was supposed to be, so let's just remove it. Reviewers: jingham, JDevlieghere, labath Reviewed By: jingham, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68696 llvm-svn: 374313
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Remove header grouping comments.Jonas Devlieghere2018-11-111-4/+0
| | | | | | | | 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
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-1/+1
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* NFC: Move Searcher::Depth into lldb-enumerations as SearchDepth.Jim Ingham2018-09-071-2/+2
| | | | | | | | In a subsequent commit, I will need to expose the search depth to the SB API's, so I'm moving this define into lldb-enumerations where it will get added to the lldb module. llvm-svn: 341690
* Support setting a breakpoint by FileSpec+Line+Column in the SBAPI.Adrian Prantl2018-08-301-10/+25
| | | | | | | | | | | | This patch extends the SBAPI to allow for setting a breakpoint not only at a specific line, but also at a specific (minimum) column. When a column is specified, it will try to find an exact match or the closest match on the same line that comes after the specified location. Differential Revision: https://reviews.llvm.org/D51461 llvm-svn: 341078
* If a function starts with line number 0, don't try to check if a breakpoint ↵Jim Ingham2018-08-071-1/+5
| | | | | | | | | | crossed function boundaries. clang doesn't use line number 0 (to mean artifically generated code) very often, but swift does it quite often. We were rejecting all by line breakpoints in functions that started at line 0. But that's a special marker so we can just not do this test in that case. llvm-svn: 339182
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Always normalize FileSpec paths.Greg Clayton2018-04-271-1/+1
| | | | | | | | Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
* Allow relative file paths when settings source breakpointsGreg Clayton2018-04-131-4/+29
| | | | | | | | | | | | | | | | | Many IDEs set breakpoints using absolute paths and this causes problems when the full path of the source file path doesn't match what is in the debug info. This can be due to different build systems and do or do not resolve symlinks. This patch allows relative breakpoint to be set correctly without needing to do any target.source-map tricks. If IDEs want to, they can send down relative paths like: ./main.c ./src/main.c src/main.c foo/bar/src/main.c I used the breakpoint resolver to match on the file basename and then we weed out anything whose relative paths don't match. This will be a huge improvement for IDEs as they can specify as much of a relative path as desired to uniquely identify a source file in the current project. Differential Revision: https://reviews.llvm.org/D45592 llvm-svn: 330028
* Update StructuredData::String to return StringRefs.Zachary Turner2017-05-121-1/+1
| | | | | | | | It was returning const std::string& which was leading to unnecessary copies all over the place, and preventing people from doing things like Dict->GetValueForKeyAsString("foo", ref); llvm-svn: 302875
* Rename Error -> Status.Zachary Turner2017-05-121-1/+1
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* BreakpointResolverFileLine: Restrict move-to-nearest-code from moving across ↵Pavel Labath2017-03-151-16/+77
| | | | | | | | | | | | | | | | | | | | | | | | | function boundaries Summary: This fixes the case where a user tries to set a breakpoint on a source line outside of any function (e.g. because that code is #ifdefed out, or the compiler did not emit code for the function, etc.) and we would silently move the breakpoint to the next function. Now we check whether the line range of the resolved symbol context function matches the original line number. We reject any breakpoint locations that appear to move the breakpoint into a new function. This filtering only happens if we have full debug info available (e.g. in case of -gline-tables-only compilation, we still set the breakpoint on the nearest source line). Reviewers: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30817 llvm-svn: 297817
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | 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
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* Make lldb::Regex use StringRef.Zachary Turner2016-09-211-1/+1
| | | | | | | | | | This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
* Add a few const's (thanks Zachary) and return shared or unique pointersJim Ingham2016-09-131-1/+2
| | | | | | in places where they help prevent leaks. llvm-svn: 281288
* This is the main part of a change to add breakpoint save and restore to lldb.Jim Ingham2016-09-121-0/+71
| | | | | | | | | | | | | | | Still to come: 1) SB API's 2) Testcases 3) Loose ends: a) serialize Thread options b) serialize Exception resolvers 4) "break list --file" should list breakpoints contained in a file and "break read -f 1 3 5" should then read in only those breakpoints. <rdar://problem/12611863> llvm-svn: 281273
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-84/+61
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Add an "offset" option to "break set -n" and "break set -f -l". Jim Ingham2016-03-091-1/+3
| | | | | | | | | | | | That way you can set offset breakpoints that will move as the function they are contained in moves (which address breakpoints can't do...) I don't align the new address to instruction boundaries yet, so you have to get this right yourself for now. <rdar://problem/13365575> llvm-svn: 263049
* Add --move-to-nearest-code / target.move-to-nearest-code options (attempt 2)Ilia K2015-05-181-5/+8
| | | | | | | | | | | | This patch initially was committed in r237460 but later it was reverted (r237479) due to 4 new failures: * TestExitDuringStep.py * TestNumThreads.py * TestThreadExit.py * TestThreadStates.py This patch also fixes these tests. llvm-svn: 237566
* Reverting r237460 to fix test failures introduced on OSX & LinuxVince Harron2015-05-151-8/+5
| | | | | | | | | TestExitDuringStep.py TestNumThreads.py TestThreadExit.py TestThreadStates.py llvm-svn: 237479
* Add --move-to-nearest-code / target.move-to-nearest-code optionsIlia K2015-05-151-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This option forces to only set a source line breakpoint when there is an exact-match This patch includes the following commits: # Add the -m/--exact-match option in "breakpoint set" command ## Add exact_match arg in BreakpointResolverFileLine ctor ## Add m_exact_match field in BreakpointResolverFileLine ## Add exact_match arg in BreakpointResolverFileRegex ctor ## Add m_exact_match field in BreakpointResolverFileRegex ## Add exact_match arg in Target::CreateSourceRegexBreakpoint ## Add exact_match arg in Target::CreateBreakpoint ## Add -m/--exact-match option in "breakpoint set" command # Add target.exact-match option to skip BP if source line doesn't match ## Add target.exact-match global option ## Add Target::GetExactMatch ## Refactor Target::CreateSourceRegexBreakpoint to accept LazyBool exact_match (was bool) ## Refactor Target::CreateBreakpoint to accept LazyBool exact_match (was bool) # Add target.exact-match test in SettingsCommandTestCase # Add BreakpointOptionsTestCase tests to test --skip-prologue/--exact-match options # Fix a few typos in lldbutil.check_breakpoint_result func # Rename --exact-match/m_exact_match/exact_match/GetExactMatch to --move-to-nearest-code/m_move_to_nearest_code/move_to_nearest_code/GetMoveToNearestCode # Add exact_match field in BreakpointResolverFileLine::GetDescription and BreakpointResolverFileRegex::GetDescription, for example: was: ``` 1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, locations = 1, resolved = 1, hit count = 2 1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2 ``` now: ``` 1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 2 1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2 ``` Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb functionalities/breakpoint/ ./dotest.py -v --executable $BUILDDIR/bin/lldb settings/ ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/breakpoint/ Reviewers: jingham, clayborg Reviewed By: clayborg Subscribers: lldb-commits, clayborg, jingham Differential Revision: http://reviews.llvm.org/D9273 llvm-svn: 237460
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-181-1/+0
| | | | | | | | | So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
* Add the ability to set breakpoints with conditions, commands, etc,Jim Ingham2014-12-061-0/+11
| | | | | | | | | | | | | | in the "dummy-target". The dummy target breakpoints prime all future targets. Breakpoints set before any target is created (e.g. breakpoints in ~/.lldbinit) automatically get set in the dummy target. You can also list, add & delete breakpoints from the dummy target using the "-D" flag, which is supported by most of the breakpoint commands. This removes a long-standing wart in lldb... <rdar://problem/10881487> llvm-svn: 223565
* Factor the code that was eliminating redundant breakpoint locations and movingJim Ingham2013-09-271-139/+6
| | | | | | | | 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
* Change the "breakpoint fuzz" algorithm from "coalesce the line ranges for a ↵Jim Ingham2013-09-101-7/+6
| | | | | | | | | | | | file & line breakpoint if they are contiguous" to "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
* Sort out a number of mismatched integer types in order to cut down the ↵Andy Gibbs2013-06-191-1/+1
| | | | | | number of compiler warnings. llvm-svn: 184333
* Be sure to print out the full file path when dumping breakpoint resolvers ↵Greg Clayton2013-06-131-1/+1
| | | | | | for file and line when the full path was specified. llvm-svn: 183932
* <rdar://problem/13521159>Greg Clayton2013-03-271-1/+1
| | | | | | | | 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
* For file & line breakpoints, if there are subsets of contiguous line table ↵Jim Ingham2013-03-121-51/+67
| | | | | | | | entries for the specified line, set the breakpoint on the first one of each of the contiguous sub-sets of entries, and not all the others. llvm-svn: 176846
* <rdar://problem/13069948>Greg Clayton2013-01-251-2/+2
| | | | | | | | | | | | 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
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-2/+2
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* <rdar://problem/11757916>Greg Clayton2012-08-291-1/+3
| | | | | | | | | | | | 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
* Also push file & line breakpoints past the prologue. Also added a "-K" ↵Jim Ingham2012-05-221-3/+30
| | | | | | | | | | | argument to the relevant "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
* <rdar://problem/11282938>Greg Clayton2012-04-231-2/+5
| | | | | | Fixed an issue where we get NULL compile units back from the symbol vendor. We need symbol vendors to be able to quickly give an estimate of the compile units that they have without having to fully vette them first, so anyone getting compile units from a module should be able to deal with a NULL compile unit being returned for a given index. llvm-svn: 155398
* Don't set breakpoints independently comp unit by comp unit, but look over ↵Jim Ingham2012-01-131-42/+108
| | | | | | | | | all the file & line matches and only pick the "best" ones. <rdar://problem/10685990> llvm-svn: 148087
* Add a new breakpoint type "break by source regular expression".Jim Ingham2011-09-211-5/+15
| | | | | | | | | Fix the RegularExpression class so it has a real copy constructor. Fix the breakpoint setting with multiple shared libraries so it makes one breakpoint not one per shared library. Add SBFileSpecList, to be used to expose the above to the SB interface (not done yet.) llvm-svn: 140225
* Modified all logging calls to hand out shared pointers to make sure weGreg Clayton2010-11-061-1/+1
| | | | | | | | | | | don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
* Check in an initial implementation of the "breakpoint clear" command, whose ↵Johnny Chen2010-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | purpose is clear the breakpoint associated with the (filename, line_number) combo when an arrow is pointing to a source position using Emacs Grand Unified Debugger library to interact with lldb. The current implmentation is insufficient in that it only asks the breakpoint whether it is associated with a breakpoint resolver with FileLine type and whether it matches the (filename, line_number) combo. There are other breakpoint resolver types whose breakpoint locations can potentially match the (filename, line_number) combo. The BreakpointResolver, BreakpointResolverName, BreakpointResolverAddress, and BreakpointResolverFileLine classes have extra static classof methods to support LLVM style type inquiry through isa, cast, and dyn_cast. The Breakpoint class has an API method bool GetMatchingFileLine(...) which is invoked from CommandObjectBreak.cpp to implement the "breakpoint clear" command. llvm-svn: 117562
* Merged Eli Friedman's linux build changes where he added Makefile files thatGreg Clayton2010-07-091-1/+1
| | | | | | | 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
* Added function name types to allow us to set breakpoints by name moreGreg Clayton2010-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+122
llvm-svn: 105619
OpenPOWER on IntegriCloud