| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.
Depends on D49887.
Differential Revision: https://reviews.llvm.org/D50478
llvm-svn: 343900
|
|
llvm-svn: 339205
|
|
Clarify how StackFrameList works by documenting its methods. Also,
delete some dead code and insert some TODOs.
Differential Revision: https://reviews.llvm.org/D50087
llvm-svn: 338590
|
|
Using early returns in this function substantially reduces the nesting
level, making the logic easier to understand.
llvm-svn: 338589
|
|
Splitting GetOnlyConcreteFramesUpTo will make it easier to implement
support for synthetic tail call frames in backtraces. This is just a
prep change, no functionality is affected.
llvm-svn: 338588
|
|
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.
llvm-svn: 335599
|
|
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
|
|
This patch introduces a new thread backtrace command "unique".
The command is based off of "thread backtrace all" but will instead
find all threads which share matching call stacks and de-duplicate
their output, listing call stack and all the threads which share it.
This is especially useful for apps which use thread/task pools
sitting around waiting for work and cause excessive duplicate output.
I needed this behavior recently when debugging a core with 700+ threads.
Differential Revision: https://reviews.llvm.org/D33426
Reviewers: clayborg, jingham
Patch by Brian Gianforcaro <b.gianfo@gmail.com>
llvm-svn: 305197
|
|
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
|
|
Also found/fixed one bug identified by this warning in
RenderScriptx86ABIFixups.cpp where a string literal was being used in an
effort to provide a name for an instruction/register, but was instead
being passed as the bool 'isVolatile' parameter.
llvm-svn: 291198
|
|
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
llvm-svn: 270024
|
|
Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped.
Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct.
Tests run on Ubuntu 12.04 show no regression.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20135
llvm-svn: 269250
|
|
the right thing and break.
llvm-svn: 261950
|
|
source/Target; other minor fixes.
llvm-svn: 261242
|
|
Summary: This function reads m_frames, so it needs to lock the
mutex like all other function that access m_frames.
Found using AddressSanitizer.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13638
llvm-svn: 250493
|
|
llvm-svn: 250465
|
|
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
|
|
It is required because of the following edge case on arm:
bx <addr> Non-tail call in a no return function
[data-pool] Marked with $d mapping symbol
The return address of the function call will point to the data pool but
we have to treat it as code so the StackFrame can calculate the symbols
correctly.
Differential revision: http://reviews.llvm.org/D12556
llvm-svn: 246958
|
|
When the current address is pointing 1 (unit) over the end of a
section the we have to do a section lookup after making the adjusment
of the current address.
Differential revision: http://reviews.llvm.org/D10124
llvm-svn: 238737
|
|
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
|
|
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
|
|
llvm-svn: 212553
|
|
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
|
|
unwinder when StackFrameList::GetFramesUpTo() is called.
Mainly patched to stop LLDB from crashing. This can easily happen if you debug to a remote gdbserver that doesn't have any dynamic register info and you don't have a target definition file specified.
llvm-svn: 195499
|
|
at some point in the past. We may have nothing more than a pc value
for this type of stack frame -- hopefully we'll have a pc and a
stop_id so we can track module loads and unloads over time and
symbolicate the pc at the correct point in time.
Also add a flag to indicate if the CFA for the frame is available
(a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an
overall setting to indicate whether this is a history stack frame
or not. A history stack frame may not have a CFA, it may not have
a register context, it may not have variables, it may not have a
frame pointer or a stack pointer.
<rdar://problem/15314068>
llvm-svn: 193987
|
|
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
|
|
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
|
|
<rdar://problem/15252474>
llvm-svn: 192989
|
|
Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContextRef doesn't store a std::weak_ptr to a stack frame because stack frames often get replaced with new version, so it held onto a StackID object that would allow us to ask the thread each time for the frame for the StackID. The linear function was too slow for large recursive stacks. We also fixed an issue where anytime the std::shared_ptr<ExecutionContextRef> in any SBTarget, SBProcess, SBThread objects was turned into an ExecutionContext object, it would try to resolve all items in the ExecutionContext which are shared pointers. Even if the StackID in the ExecutionContextRef was invalid, it was looking through all frames in every thread. This causes a lot of unnecessary frame accesses.
llvm-svn: 182627
|
|
the macros and just use C++11.
llvm-svn: 179805
|
|
C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.
Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.
llvm-svn: 179779
|
|
Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread.
- Cleaned up all the places where a thread inside a thread was causing problems
llvm-svn: 179405
|
|
threads are using these lists and those other threads have the mutex locked.
llvm-svn: 178262
|
|
us to think we can't even get the
frame at index 0. We should ALWAYS be able to get that.
<rdar://problem/13497571>
llvm-svn: 178205
|
|
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
|
|
Fixing an issue where threads and frames could get out of sync and cause ValueObjects to fail to retrieve their values correctly
llvm-svn: 177166
|
|
Added the ability to debug through your process exec'ing itself to the same architecture.
llvm-svn: 169340
|
|
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
llvm-svn: 168945
|
|
llvm-svn: 165808
|
|
inline stack when we get there by breakpoint. If we hit a user breakpoint, I set the stop point to the bottom-most frame 'cause that's what we did before.
<rdar://problem/12258999> Setting breakpoint in always inline function is stopping in function above it
llvm-svn: 163439
|
|
In GetFramesUpTo, don't adjust the number of frames for the inlined depth if the number of frames in UINT32_MAX.
llvm-svn: 163432
|
|
InlinedStackDepth.
llvm-svn: 163365
|
|
virtual step.
llvm-svn: 163341
|
|
llvm-svn: 163246
|
|
unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that
on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an
assert and dies immediately. So for now its off.
llvm-svn: 163044
|
|
The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them.
llvm-svn: 160071
|
|
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...
Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)
llvm-svn: 156221
|
