Commit Graph

845 Commits

Author SHA1 Message Date
Greg Clayton eb023e75dc <rdar://problem/13635174>
Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging. 

Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function.

llvm-svn: 192491
2013-10-11 19:48:25 +00:00
Ed Maste b73f844be3 POSIX RegisterContext for mips64
Based on the POSIX x86_64 register context.  This is sufficient for opening
a mips64 (big endian) core file.  Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.

Review: http://llvm-reviews.chandlerc.com/D1873
llvm-svn: 192335
2013-10-10 00:59:47 +00:00
Michael Sartain 15c07b90c0 Re-enable test_convenience_registers_16bit_with_process_attach test for Linux.
Remove 32-bit POSIX register hack in ConvertBetweenRegisterKinds.

llvm-svn: 192306
2013-10-09 17:44:52 +00:00
Daniel Malea 9e9919f043 Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state
- By default, the above function will wait for at least one event
- Set wait_always=false to make the function return immediately if the process is already stopped

llvm-svn: 192301
2013-10-09 16:56:28 +00:00
Enrico Granata 347c2aa3e3 <rdar://problem/14028923>
Implement SBTarget::CreateValueFromAddress() with a behavior equivalent to SBValue::CreateValueFromAddress()
(but without the need to grab an SBValue first just as a starting point to make up another SBValue out of whole cloth)

llvm-svn: 192239
2013-10-08 21:49:02 +00:00
Sean Callanan ddd7a2a65b Changed the bool conversion operator on ConstString
to be explicit, to prevent horrid things like

std::string a = ConstString("foo")

from taking the path ConstString -> bool -> char
-> std::string.

This fixes, among other things, ClangFunction.

<rdar://problem/15137989>

llvm-svn: 191934
2013-10-03 22:27:29 +00:00
Jim Ingham 2b89a53181 DWARF says line number 0 is a valid line number - used to indicate a source line that should
not have breakpoints set on it inserted into code that does have a valid line number.  So allow
that line number, and the ThreadPlanStepRange should just continue stepping over 0 line ranges
as if they had the same line number as whatever we were previously stepping through.

llvm-svn: 191477
2013-09-27 01:15:46 +00:00
Jim Ingham e4483cf959 Remove unnecessary checks for thread_plan_sp (we check for this at the top of the function.)
llvm-svn: 191476
2013-09-27 01:13:01 +00:00
Joerg Sonnenberger 340a17595e Convert to UNIX line endings.
llvm-svn: 191367
2013-09-25 10:37:32 +00:00
Enrico Granata 5d5f60c391 Target::m_suppress_synthetic_value was a hack required to disable synthetic values while passing an SBValue to a synthetic child provider, or incur an endless recursion
Now that SBValues can be setup to ignore synthetic values, this is no longer necessary, and so m_suppress_synthetic_value can go away

Another Hack Bites the Dust

llvm-svn: 191338
2013-09-24 22:58:37 +00:00
Daniel Malea 4b86728bf4 Examine more than 1 frame for equivalent contexts in ThreadPlanStepOverRange
- searches frames beginning from the current frame, stops when an equivalent context is found
- not using GetStackFrameCount() for performance reasons
- fixes TestInlineStepping (clang/gcc buildbots)

llvm-svn: 190868
2013-09-17 16:35:45 +00:00
Jason Molenda 6b3e6d5487 Disassembler::DisassembleRange() currently calls Target::ReadMemory
with prefer_file_cache == false.  This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491> 

llvm-svn: 190638
2013-09-12 23:23:35 +00:00
Richard Mitton f86248d9ba Added a 'jump' command, similar to GDBs.
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.

Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)

llvm-svn: 190572
2013-09-12 02:20:34 +00:00
Jim Ingham d39907935c Turns out the number of times you need to resume the process for /bin/sh depends on the
setting of the environment variable COMMAND_MODE.  Changed the Platform::GetResumeCountForShell
to Platform::GetResumeCountForLaunchInfo, and check both the shell and in the case of
/bin/sh the environment as well.

llvm-svn: 190538
2013-09-11 18:23:22 +00:00
Jim Ingham df0ae22f92 Changing the default shell to /bin/sh brought up a long-standing bug on OS X,
that /bin/sh re-exec's itself to /bin/bash, so it needs one more resume when you
are using it as the shell than /bin/bash did or you will stop at the start of your
program, rather than running it.

So I added a Platform API to get the number of resumes needed when launching with
a particular shell, and set the right values for Mac OS X.

<rdar://problem/14935282>

llvm-svn: 190381
2013-09-10 02:09:47 +00:00
Ed Maste 93ef728f27 Correct logic error found by inspection.
From Jim's post on the lldb-dev mailing list:

  This code is there as a backstop for when the unwinder drops a frame at
  the beginning of new function/trampoline or whatever.

  In the (older_ctx_is_equivalent == false) case we will see if we are at
  a trampoline function that somebody knows how to get out of, and
  otherwise we will stop.

llvm-svn: 190149
2013-09-06 12:43:14 +00:00
Virgile Bello e2607b50ea Add OptionParser.h
llvm-svn: 190063
2013-09-05 16:42:23 +00:00
Ed Maste b8ca4a2c1a Switch '/bin/bash' to '/bin/sh'
/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
2013-09-03 23:04:53 +00:00
Ashok Thirumurthi 03520b7fc7 Fixed a few typos.
llvm-svn: 189355
2013-08-27 14:56:58 +00:00
Charles Davis 510938e528 Fix some names in the wake of my Mach-O changes to LLVM.
llvm-svn: 189317
2013-08-27 05:04:57 +00:00
Daniel Malea e0f8f574c7 merge lldb-platform-work branch (and assorted fixes) into trunk
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
2013-08-26 23:57:52 +00:00
Virgile Bello b2f1fb2943 MingW compilation (windows). Includes various refactoring to improve portability.
llvm-svn: 189107
2013-08-23 12:44:05 +00:00
Andrew Kaylor 53386dc836 Introducing a temporary work-around for a register mapping problem with 32-bit Linux targets.
llvm-svn: 188954
2013-08-21 22:46:02 +00:00
Greg Clayton 86eac940b4 <rdar://problem/14717184>
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
2013-08-13 21:32:34 +00:00
Greg Clayton fd814c5a64 <rdar://problem/14717184>
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
2013-08-13 01:42:25 +00:00
Daniel Malea d79ae05080 New settings: target.use-hex-immediates and target.hex-immediates-style
- 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
2013-08-07 21:54:09 +00:00
Michael Sartain 89c862f298 clean up about 22 warnings messages
llvm-svn: 187900
2013-08-07 19:05:15 +00:00
Jason Molenda 3f032ff2c5 Test to see if logging is enabled before printing
to a log channel in StopInfoBreakpoint::PerformAction().
<rdar://problem/14651751> 

llvm-svn: 187833
2013-08-06 23:08:59 +00:00
Jason Molenda 975abffee7 Re-enable fast stepping for arm targets. The issue being worked
around was fixed in llvm commit r186846.
<rdar://problem/14489274> 

llvm-svn: 187620
2013-08-01 21:50:20 +00:00
Michael Sartain 9f822cd1ec Fix thread name updating in Linux. "thread list" should report correct names always now.
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
2013-07-31 23:27:46 +00:00
Daniel Malea a012d3a68e Fix lock hierarchy violation in Process (lock ordering of ThreadList mutex and StackFrameList mutex)
- 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
2013-07-31 20:21:20 +00:00
Jim Ingham 56d404281f The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction
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
2013-07-31 02:19:15 +00:00
Sean Callanan 4b388c9e16 Send a stop event when an expression stops at a breakpoint
in an expression and doesn't ignore the stop.

Patch by Jim Ingham.

<rdar://problem/14583884>

llvm-svn: 187434
2013-07-30 19:54:09 +00:00
Greg Clayton 6e10f149c4 <rdar://problem/14526890>
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
2013-07-30 00:23:06 +00:00
Ed Maste 64fad60e34 Use flag instead of rwlock state to track process running state
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
2013-07-29 20:58:06 +00:00
Jim Ingham a7d4822c75 Refine the fix in r187094 to only distrust the StackID comparision when we are starting from an address with no symbols.
If we don't do that "nexti" will stop too soon when stepping past a tail call jump.

rdar://problem/14516227

llvm-svn: 187173
2013-07-26 00:27:57 +00:00
Jim Ingham 886a3e2cdf Handle the case where we are stepping through code with no symbols, so we can't really find the function start PC
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
2013-07-25 00:59:01 +00:00
Jim Ingham 63c5c2a0d8 Turn off fast stepping for ARM till the MC's MayAffectControlFlow gets more accurate.
rdar://problem/14488761

llvm-svn: 186646
2013-07-19 02:18:31 +00:00
Jim Ingham 4d56e9c1cb This commit does two things. One, it converts the return value of the QueueThreadPlanXXX
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
2013-07-18 21:48:26 +00:00
Greg Clayton 2540a8a7bc Fixed GetModuleSpecifications() to work better overall:
- 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
2013-07-12 22:07:46 +00:00
Greg Clayton 57ee306789 Huge change to clean up types.
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.

This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.

llvm-svn: 186130
2013-07-11 22:46:58 +00:00
Jim Ingham 363ddd7df2 Mark the "step over single instruction" plan private in the StopInfoWatchpoint::PerformAction to
ensure that the watchpoint not the step is reported as the stop reason.  Also, stash away & restore
the current stop reason just so it can't go away on us.

llvm-svn: 185474
2013-07-02 21:12:44 +00:00
Ed Maste c29693f720 Remove obsolete comment
llvm-svn: 185441
2013-07-02 16:35:47 +00:00
Jim Ingham b0b4513ea2 Use the "last created watchpoint" rather than asserting on watchpoint commands passing no watchpoint ID.
<rdar://problem/14327560> 

llvm-svn: 185406
2013-07-02 02:09:46 +00:00
Michael Sartain a7499c9830 Split symbol support for ELF and Linux.
llvm-svn: 185366
2013-07-01 19:45:50 +00:00
Sean Callanan 70cac8fd81 Remove the process's reservation cache and don't
bother checking if a region is safe to use.  In
cases where regions need to be synthesized rather
than properly allocated, the memory reads required
to determine whether the area is used are

- insufficient, because intermediate locations
  could be in use, and

- unsafe, because on some platforms reading from
  memory can trigger events.

All this only makes a difference on platforms
where memory allocation in the target is impossible.
Behavior on platforms where it is possible should
stay the same.

<rdar://problem/14023970>

llvm-svn: 185046
2013-06-27 00:10:26 +00:00
Han Ming Ong 91ed6b878f <rdar://problem/14182286>
Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first.

Reviewed by Greg

llvm-svn: 184769
2013-06-24 18:15:05 +00:00
Jim Ingham 02ff8e0931 Remember to update the m_thread_list_real after you do UpdateThreadList.
<rdar://problem/14147303>

llvm-svn: 184622
2013-06-22 00:55:02 +00:00
Jim Ingham dee1bc98f9 Add some useful logging for tracking thread matching problems.
llvm-svn: 184619
2013-06-22 00:27:45 +00:00
Han Ming Ong ef171f24d3 <rdar://problem/14004410>
Remove old GetNextThreadIndexID() from lldb

llvm-svn: 184600
2013-06-21 22:38:16 +00:00