| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
environment and that might not always be set. Our FileSpec class uses this function to resolve any paths that start with "~/" on systems that support home directories as '~'. I have modified FileSpec::ResolveUsername (llvm::SmallVectorImpl<char> &path) to deal with the cases where llvm::sys::path::home_directory() returns false by digging a little further on unix systems and setting "HOME" in the environment so that subsequent calls to llvm::sys::path::home_directory() will succeed.
I also added a test to ensure we don't regress.
<rdar://problem/25342377>
llvm-svn: 266832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed
needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with
backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a
problem because we would consider paths with different separators as different (which led to
unresolved breakpoints for instance).
Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I
am commenting out the GetDirectory unittests until we figure out the what is the expected
behaviour here.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19060
llvm-svn: 266286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Even though FileSpec attempted to handle both kinds of path syntaxes (posix and windows) on both
platforms, it relied on the llvm path library to do its work, whose behavior differed on
different platforms. This led to subtle differences in FileSpec behavior between platforms. This
replaces the pieces of the llvm library with our own implementations. The functions are simply
copied from llvm, with #ifdefs replaced by runtime checks for ePathSyntaxWindows.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18689
llvm-svn: 265299
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and
handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior.
Summary of changes:
FileSpec("/bar").GetCString(): before "//bar", after "/bar".
FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar".
FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar".
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18044
llvm-svn: 263207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Paths on Windows are not case-sensitive. Because of this, if a file
is called main.cpp, you should be able to set a breakpoint on it
by using the name Main.cpp. In an ideal world, you could just
tell people to match the case, but in practice this can be a real
problem as it requires you to know whether the person who compiled
the program ran "clang++ main.cpp" or "clang++ Main.cpp", both of
which would work, regardless of what the file was actually called.
This fixes http://llvm.org/pr22667
Patch by Petr Hons
Differential Revision: http://reviews.llvm.org/D17492
Reviewed by: zturner
llvm-svn: 261771
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the path if m_filename is set to exactly '.'. Previously this would cause a FileSpec object that looked like:
m_directory = "/tmp"
m_filename = "."
To look like:
m_directory = "/tmp/."
m_filename = "foo.txt"
if "foo.txt" was appended to it. With this fix it will be:
m_directory = "/tmp"
m_filename = "foo.txt"
llvm-svn: 250770
|
|
|
|
|
|
|
|
| |
zturner!
http://reviews.llvm.org/D12984
llvm-svn: 248055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use the symbolic link to resolver to find the target of the LLDB shlib
symlink if there is a symlink. This allows us to find shlib-relative resources
even when running under the testsuite, where _lldb.so is a symlink in the Python
resource directory.
Also changed a comment to be slightly more clear about what resolve_path in the
constructor for FileSpec means, since if we were actually using realpath() this
code wouldn't have been necessary.
http://reviews.llvm.org/D12984
llvm-svn: 248048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When calling find_first_of and find_last_of on a single character,
we can instead just call find / rfind and make our intent more
clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12518
llvm-svn: 246609
|
|
|
|
|
|
| |
http://reviews.llvm.org/D11356
llvm-svn: 242753
|
|
|
|
|
|
| |
Windows build was broken in either r240983 or r240978 in the changes to FileSpec.cpp
llvm-svn: 241071
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10811
llvm-svn: 240983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in FileSystem::DeleteDirectory(...).
Fixes include:
- use FileSystem::Unlink() instead of a direct call to ::unlink(...) when deleting files when iterating through the current directory
- save directories from current directory in a list and iterate through those _after_ the current directory has been iterated
- Use new FileSpec::ForEachItemInDirectory() instead of manually iterating across directories with opendir()/readdir()/closedir()
We should switch all code over to using FileSpec::ForEachItemInDirectory(...) in the near future and get rid of FileSpec::EnumerateDirectory().
This is a follow up patch to:
http://reviews.llvm.org/D10787
llvm-svn: 240978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`IsRelativeToCurrentWorkingDirectory` was misleading, because relative paths
are sometimes appended to other directories, not just the cwd. Plus, the new
name is shorter. Also added `IsAbsolute` for completeness.
Reviewers: clayborg, ovyalov
Reviewed By: ovyalov
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10262
llvm-svn: 239419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Added PrependPathComponent utility functions to FileSpec.
- Delegate path operations in ParseCompileUnit to FileSpec.
- Delegate path operations in ParseSupportFiles to FileSpec.
Reviewers: clayborg, vharron, ovyalov
Reviewed By: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10253
llvm-svn: 239127
|
|
|
|
|
|
|
|
| |
use @rpath.
<rdar://problem/8371885>
llvm-svn: 238886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D9728.
Reviewers: ovyalov, zturner, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9806
llvm-svn: 238605
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix FileSpec::Dump() to output denormalized path.
See D9942 for previous discussions.
Reviewers: zturner
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10077
llvm-svn: 238440
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: domipheus, ovyalov
Reviewed By: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9862
llvm-svn: 237741
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ovyalov, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9579
llvm-svn: 236925
|
|
|
|
|
|
|
|
|
|
|
| |
/private/tmp/main.cpp
/private/tmp/..//tmp/main.cpp
We saw paths like this in makefile generate binaries when someone left an extra '/' on the end of a makefile variable.
<rdar://problem/18945972>
llvm-svn: 236541
|
|
|
|
|
|
|
|
|
|
| |
Previously, users on Windows had to manually specify PYTHONPATH
to point to the site-packages directory before running LLDB.
The reason for this was because sys.path was being initialized
with a path containing unescaped backslashes, causing escape
sequences to end up in the paths.
llvm-svn: 234516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before this fix the FileSpec::GetPath() returned string which might be without '\0' at the end.
It could have happened if the size of buffer for path was less than actual path.
Test case:
```
FileSpec test("/path/to/file", false);
char buf[]="!!!!!!";
test.GetPath(buf, 3);
```
Before fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/pa!!!"
```
After fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/p"
```
Reviewers: zturner, abidh, clayborg
Reviewed By: abidh, clayborg
Subscribers: tberghammer, vharron, lldb-commits, clayborg, zturner, abidh
Differential Revision: http://reviews.llvm.org/D7553
llvm-svn: 230787
|
|
|
|
|
|
|
|
|
|
|
| |
and llvm::sys::fs::make_absolute prepends the current
working directory to that path, leave the original
bare file name unchanged if $cwd/ls doesn't exist.
http://reviews.llvm.org/D7477
<rdar://problem/18775190>
llvm-svn: 230451
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is implemented by making a new FileSystem function:
bool
FileSystem::IsLocal(const FileSpec &spec)
Then using this in a new function:
DataBufferSP
FileSpec::MemoryMapFileContentsIfLocal(off_t file_offset, size_t file_size) const;
This function only mmaps data if the file is a local file since that means we can reliably page in data. We were experiencing crashes where people would use debug info files on network mounted file systems and that mount would go away and cause the next access to a page that wasn't paged in to crash LLDB.
We now avoid this by just copying the data into a heap buffer and keeping a permanent copy to avoid the crash. Updated all previous users of FileSpec::MemoryMapFileContentsIfLocal() in ObjectFile subclasses over to use the new FileSpec::MemoryMapFileContentsIfLocal() function.
<rdar://problem/19470249>
llvm-svn: 230283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some time, eclipse (CDT) uses full path of the file in break-insert command
when putting breakpoint on a source line. On windows, a typical command looks
like the following.
56-break-insert -f F:\\work\\ws\\test\\main.c:49
Current implementation in lldb-mi have problem in 2 ways.
1. It was assuming that there will be only one : in the path which is wrong if full
path is supplied.
2. CDT sends out path with double backslashes in windows which gives error on
resolution.
Fixed the : issue in lldb-mi. Changed FileSpec::Normalize to make sure that it
handles the path with \\ correctly. Added test cases to check for full path in
both lldb-mi and lldb. Also added a test case to check SBFileSpec with double
slashes.
llvm-svn: 228538
|
|
|
|
|
|
|
|
|
|
| |
specify compile and execute flags for regular expressions. Also enable better regular expressions if they are available by check if the REG_ENHANCED is available and using it if it is.
Since REG_ENHANCED is available on MacOSX, this allow the use of \d (digits) \b (word boundaries) and much more without affecting other systems.
<rdar://problem/12082562>
llvm-svn: 226704
|
|
|
|
|
|
|
|
| |
so it doesn't assume that the SmallVector<char> will have
nul terminator. It did not in at least one case.
Caught by ASAN instrumentation.
llvm-svn: 226544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a resubmit of r223548, which was reverted due to breaking
tests on Linux and Mac.
This resubmit fixes the reason for the revert by adding back some
accidentally removed code which appends -c to the command line
when running /bin/sh.
This resubmit also differs from the original patch in that it sets
the architecture on the ProcessLaunchInfo. A follow-up patch will
refactor this to separate the logic for different platforms.
Differential Revision: http://reviews.llvm.org/D6553
Reviewed By: Greg Clayton
llvm-svn: 223695
|
|
|
|
| |
llvm-svn: 223568
|
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D6553
Reviewed By: Greg Clayton
llvm-svn: 223548
|
|
|
|
|
|
|
| |
Normalizing paths before resolving them can cause the path to
become denormalized after resolution.
llvm-svn: 223087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
relative paths, like:
/whatever/llvm/lib/Sema/../../include/llvm/Sema/
That causes problems with our type uniquing, since we use the declaration file
and line as one component of the uniquing, and different ways of getting to the
same file will have different directory spellings, though they are functionally
equivalent. We end up with two copies of the exact same type because of this,
and that makes the expression parser give "duplicate type" errors.
I added a method to resolve paths with ../ in them and used that in the FileSpec::Equals,
for comparing Declarations and for doing Breakpoint compares as well, since they also
suffer from this if you specify breakpoints by full path (since nobody knows what
../'s to insert...)
<rdar://problem/18765814>
llvm-svn: 222075
|
|
|
|
| |
llvm-svn: 221286
|
|
|
|
|
|
|
| |
constructors.
clang static analyzer fixit.
llvm-svn: 219768
|
|
|
|
|
|
|
| |
current user, and ResolvePartialUsername will resolve "~" to the list of
users.
llvm-svn: 217723
|
|
|
|
|
|
| |
This gets the file completer for absolute paths working again.
llvm-svn: 217722
|
|
|
|
|
|
|
| |
anyway /Vol doesn't complete correctly either. Somehow we're chopping the names
up incorrectly before passing them into the completer.
llvm-svn: 217720
|
|
|
|
|
|
|
|
| |
"~/". This
gets command-line file completion from ~ working again.
llvm-svn: 217719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More specifically, this change can be summarized as follows:
1) Makes an lldbHostPosix library which contains code common to
all posix platforms.
2) Creates Host/FileSystem.h which defines a common FileSystem
interface.
3) Implements FileSystem.h in Host/windows and Host/posix.
4) Creates Host/FileCache.h, implemented in Host/common, which
defines a class useful for storing handles to open files needed
by the debugger.
Differential Revision: http://reviews.llvm.org/D4889
llvm-svn: 215775
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes include:
1 - added new FileSpec method: bool FileSpec::Readable()
2 - detect when an executable is not readable and give an appropriate error for:
(lldb) file /tmp/unreadablefile
3 - detect when a core file is not readable and give an appropriate error
4 - detect when a specified core file doesn't exist and give an appropriate error
<rdar://problem/17727734>
llvm-svn: 215741
|
|
|
|
|
|
| |
Remove unused static function identified by GCC 4.8.2.
llvm-svn: 215300
|
|
|
|
| |
llvm-svn: 215262
|
|
|
|
| |
llvm-svn: 215124
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the notion of a "path syntax" to FileSpec. There
are two syntaxes (Posix and Windows) and one "meta syntax",
Host Native, which uses the current platform to figure out the
appropriate syntax for host paths.
This allows paths from one platform to be represented and
manipulated on another platform even if they have different path
syntaxes.
llvm-svn: 215123
|
|
|
|
| |
llvm-svn: 212132
|
|
|
|
|
|
|
|
|
|
| |
are not thread safe.
I switched the lldb_private::FileSpec code over to use "llvm::StringRef llvm::sys::path::filename(llvm::StringRef)" for basename() and "llvm::StringRef llvm::sys::path::parent_path(llvm::StringRef)" for dirname().
<rdar://problem/16870083>
llvm-svn: 209917
|