summaryrefslogtreecommitdiff
path: root/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
AgeCommit message (Collapse)Author
2025-11-20[lldb] Eliminate SupportFileSP nullptr derefs (#168624)Jonas Devlieghere
This patch fixes and eliminates the possibility of SupportFileSP ever being nullptr. The support file was originally treated like a value type, but became a polymorphic type and therefore has to be stored and passed around as a pointer. To avoid having all the callers check the validity of the pointer, I introduced the invariant that SupportFileSP is never null and always default constructed. However, without enforcement at the type level, that's fragile and indeed, we already identified two crashes where someone accidentally broke that invariant. This PR introduces a NonNullSharedPtr to prevent that. NonNullSharedPtr is a smart pointer wrapper around std::shared_ptr that guarantees the pointer is never null. If default-constructed, it creates a default-constructed instance of the contained type. Note that I'm using private inheritance because you shouldn't inherit from standard library classes due to the lack of virtual destructor. So while the new abstraction looks like a `std::shared_ptr`, it is in fact **not** a shared pointer. Given that our destructor is trivial, we could use public inheritance, but currently there's no need for it. rdar://164989579
2024-11-13[lldb] Fix source display for artificial locations (#115876)Pavel Labath
When retrieving the location of the function declaration, we were dropping the file component on the floor, which resulted in an amusingly confusing situation were we displayed the file containing the implementation of the function, but used the line number of the declaration. This patch fixes that. It required a small refactor Function::GetStartLineSourceLineInfo to return a SupportFile (instead of just the file spec), which in turn necessitated changes in a couple of other places as well.
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl
This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ` ResultTy DoFoo(Status& error) ` to ` llvm::Expected<ResultTy> DoFoo() ` How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly ` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) ` plus the occasional manual cleanup.
2024-08-15[lldb] Realpath symlinks for breakpoints (#102223)royitaqi
Improve the chance of resolving file/line breakpoints by realpath'ing the support files before doing a second match attempt, with some conditions applied. A working [hello-world example](https://github.com/royitaqi/lldb_demos/blob/main/realpath/README.md). See [patch](https://github.com/llvm/llvm-project/pull/102223) for more info about problem/motivation, details of the feature, new settings, telemetries and tests.
2024-05-23[lldb][Windows] Fixed the TestBreakpointCommand test (#93122)Dmitry Vasilyev
The TestBreakpointCommand test is incorrectly disabled for Windows target. We can disable it for Windows host instead or just fix the issue. This patch fixes the path separator in BreakpointResolverFileLine::DeduceSourceMapping() and the Windows specific absolute path in the test in case of the Windows host.
2024-03-21[lldb] Reland: Store SupportFile in FileEntry (NFC) (#85892)Jonas Devlieghere
This is another step towards supporting DWARF5 checksums and inline source code in LLDB. This is a reland of #85468 but without the functional change of storing the support file from the line table (yet).
2024-03-19Revert "[lldb] Store SupportFile in FileEntry (NFC)" (#85885)Jonas Devlieghere
Reverts llvm/llvm-project#85468 because @slackito reports this broke stepping in one of their tests [1] and this patch was meant to be NFC. [1] https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120
2024-03-15[lldb] Store SupportFile in FileEntry (NFC) (#85468)Jonas Devlieghere
This is another step towards supporting DWARF5 checksums and inline source code in LLDB.
2023-12-16[lldb] Use StringRef::{starts,ends}_with (NFC)Kazu Hirata
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-15[lldb][NFCI] Remove unused parameter from ↵Alex Langford
BreakpointResolver*::CreateFromStructuredData (#75374) These appear to be unused.
2023-11-07[lldb] BreakpointResolver{*}::CreateFromStructuredData should return shared ↵Alex Langford
pointers (#71477) BreakpointResolver::CreateFromStructuredData returns a BreakpointResolverSP, but all of the subclasses return raw pointers. Instead of creating a raw pointer and shoving it into a shared pointer, it seems reasonable to just create the shared pointer directly.
2023-05-05Re-land "[lldb] Expose a const iterator for SymbolContextList"Alex Langford
Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications to fix tests. I originally reverted this because it caused a test to fail on Linux. The problem was that I inverted a condition on accident.
2023-05-04Revert "[lldb] Expose a const iterator for SymbolContextList"Alex Langford
This reverts commit 04aa943be8ed5c03092e2a90112ac638360ec253. This broke the debian buildbot and I'm not sure why. Reverting so I can investigate.
2023-05-04[lldb] Expose a const iterator for SymbolContextListAlex Langford
There are many situations where we'll iterate over a SymbolContextList with the pattern: ``` SymbolContextList sc_list; // Fill in sc_list here for (auto i = 0; i < sc_list.GetSize(); i++) { SymbolContext sc; sc_list.GetSymbolAtContext(i, sc); // Do work with sc } ``` Adding an iterator to iterate over the instances directly means we don't have to do bounds checking or create a copy of every element of the SymbolContextList. Differential Revision: https://reviews.llvm.org/D149900
2023-01-07[lldb] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-07[lldb] Add #include <optional> (NFC)Kazu Hirata
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-17[lldb] llvm::Optional::value => operator*/operator->Fangrui Song
std::optional::value() has undesired exception checking semantics and is unavailable in some older Xcode. The call sites block std::optional migration.
2022-12-04[lldb] Use std::nullopt instead of None in comments (NFC)Kazu Hirata
This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-04[lldb] Use std::nullopt instead of None (NFC)Kazu Hirata
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-09-23[lldb] Use Optional::{has_value,value,value_or}Kazu Hirata
2022-09-22Add auto source map deduce count statisticsJeffrey Tan
This patch adds auto source map deduce count as a target level statistics. This will help telemetry to track how many debug sessions benefit from this feature. Differential Revision: https://reviews.llvm.org/D134483
2022-09-19Add auto deduce source map settingJeffrey Tan
This patch adds a new "target.auto-source-map-relative" setting. If enabled, this setting may auto deduce a source map entry based on requested breakpoint path and the original path stored in debug info for resolved breakpoint. As an example, if debug info contains "./a/b/c/main.cpp", user sets a source breakpoint at "/root/repo/x/y/z/a/b/c/main.cpp". The breakpoint will resolve correctly now with Greg's patch https://reviews.llvm.org/D130401. However, the resolved breakpoint will use "./a/b/c/main.cpp" to locate source file during stop event which would fail most of the time. With the new "target.auto-source-map-relative" setting enabled, a auto deduced source map entry "." => "/root/repo/x/y/z" will be added. This new mapping will help lldb to map resolved breakpoint path "./a/b/c/main.cpp" back to "/root/repo/x/y/z/a/b/c/main.cpp" and locate it on disk. If an existing source map entry is used the patch also concatenates the auto deduced entry with any stripped reverse mapping prefix (see example below). As a second example, debug info contains "./a/b/c/main.cpp" and user sets breakpoint at "/root/repo/x/y/z/a/b/c/main.cpp". Let's say there is an existing source map entry "." => "/root/repo"; this mapping would strip the prefix out of "/root/repo/x/y/z/a/b/c/main.cpp" and use "x/y/z/a/b/c/main.cpp" to resolve breakpoint. "target.auto-source-map-relative" setting would auto deduce a new potential mapping of "." => "x/y/z", then it detects that there is a stripped prefix from reverse mapping and concatenates it as the new mapping: "." => "/root/repo/x/y/z" which would correct map "./a/b/c/main.cpp" path to new path in disk. This patches depends on https://reviews.llvm.org/D130401 to use new added SBDebugger::GetSetting() API for testing. Differential Revision: https://reviews.llvm.org/D133042
2022-08-08Implement better path matching in FileSpecList::FindCompatibleIndex(...).Greg Clayton
Currently a FileSpecList::FindFileIndex(...) will only match the specified FileSpec if: - it has filename and directory and both match exactly - if has a filename only and any filename in the list matches Because of this, we modify our breakpoint resolving so it can handle relative paths by doing some extra code that removes the directory from the FileSpec when searching if the path is relative. This patch is intended to fix breakpoints so they work as users expect them to by adding the following features: - allow matches to relative paths in the file list to match as long as the relative path is at the end of the specified path at valid directory delimiters - allow matches to paths to match if the specified path is relative and shorter than the file paths in the list This allows us to remove the extra logic from BreakpointResolverFileLine.cpp that added support for setting breakpoints with relative paths. This means we can still set breakpoints with relative paths when the debug info contains full paths. We add the ability to set breakpoints with full paths when the debug info contains relative paths. Debug info contains "./a/b/c/main.cpp", the following will set breakpoints successfully: - /build/a/b/c/main.cpp - a/b/c/main.cpp - b/c/main.cpp - c/main.cpp - main.cpp - ./c/main.cpp - ./a/b/c/main.cpp - ./b/c/main.cpp - ./main.cpp This also ensures that we won't match partial directory names, if a relative path is in the list or is used for the match, things must match at the directory level. The breakpoint resolving code will now use the new FileSpecList::FindCompatibleIndex(...) function to allow this fuzzy matching to work for breakpoints. Differential Revision: https://reviews.llvm.org/D130401
2022-07-28[NFC] Improve FileSpec internal APIs and usage in preparation for adding ↵Greg Clayton
caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-23Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for ↵Nico Weber
adding caching of resolved/absolute." and follow-ups This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d. It broke the build on Windows, see comments on https://reviews.llvm.org/D130309 It also reverts these follow-ups: Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14. Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24. Revert "Cache the value for absolute path in FileSpec." This reverts commit dabe877248b85b34878e75d5510339325ee087d0.
2022-07-22[NFC] Improve FileSpec internal APIs and usage in preparation for adding ↵Greg Clayton
caching of resolved/absolute. The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130309
2022-06-19[lldb] Use value_or instead of getValueOr (NFC)Kazu Hirata
2022-02-03[lldb] Rename Logging.h to LLDBLog.h and clean up includesPavel Labath
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
2022-02-02[lldb] Convert "LLDB" log channel to the new APIPavel Labath
2021-07-29[source map] fix relative path breakpointsWalter Erquinigo
https://reviews.llvm.org/D45592 added a nice feature to be able to specify a breakpoint by a relative path. E.g. passing foo.cpp or bar/foo.cpp or zaz/bar/foo.cpp is fine. However, https://reviews.llvm.org/D68671 by mistake disabled the test that ensured this functionality works. With time, someone made a small mistake and fully broke the functionality. So, I'm making a very simple fix and the test passes. Differential Revision: https://reviews.llvm.org/D107126
2021-05-04[lldb] Refactor argument group by SourceLocationSpec (NFCI)Med Ismail Bennani
This patch refactors a good part of the code base turning the usual FileSpec, Line, Column, CheckInlines, ExactMatch arguments into a SourceLocationSpec object. This change is required for a following patch that will add handling of the column line information when doing symbol resolution. Differential Revision: https://reviews.llvm.org/D100965 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-01-20Fix a bug with setting breakpoints on C++11 inline initialization statements.Jim Ingham
If they occurred before the constructor that used them, we would refuse to set the breakpoint because we thought they were crossing function boundaries. Differential Revision: https://reviews.llvm.org/D94846
2020-03-04[lldb] Make BreakpointResolver hold weak_ptr instead of raw pointer to ↵Tatyana Krasnukha
breakpoint This prevents calling Breakpoint::shared_from_this of an object that is not owned by any shared_ptr. Differential Revision: https://reviews.llvm.org/D74557
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2019-10-10[lldb][NFC] Remove strange bool parameter from Searcher::SearchCallbackRaphael Isemann
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
2019-05-23[lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine
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
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere
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-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-11-11Remove header grouping comments.Jonas Devlieghere
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-01[FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere
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
2018-09-07NFC: Move Searcher::Depth into lldb-enumerations as SearchDepth.Jim Ingham
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
2018-08-30Support setting a breakpoint by FileSpec+Line+Column in the SBAPI.Adrian Prantl
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
2018-08-07If a function starts with line number 0, don't try to check if a breakpoint ↵Jim Ingham
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
2018-04-30Reflow paragraphs in comments.Adrian Prantl
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-27Always normalize FileSpec paths.Greg Clayton
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
2018-04-13Allow relative file paths when settings source breakpointsGreg Clayton
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
2017-05-12Update StructuredData::String to return StringRefs.Zachary Turner
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
2017-05-12Rename Error -> Status.Zachary Turner
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
2017-03-15BreakpointResolverFileLine: Restrict move-to-nearest-code from moving across ↵Pavel Labath
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
2017-03-03Move Log from Core -> Utility.Zachary Turner
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