parse the output from "log enable --timestamp ...." and converts it to be relative
to the first timestamp and shows the time deltas between log lines. This can also
be used as a stand along script outside of lldb:
./delta.py log.txt
llvm-svn: 153288
Fixed a performance regression when dynamic types are enable where we would ask a C++ type if it can possibly be dynamic. Previously we would force the type to complete itself and then anwwer the question definitively. Now we ask the type if it is already complete and only definitively answer the question for completed types and just say "yes" for non-complete C++ types. We also always now answer yes for Objective C classes and do not complete those types either.
llvm-svn: 153284
- Addresses with no description were given
comments, leading to useless comments like
"; , "
- Addresses weren't resolved with respect
to the correct module.
llvm-svn: 153274
that the inferior cannot execute past the watchpoint-triggering instruction.
The solution is disable the watchpoint before resuming the inferior and make it hardware single step;
when the inferior stops again due to single step, re-enable the watchpoint and disable the single step
to make the inferior able to continue again without obstacle.
rdar://problem/9667960
llvm-svn: 153273
This is the feature that allowed the user to have things like:
class Base { ... };
class Derived : public Base { ... };
and have formatters defined for Base work automatically for Derived.
This feature turned out to be too expensive since it requires completing types.
This patch takes care of removing cascading (other than typedefs chain cascading), updating the test suite accordingly, and adding required Cocoa class names to keep the AppKit formatters working
llvm-svn: 153272
After the instructions are moved to the branch island, fixupInstructions() expands every 2-byte ja/je instruction with a 1-byte offset into a 6-byte ja/je with 32-bit offset. The offset is fixed to point to the original function.
llvm-svn: 153249
relied on an artifact of how the inliner and subsequent passes in
clang's -O3 mode happen to treat basic blocks and the labels for the
basic blocks. In my work on the inliner, and changed this fundamental
assumption, and the label that was being checked on the entry basic
block will no longer appear in opt builds. There was no reason to expect
the label to always be present anyways, much to my regret.
I've changed the test to just ensure that we return an immediate
constant. If there are intervening instructions, that's bad, but not
really that relevant to the test.
I'd love it if others have a better way of checking that a function body
contains only a 'ret' instruction that isn't dependent on whether or not
the entry block receives a label...
llvm-svn: 153243
(and hopefully on Windows). The bots have been down most of the day
because of this, and it's not clear to me what all will be required to
fix it.
The commits started with r153205, then r153207, r153208, and r153221.
The first commit seems to be the real culprit, but I couldn't revert
a smaller number of patches.
When resubmitting, r153207 and r153208 should be folded into r153205,
they were simple build fixes.
llvm-svn: 153241
Bill Wendling