Summary:
http://llvm.org/bugs/show_bug.cgi?id=20400
The default triple of i686-pc-linux-gnu for 32 bit linux targets is compatible
but not necessarily identical to the inferior binaries.
Applying Azat Khuzhin's solution of using ArchSpec::IsCompatibleMatch() instead
of ArchSpec::IsExactMatch() when comparing ObjectFile and Modules architecture.
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7897
llvm-svn: 230694
Summary:
They'll be set anyway when the thread starts running, so the launching threads
should just ignore the set request.
Reviewers: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7914
llvm-svn: 230671
When we have a debug map we have an executable with a bunch of STAB symbols and each source file has a N_SO symbol which scopes a bunch of symbols inside of it. We can use this to our advantage here when looking for the complete definition of an objective C class by looking for a symbol whose name matches the class name and whose type is eSymbolTypeObjCClass. If we find one, that symbol will be contained within a N_SO symbol. This symbol gets turned into a symbol whose type is eSymbolTypeSourceFile and that symbol will contain the eSymbolTypeObjCClass which helps us to locate the correct .o file and allows us to only look in that file.
To further accelerate things, if we are looking for the implementation, we can avoid looking at all .o files if we don't find a matching symbol because we have a debug map, which means the objective C symbol for the class can't have been stripped, so we can safely not search all remaining .o files. This will save us lots of time when trying to look for "NSObject" and any other AppKit and Foundation classes that we never have implementation definitions for.
<rdar://problem/19234225>
llvm-svn: 230562
The DebuggerThread was detecting the launch error, but it was
ignored by ProcessWindows::DoLaunch, causing LLDB to wait forever
in the debugger loop.
This fixes the test case that explicitly attempts to launch a
process from a non-existant path.
Patch by Adrian McCarthy
Differential Revision: http://reviews.llvm.org/D7874
llvm-svn: 230523
Earlier this week I was able to get clang-cl on Windows to be
able to self host. This opened the door to being able to
get a whole new slew of warnings for the Windows build.
This patch fixes all of the warnings, many of which were real
bugs.
llvm-svn: 230522
ExecutionContext::GetAddressByteSize() was calling GettAddressByteSize () on Target and Process class but was ignoring the return type. I have added the missing return.
No regression in the test suite. Committed as obvious.
llvm-svn: 230502
Add O_TRUNC when opening file for redirecting stdout and stderr of the
process. It is neccessary because if the file exists then on some
platform the original content is kept while it isn't overwritten by the
new data causing pollution of the saved stdout and stderr.
llvm-svn: 230492
Summary:
Symbols::LocateExecutableSymbolFile tries to locate the file in containing the debug info in a
splitdebug configuration. It tries to skip over the original file in its search path, but it was
easily fooled by symlinks. This changes the function to use llvm::sys::fs::equivalent, which can
correctly compare symlinks.
As a side effect, I had to fix one test because the address for the "abort" function resolves on
my system to "__GI_abort" now. With the debug info, the libc on my system contains two symbols
associated with the address of the abort function, and lldb prefers __GI_abort, possibly because
the debug info is associated with it. It would be nice at some point to have it prefer the public
symbol name.
Reviewers: emaste, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7836
llvm-svn: 230476
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
Fix this by returning the fact that the "symbols" word is complete if there is nothing else to complete after the "symbols" word.
<rdar://problem/19164599>
llvm-svn: 230408
This resubmits r230380. The primary cause of the failure was
actually just a warning, which we can disable at the CMake level
in a followup patch on the LLVM side. The other thing which was
actually an error on the bot should be able to be fixed with
a clean.
llvm-svn: 230389
An OBJECT library is a special type of CMake library that produces
no archive, has no link interface, and no link inputs. It is like
a regular archive, just without the physical output. To link
against an OBJECT library, you reference it in the *source* file
list of a library using the special syntax $<TARGET_OBJECTS:lldbAPI>.
This will cause every object file to be passed to the linker
independently, as opposed to a single archive being passed to the
linker.
This is *extremely* important on Windows. lldbAPI exports all of the
SB classes using __declspec(dllexport). Unfortunately for technical
reasons it is not possible (well, extremely difficult) to get the
linker to propagate a __declspec(dllexport) attribute from a symbol
in an object file in an archive to a DLL that links against that
archive. The solution to this is for the DLL to link the object files
directly. So lldbAPI must be an OBJECT library.
This fixes an issue that has been present since the duplicated
lldbAPI file lists were removed, which would cause linker failures.
As a side effect, this also makes LLDB_DISABLE_PYTHON=1 work again
on Windows, which was previously totally broken.
llvm-svn: 230380
This new class makes it easier to change the timeout of a
GDBRemoteCommunication instance for a short time and then restore it to
its original value.
Differential revision: http://reviews.llvm.org/D7826
llvm-svn: 230319
Also, since most of the time the lack of such information is a serious problem that hinders productive debugging, emit an actual user visible warning when this occurs (once per process)
Fixes rdar://19898507
llvm-svn: 230299
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
Embedding python with MSVC is very finicky, for reasons having
to do with the operating system's CRT, the implementation of
python itself on Windows, and even bugs in CMake.
One side effect of this is that we cannot rely on FindPythonLibs
and FindPythonInterp CMake functions to locate the correct
version of Python. We must instead manually specify the location
of PYTHON_LIBRARY and PYTHON_INCLUDE_DIR.
As a side effect, this fixes building LLDB in release mode by
specifying -DCMAKE_BUILD_TYPE=Release, which was previously
broken.
llvm-svn: 230262
This makes these failures slightly more obvious, avoiding the need to
run LLDB under a debugger or rely on a LLDB core. I encountered these
while bringing up a new OS/arch combination.
llvm-svn: 230236
With the previous implementation the protocol used by the client and the
server for the response was different and worked only by an accident.
With this change the communication is fixed and the return code from
mkdir and chmod correctly captured by lldb. The change also add
documentation for the qPlatform__[mkdir,chmod] packages.
Differential revision: http://reviews.llvm.org/D7786
llvm-svn: 230213
Process::Launch try to catch a stop signal after launching a process. If
it is unsuccessful it destroy the process but previously still reported
that the process launched successfully. This behavior caused a
deadlock. With thic change the process launch error reported correctly.
Differential revision: http://reviews.llvm.org/D7784
llvm-svn: 230212
Summary:
This patch enables evaluation of DWARF expressions setting the CFA during stack unwinding.
This makes TestSigtrampUnwind "almost" pass on linux. I am not enabling the test yet since the
symbol name for the signal trampoline does not get resolved properly due to a different bug, but
apart from that, the backtrace is sane.
I am unsure how this change affects Mac. I think it makes the unwinder prefer the DWARF unwind
plan instead of some custom platform-dependant plan. However, it does not affect the end result
- the stack unwinding works as expected.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7792
llvm-svn: 230211
Summary:
This change refactors UnwindPlan::Row to be able to store the fact that the CFA is value is set
by evaluating a dwarf expression (DW_CFA_def_cfa_expression). This is achieved by creating a new
class CFAValue and moving all CFA setting/getting code there. Note that code using the new
CFAValue::isDWARFExpression is not yet present and will be added in a follow-up patch. Therefore,
this patch should not change the functionality in any way.
Test Plan: Ran tests on Mac and Linux. No regressions detected.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7755
llvm-svn: 230210
const, there was never a need for lookup_const_result. Now that vestigal
type is gone, so switch LLDB to lookup_result and to use the
DeclContextLookupResult rather than the Const variant.
llvm-svn: 230126
- Add Host::GlobArguments() to perform local-globbing
I implemented this on OSX and Windows in terms of argdumper (Windows implementation is essentially the same as the OSX version + a change in binary name and some string magic)
Other platforms did not specifically chime in, so I left it unimplemented for them for the time being. Please feel free to fill in the blanks
- Add Platform::GlobArguments() to support remote-globbing
For now, no feature change here - but now we have infrastructure to help GDBRemote targets to support globbing - and patches to that effect will follow
No visible feature change
llvm-svn: 230065
Chaoren Lin