I think we don't. If we consider them stable enough for enabling them on a
buildbot AND we agree to revert changes breaking the unittests then I am
happy with enabling them (doing it should take very little effort from our
side). Otherwise I would prefer to wait until we can get them to a stable
st
We're not running them yet. I'd like to add that at some point, but I
haven't gotten around to that yet...
On 5 April 2016 at 09:39, Tamas Berghammer wrote:
> I think we don't. If we consider them stable enough for enabling them on a
> buildbot AND we agree to revert changes breaking the unittest
We've got an OS that implements something they call a "user PD", which is a
lot like a PIE process. To debug it, we need to get the address of the image
and then slide the target's symbols. What's the best way to get the address
from the remote stub? Linux lldb reads an AuxVector from lldb-server,
> On Apr 5, 2016, at 10:46 AM, Ted Woodward via lldb-dev
> wrote:
>
> We’ve got an OS that implements something they call a “user PD”, which is a
> lot like a PIE process. To debug it, we need to get the address of the image
> and then slide the target’s symbols. What’s the best way to get th
https://llvm.org/bugs/show_bug.cgi?id=27227
Bug ID: 27227
Summary: TestImport fails on Python 3
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priorit
Hi Enrico,
Any suggestion/example how to add a data formatter for our own STL string?
>From the output below I can see we are using our own "*fbstring_core*"
which I assume I need to write a type summary for this type:
frame variable corpus -T
(const string &const) corpus = error: summary string
Okay, thanks all.
FWIW I am running them on the OS X side. I haven't seen any stability
problems yet. I'd also expect them to be very stable, much more like a
compiler test, since there are far fewer parts in a small-scoped C++ unit
test (vs., say, our Python tests which are end-to-end and have
