I think we can remove these, provided there is a way to mimic the
functionality they are used for now, which I think shouldn't be hard.
Anything which was set up in the setUp() method should be undone in
tearDown(). Anything which was set up in the test method, can be
undone using a try-finally blo
[moving this to lldb-dev for more visibility.]
Sorry, I was in a hurry yesterday, so I did not explain myself fully. Let
me try to elaborate.
> What I am trying to avoid here is getting useless noise in build
automation where test cases proclaim their failure, which however tells us
nothing of va
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08.10.2015 12:21, Kamil Rytarowski via lldb-dev wrote:
> On 05.10.2015 21:46, Todd Fiala wrote:
>> Seems like a great idea. (Ed, is that something you might be
>> able to review?)
>
>
> The first patch is already proposed:
> http://reviews.llv
Hello,
I want to implement support for reading Performance measurement
information using the perf_event_open system calls. The motive is to add
support for Intel PT hardware feature, which is available through the
perf_event interface. I was thinking of implementing a new Wrapper like
Ptrace
https://llvm.org/bugs/show_bug.cgi?id=25273
Bug ID: 25273
Summary: synthetic data formatters for libstdc++ STL containers
fail on Ubuntu 15.10 x86_64
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
https://llvm.org/bugs/show_bug.cgi?id=25273
Todd Fiala changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|lldb-dev@lists.llvm.or
I'm in favor of (b). The less user-required setup to do the right thing on
a test suite, the better IMHO. Those actively trying to make sure one or
another c++ library is getting tested will be looking for the output to
validate which std c++ lib(s) ran.
-Todd
On Wed, Oct 21, 2015 at 3:47 AM, P
[ Moving this discussion back to the list. I pressed the wrong button
when replying.]
Thanks for the explanation Ravi. It sounds like a very useful feature
indeed. I've found a reference to the debugserver profile data in
GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with
your inv
On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton wrote:
> Then try running and let me know what your results are!
Hm, there seems to be something seriously wrong. I triple-checked
everything, but Declaration::Compare is not even called when the error
is triggered! How should we proceed now?
So first, an addendum: I found a way to make the project build without
using a symlink, and use a direct reference instead. The problem still
persists. It may be that symlink is one of the problems, but it is
certainly not the only problem.
On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton wrote:
> i
I seen very similar error messages when debugging an application compiled
with fission (split/dwo) debug info on Linux with a release version of LLDB
compiled from ToT. When I tested the same with a debug or with a
release+assert build I hit some assertion inside clang. It might worth a
try to chec
Yea, that's what I think too. I think this mechanism was probably invented
to just to save some code and promote reusability, but in practice leads to
these kinds of problems.
On Wed, Oct 21, 2015 at 2:07 AM Pavel Labath wrote:
> I think we can remove these, provided there is a way to mimic the
There are two different kinds of performance counters: OS performance
counters and CPU performance counters. It sounds like you're talking about
the latter, but it's worth considering whether this could be designed in a
way to support both (i.e. even if you don't do both yourself, at least make
th
Yes, the output of dotest.py goes through LitTestCommand parse.
The parser is matching for "XPASS", but dotest output is using "UNEXPECTED
SUCCESS". :)
Thanks,
Ying
On Tue, Oct 20, 2015 at 6:34 PM, Todd Fiala wrote:
> Hi Ying,
>
> Our dotest.py lldb test results go through that lit test parser
> On Oct 21, 2015, at 8:45 AM, Ramkumar Ramachandra wrote:
>
> So first, an addendum: I found a way to make the project build without
> using a symlink, and use a direct reference instead. The problem still
> persists. It may be that symlink is one of the problems, but it is
> certainly not the
I think it was mostly done to provide an exception safe way to cleanup stuff
without having to override TestBase.tearDown(). I am guessing this cleanup
happens on TestCase.tearDown() and not after the current test case right?
I could see it being used to cleanup after a single test case in case
IMHO the best way to provide this information is to implement reverse debugging
packets in a GDB server (lldb-server). If you enable this feature via some
packet to lldb-server, and that enables the gathering of data that keeps the
last N instructions run by all threads in some buffer that gets
one main benefit to doing this externally is allow this to be done remotely
over any debugger connection. If you can run expressions to
enable/disable/setup the memory buffer/access the buffer contents, then you
don't need to add code into the debugger to actually do this.
Greg
> On Oct 21, 20
Well you can see them getting added via self.addTearDownHook(), so that
means they're called through an instance. Specifically, it happens in
Base.tearDown(self), so it's basically identical (in concept) to if the
relevant handlers were called in the implementation of MyTest.tearDown(),
but differ
*TL;DR - Nobody has to do anything, this is just a heads up that a 400+
file CL is coming.*
IANAL, but I've been told by one that I need to move all third party code
used by LLDB to lldb/third_party. Currently there is only one thing there:
the Python `six` module used for creating code that is p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21.10.2015 12:47, Kamil Rytarowski via lldb-dev wrote:
> On 08.10.2015 12:21, Kamil Rytarowski via lldb-dev wrote:
>> On 05.10.2015 21:46, Todd Fiala wrote:
>>> Seems like a great idea. (Ed, is that something you might be
>>> able to review?)
>
Oh haha okay. :-)
Thanks for explaining, Ying!
-Todd
On Wed, Oct 21, 2015 at 10:01 AM, Ying Chen wrote:
> Yes, the output of dotest.py goes through LitTestCommand parse.
> The parser is matching for "XPASS", but dotest output is using "UNEXPECTED
> SUCCESS". :)
>
> Thanks,
> Ying
>
> On Tue,
22 matches
Mail list logo
