have a certain name, not just the first. This
is useful if a class method and an instance
method have the same name.
<rdar://problem/14872081>
llvm-svn: 190008
by appending the thread ID to the test packet when
debugserver requires it.
This allows register writing (and, by extension,
expressions) to work on Mac OS X.
llvm-svn: 190007
Added "mach_o.py" which is a mach-o parser that can dump mach-o file contents and also extract sections. It uses the "file_extract" module and the "dict_utils" module.
llvm-svn: 189959
Instead of directly manipulating the thread list in Launch and Attach,
just rely on RefreshStateAfterStop to populate the initial list.
Review: http://llvm-reviews.chandlerc.com/D1565
llvm-svn: 189889
/bin/sh is more portable, and all systems with /bin/bash are expected to
have /bin/sh as well, even if only a link to bash.
Review: http://llvm-reviews.chandlerc.com/D1576
llvm-svn: 189879
A FreeBSD implementation of Host::FindProcesses was added in r189295.
Contrary to my earlier report of failing tests it seems all attach by
name tests now pass.
http://www.llvm.org/pr16699
llvm-svn: 189680
A FreeBSD implementation of Host::FindProcesses was added in r189295.
Note that some tests still fail as the implementation returns a truncated
name for processes with long names.
http://www.llvm.org/pr16699
llvm-svn: 189667
On Linux there is no separate notion of a process (vs. a thread) for
ptrace(); each thread needs to be individually detached. On FreeBSD
we have a separate process context, and we detach just it.
Review: http://llvm-reviews.chandlerc.com/D1418
llvm-svn: 189666
Testing shows it works for at least trivial cases, while the
USE_STANDARD_JIT case does not even work for those. Thus, don't define
USE_STANDARD_JIT on FreeBSD.
I've left the #if block choosing the appropriate #include in case it's
useful for testing.
llvm-svn: 189611
Some stubs only support g/G packets for registers.
This change makes sure that we check if remote stub supports 'p' packet before using it.
llvm-svn: 189576
- add default timeout of 10s (unil qPlatform_RunCommand supports timeout packets and CommandObjectPlatform is updated to read a timeout flag/setting)
- add a few tests for platform shell
llvm-svn: 189405
- move LaunchProcessPosixSpawn() and Host::LaunchProcess() from freebsd host plugin to common (linux/freebsd section)
- modify MonitorChildProcessThreadFunction to use pid_t from sys/types.h to avoid Linux/FreeBSD/Mac warnings when calling waitpid()
llvm-svn: 189404
- mode_t is defined in <sys/types.h>
- reorganized S_* user rights into win32.h
- Use Host::Kill instead of kill
- Currently #ifdef functions using pread/pwrite.
llvm-svn: 189364
Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix
LLDB to use the new names. While I was here, I decided that a COFF
plugin really shouldn't be using Mach-O enums.
llvm-svn: 189316
should not split up that pathname itself or require quoting to avoid the same.
This fixing a bug where target create -c "core file" or target create -s "symbol file"
will fail with an error message that the paths haven't been properly quoted. Working
around it required target create -c "core\ file" to survive both attemps at tokenizing.
<rdar://problem/14230629>
llvm-svn: 189313
out of a binary, if the Mach-O binary is MH_PRELOAD ("standalone"), don't
let the OS be set to "ios" or "macosx" - there will be no dynamic loader
used when debugging this process.
<rdar://problem/9956443>
llvm-svn: 189305
Summary:
This merge brings in the improved 'platform' command that knows how to
interface with remote machines; that is, query OS/kernel information, push
and pull files, run shell commands, etc... and implementation for the new
communication packets that back that interface, at least on Darwin based
operating systems via the POSIXPlatform class. Linux support is coming soon.
Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
X Mountain Lion.
Additional improvements (not in the source SVN branch 'lldb-platform-work'):
- cmake build scripts for lldb-platform
- cleanup test suite
- documentation stub for qPlatform_RunCommand
- use log class instead of printf() directly
- reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
- add new logging category 'platform'
Reviewers: Matt Kopec, Greg Clayton
Review: http://llvm-reviews.chandlerc.com/D1493
llvm-svn: 189295
live beyont parsing. This is important because
all the ClangASTImporter::Minions for a parser's
ASTContext are cleared when ClangExpressionDeclMap
is deleted.
This resolves many hard-to-reproduce crashes,
especially ones involving breakpoint conditions.
<rdar://problem/14775391>
llvm-svn: 189080
This means that "register read stmm0 --format f" actually works now.
This is a little messy but LLDB assumes 'long double' is portable, when it is not.
llvm-svn: 188698
address.
When loading a dSYM, and the file addresses of the dSYM Sections are
different than the executable binary Sections' file addresses, the
debug info won't be remapped to the actual load addresses correctly.
This only happens with binaries on the in-memory shared cache binaries
where their File addresses have been set to their actual load address
(outside an offset value) whereas the original executable and dSYM
have 0-based File addresses.
I think this patch will not be activated for other cases -- this is
the only case we know of where the dSYM and the executable's File
addresses differ -- but if this causes other problems we can restrict
it more carefully.
<rdar://problem/12335086>
llvm-svn: 188532
Improve the documentation for the new target.memory-module-load-level setting, and also return an error when there is no nlist data when appropriate.
llvm-svn: 188317
a bunch of semicolons where the IndirectFieldDecls
were. These IndirectFieldDecls should have been
implicit.
<rdar://problem/14628784>
llvm-svn: 188247
LLDB needs in memory module load level settings to control how much information is read from memory when loading in memory modules. This change adds a new setting:
(lldb) settings set target.memory-module-load-level [minimal|partial|complete]
minimal will load only sections (no symbols, or function bounds via function starts or EH frame)
partial will load sections + bounds
complete will load sections + bounds + symbols
llvm-svn: 188246
- updated RNBDefs.h to allow version numbers to be passed in via preprocessor defines
- update libdebugserver.cpp to compile against latest DNBProcessKill signature
Review: http://llvm-reviews.chandlerc.com/D1331
llvm-svn: 188078
- Immediates can be shown as hex (either Intel or MASM style)
- See TestSettings.py for usage examples
- Verified to cause no regressions on Linux x86_64 (Ubuntu 12.10)
Patch by Richard Mitton!
llvm-svn: 187921
mapping of source to assembly so that the same test script can be used
with more compilers.
Patch by Andy Kaylor!
Also marks the LLDB test of template parameters as xfail on icc.
llvm-svn: 187600
This adds a new parameter, --skip-category, that can be used to list
categories that should be skipped. For example, to run all tests except for
Objective-C ones, one can now write:
./dotest.py --skip-category objc [...]
llvm-svn: 187590
Created new LinuxThread class inherited from POSIXThread and removed linux / freebsd ifdefs
Removed several un-needed set thread name calls
CR (and multiple suggestions): mkopec
llvm-svn: 187545
- this fix ensures the ThreadList mutex is always locked before the StackFrameList mutex
Situation where deadlock could occur (without this fix):
Thread 1 is in Process::WillResume and locks the ThreadList mutex (on entry), and subsequently calls StackFrameList::Clear() which locks the StackFrameList mutex.
Meanwhile, thread 2 is in Process::RunThreadPlan and calls Thread::SetSelectedFrame() (which locks the StackFrameList mutex) before calling GetSelectedThread (which attempts to lock the ThreadList mutex)
In my testing on both Linux and Mac OS X, I was unable to reproduce any hangs with this patch applied.
llvm-svn: 187522
provide more detail on compiler compatibility, and to illustrate that this is
an issue with expression evaluation.
- Note that clang doesn't emit DW_TAG_const_type, which might be okay if there's
no such thing as a non-const rvalue reference. How about foo(make_int())?
llvm-svn: 187499
the extra check introduces 22 new test failures with the LLDB clang buildbot.
Note that the unhandled DWARF_OP codes in DWARFExpression::Evaluate don't cause test failures if the check is ignored.
llvm-svn: 187480
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this
for real when I have time to do so.
<rdar://problem/14581918>
llvm-svn: 187473
- disable some TestConcurrentEvents cases (which are affected by llvm.org/pr16714 -- watchpoints in multithreaded programs)
- relax number-of-bp-locations check in TestUniqueTypes/TestUnsignedTypes
- skip TestDataFormatterStdVector cases with GCC 4.8 (known failure due to llvm.org/pr15301)
- workaround for race condition in TestHelloWorld.py
- update TestSettings.py to work on distros (like Fedora) that have /bin/cat hardlinked to /usr/bin/cat
After these changes, the test suite should run cleanly against GCC 4.8 (with DWARF v4)!
llvm-svn: 187451
- pass through to base-class implementation when raised exception is not from an LLDBTest
- should make the test suite errors a little easier to root-cause
llvm-svn: 187450
to handle the case of an integer constant (DWARF 3 and later).
- Fixes tests that assert in RecordLayoutBuilder::updateExternalFieldOffset
because LLDB was providing an external AST source with missing member offsets.
llvm-svn: 187423
Instantiate RegisterContext... based on getOS() instead of with
compile-time #ifdef-ery.
The assert() here is unfortunate, but better than crashing with no
explanation.
This change is equivalent to r186865 for elf-core.
llvm-svn: 187422
Fixed a crasher when using memory threads where a thread is sticking around too long and was causing problems when it didn't have a thread plan.
llvm-svn: 187395
- newer gcc generates additional debuginfo for function exit (stack object desctruction) which was causing tests to fail
- work-around consists of not declaring any stack objects in main()
llvm-svn: 187389
LLDB requires that the inferior process be stopped before, and remain
stopped during, certain accesses to process state.
Previously this was achieved with a POSIX rwlock which had a write lock
taken for the duration that the process was running, and released when
the process was stopped. Any access to process state was performed with
a read lock held.
However, POSIX requires that pthread_rwlock_unlock() be called from the
same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start
the process from different threads. Violating this constraint is
technically undefined behaviour, although as it happens Linux and Darwin
result in the unlock proceeding in this case. FreeBSD follows POSIX
more strictly, and the unlock would fail, resulting in a hang later upon
the next attempt to take the lock.
All read lock consumers use ReadTryLock() and handle failure to obtain
the lock (typically by logging an error "process is running"). Thus,
instead of using the lock state itself to track the running state, this
change adds an explicit m_running flag. ReadTryLock tests the flag, and
if the process is not running it returns with the read lock held.
WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning,
and (if successful) they set m_running with the lock held. This way,
read consumers can determine if the process is running and act
appropriately, and write consumers are still held off from starting the
process if read consumers are active.
Note that with this change there are still some curious access patterns,
such as calling WriteUnlock / SetStopped twice in a row, and there's no
protection from multiple threads trying to simultaneously start the
process. In practice this does not seem to be a problem, and was
exposing other undefined POSIX behaviour prior to this change.
llvm-svn: 187377
in LLDB that load the canonical frame address rather than a location list.
- Handles the simple case where a CFA can be pulled from the current stack frame.
- Fixes more than one hundred failing tests with gcc 4.8!
TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs
to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB).
- Also adds some comments to DWARFCallFrameInfo whenever I got confused.
llvm-svn: 187361
- First, the watchpoint size was being cast to the
wrong type. This is primarily cosmetic, but
annoying.
- Second, the options for the watchpoint command
were not being initialized correctly, which led
to the watchpoint size sometimes having absurdly
large values. This caused watchpoints to fail to
be set in some cases.
<rdar://problem/12658775>
llvm-svn: 187169
Also move the logic to shorten thread names from linux/Host.cpp to a new
SetShortThreadName as both FreeBSD and Linux need the functionality.
llvm-svn: 187149
- ReadLocker constructors that take a lock
- Unconditional Lock::ReadLock and ReadLocker::Lock
(all consumers use TryLock)
- Make Unlock protected, as it has no external consumers
llvm-svn: 187147
FreeBSD's Host class doesn't yet return a list of running processes,
so 'platform process list' fails and attach by process name does not
work.
llvm-svn: 187142
PR title updated to indicate that FreeBSD is also affected: Backtrace
command does not display c++ member function names on Linux or FreeBSD
llvm-svn: 187127
The tests use a plugin based on the name from sys.platform.
Unfortunately that string includes the major version number in
Python 2.7, so the tests would look for builder_freebsd9.py,
builder_freebsd10.py, etc.
The issue doesn't affect Linux as Python returns 'linux2' also
on Linux 3.x -- see http://bugs.python.org/issue12326 for details.
It seems later versions of Python will drop the major version
number, so adopt this convention now for FreeBSD.
llvm-svn: 187121
and so the StackID changes with every step. Do so by checking the parent frame ID, and if it hasn't changed,
then we haven't stepped in.
rdar://problem/14516227
llvm-svn: 187094
been down for months and is likely no longer supported. This was
the most stable-looking link I could find for the current (0.99.6)
version of the ABI doc.
llvm-svn: 187087
If we are replacing a function with the nobuiltin attribute, it may be called
with the builtin attribute on call sites. Remove any such attributes since it's
illegal to have a builtin call to something other than a nobuiltin function.
This fixes the current buildbot breakage (where LLDB crashes on
"expression new foo(42)").
llvm-svn: 186990
This change removes the final instances of compile-time #ifdef magic
from the elf core plugin. Also rename the classes to ELFLinux... as
they're specific to Linux.
llvm-svn: 186977
Extracting thread data at parse time simplifies multi-platform support.
This change adds FreeBSD thread names and auxv info.
Thanks to Samuel Jacob for review, testing, and improvements.
llvm-svn: 186975
ELF notes contain a 'name' field, which specifies a vendor who defines
the format of the note. Examples are 'FreeBSD' or 'GNU', or it may be
empty for generic notes.
Add a case for FreeBSD-specific notes, leaving Linux and GNU notes,
other vendor-specific notes, and generic notes to be handled by the
existing code for now.
Thanks to Samuel Jacob for reviewing and suggesting improvements.
llvm-svn: 186973
-C usually specifies a script to prepopulate the CMake cache. In this case no
script is specified, so CMake appears to just ignore it. So don't mention it
in the first place - it's not desired anyways.
Reviewed by: Daniel Malea
llvm-svn: 186964
Instantiate RegisterContextCore... based on getOS() instead of with
compile-time #ifdef-ery.
The assert()s here are unfortunate, but better than crashing with no
explanation. (This would previously happen for an unsupported
architecture, anyhow.)
We should add an equivalent OS and architecture test to
ProcessElfCore::DoLoadCore() and cleanly report the error to the user.
llvm-svn: 186865
On FreeBSD I see that Arch, Vendor, OS, and Environment are unchanged
after this call (for x86_64, at least), and core debugging works without
it.
If we need to restore it we should be able to switch on
arch.GetTriple.getOS() instead of a compile-time #ifdef.
Thanks to Daniel Malea for testing on Linux.
llvm-svn: 186862
RegisterContextLLDB::SavedLocationForRegister to cache the pc and
sp register numbers -- if lldb is debugging multiple Targets of
different architectures, this will be incorrect. If these were
to be cached anywhere, it would have to be up in the Target.
llvm-svn: 186651
On FreeBSD we have only one NT_PRPSINFO in a core file, regardless of the
number of threads. Consider a new thread to start whenever we see another
instance of either NT_PRPSINFO or NT_PRSTATUS.
Thanks to Samuel Jacob for testing this patch on Linux cores.
llvm-svn: 186633
plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix
a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they
succeed before trying to proceed further. If the sub-plan failed and as a result didn't make
any progress, you could end up retrying the same failing algorithm in an infinite loop.
<rdar://problem/14043602>
llvm-svn: 186618
and -fomit-frame-pointer.
- Parses eh_frame FDEs to determine the function address and size so that
the call frame parsing can continue.
Note: This code path is specific to ELF and PECOFF, because ObjectFileMachO
uses LCT_FunctionStarts to efficiently populate the symbol table.
Thanks to Jason Molenda for the review!
llvm-svn: 186585
Compile-time #ifdef-ery isn't right, but this makes core debugging work on
FreeBSD and highlights the parts that will need to be changed for runtime
arch support.
llvm-svn: 186534
Usage: 'lldb a.out -c core'.
TODO: FreeBSD support.
TODO: Support for AVX registers.
TODO: Refactor so that RegisterContextCore* don't inherit from classes that use ProcessMonitor
to fix the build on OS/X.
llvm-svn: 186516
- test with python API
- test with command interpreter
- test stepping a single (selected) thread
- test stepping all threads in the program
llvm-svn: 186446
delete a constant after we replaced it with a
dynamically-computed value. Also ensured that we
replace all users of the constant if there are
multiple ones. Added a testcase.
<rdar://problem/14379043>
llvm-svn: 186363
Added a setting to control timeout for kdp response packets. While I was at it, I also added a way to control the response timeout for gdb-remote packets.
KDP defaults to 5 seconds, and GDB defaults to 1 second. These were the default values that were in the code prior to adding these settings.
(lldb) settings set plugin.process.gdb-remote.packet-timeout 10
(lldb) settings set plugin.process.kdp-remote.packet-timeout 10
llvm-svn: 186360
1 - looking up the type basename in the type index
2 - iterate through all matches and look for decl contexts (namespace/class hierarchy) that match
The issue was the decl context matching wasn't watching for DW_TAG_class_type/DW_TAG_structure_type mismatches, and it wasn't also getting the name for DIE's that didn't have a DW_AT_name, but did have a DW_AT_specification that had a name.
llvm-svn: 186347
write to registers if they were modified in the
expression. This eliminates spurious errors if
the register can't be written to but the
expression didn't write to it anyway.
Also improved error handling for the materializer
to make "couldn't materialize struct" errors more
informative.
<rdar://problem/14322579>
llvm-svn: 186228
RegisterContextCoreLinux_x86_64 inherits from RegisterContextLinux_x86_64 which inherits from RegisterContext_x86_64 which uses has:
ProcessMonitor &GetMonitor();
This register context used by the core file can't use this since the process plug-in will be ProcessElfCore and the implementation of GetMonitor() does:
ProcessMonitor &
RegisterContext_x86_64::GetMonitor()
{
ProcessSP base = CalculateProcess();
ProcessPOSIX *process = static_cast<ProcessPOSIX*>(base.get());
return process->GetMonitor();
}
ProcessELFCore doesn't, nor should it inherit from ProcessPOSIX and any call to GetMonitor() will fail for ELF core files.
Suggested cleanups:
- Make a register context class that is a base class that doesn't have any reading smarts, then make one that uses ProcessPOSIX and the has the GetMonitor() call, and one that gets its data straight from the core file.
llvm-svn: 186223
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects
llvm-svn: 186211
Virgile Bello