We hit similar problems in the past when building with debug info
enabled; using -gsplit-dwarf helped us.
On Sun, May 22, 2016 at 3:36 AM, Sylvestre Ledru via lldb-dev
wrote:
> Hello,
>
> Lately, I haven't been able to link lldb because it uses too much memory:
>
> /usr/bin/ld: final link failed:
On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan wrote:
> Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
> first field 'small_' is fixed, however the second field 'ml_' still emits
> garbage:
>
> (lldb) fr v corpus
> (const string &const) corpus = error: summary string parsin
Is it related to the regression that Greg was talking about here:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20160208/027449.html
On Wed, Feb 10, 2016 at 2:20 AM, Tamas Berghammer via lldb-dev
wrote:
> Hi Sean,
>
> Can you gave us some more context on this because without access to
On Mon, Feb 8, 2016 at 2:35 PM, Zachary Turner wrote:
>
>
> On Mon, Feb 8, 2016 at 2:21 PM Siva Chandra wrote:
>>
>> On Mon, Feb 8, 2016 at 2:10 PM, Zachary Turner wrote:
>> > Why though?
>>
>> Foremost, I think it is because the lldb driver built as part of the
>> test is linked to the host lld
On Mon, Feb 8, 2016 at 2:10 PM, Zachary Turner wrote:
> Why though?
Foremost, I think it is because the lldb driver built as part of the
test is linked to the host lldb shared library. If you build a 32-bit
driver, we will need a 32-bit lldb shared library as well is it not?
Second, which I thin
On Mon, Feb 8, 2016 at 1:36 PM, Zachary Turner via lldb-dev
wrote:
> Why is this marked @skipIfI386? I don't see anything i386 specific about
> this test. Can this decorator be removed?
I think skipping for i386 is only because most developers are using
64-bit hosts for development. [Heck, even
Yes, there is something like that but I am unable to recollect.
However, I do not think Zach's problem is that. He is able to get all
but 2 of the tests passing.
Zach, is it possible for you to run with clang-3.5?
On Wed, Feb 3, 2016 at 3:05 PM, Todd Fiala wrote:
> (Security around ptrace).
>
>
Our bot is running on Ubuntu 14.04 and is green:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
One thing though, the bot does not run the testsuite with clang-3.6.
About the unexpected successes, they are very likely tests which were
found to be flaky and marked as expectedFailu
I think this one:
http://llvm.org/viewvc/llvm-project?view=revision&revision=240578
On Mon, Jan 25, 2016 at 4:34 PM, Enrico Granata wrote:
>
> On Jan 25, 2016, at 4:09 PM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> lldb-340.4.119 (OSX 10.11.3)
>
> On Mon, Jan 25, 2016 at
On Mon, Jan 25, 2016 at 4:09 PM, Vadim Chugunov wrote:
> lldb-340.4.119 (OSX 10.11.3)
I have no idea what that number means. May be Enrico can figure if
that build has the fix or not.
> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra
> wrote:
>>
>> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov
On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
wrote:
> Hi,
> If I have an SBValue for an object whose type has a formatter enabled for
> it, is there a way to detect this via the Python API, and if so, request an
> "unmodified" view of the object?
> I've experimented with value.IsS
Can you try again after taking my change at r255584?
On Mon, Dec 14, 2015 at 4:31 PM, Todd Fiala via lldb-dev
wrote:
> I'm having some of these blow up.
>
> In the case of test/lang/c/typedef/Testtypedef.py, it looks like some of the
> @expected decorators were changed a bit, and perhaps they are
Note that my patch is C++ specific. You might want to try by
commenting out the C++ check. Also, since in your case something
(though wrong) is actually found, you will have to change the ordering
of tries in ClangExpressionDeclMap::GetFunctionAddress.
On Fri, Nov 6, 2015 at 3:12 AM, Aidan Dodds
On Thu, Nov 5, 2015 at 9:43 AM, Aidan Dodds via lldb-dev
wrote:
> I believe I have tracked down an interesting bug which related to LLDBs
> expression parser.
>
> In my target program I have a math library, a shared object which makes use
> of clangs __attribute__((overloadable)) extension for C99
On Tue, Sep 15, 2015 at 9:59 AM, Tamas Berghammer
wrote:
> I think downloading data with the json API won't help because it will only
> list the failures displayed on the Web UI what don't contain full test
> names and don't contain info about the UnexpectedSuccess-es. If you want to
> download i
IIRC, doing it from Python is straightforward and simple:
json.load(urlparse.urlopen(<...>))
Could be a little more, but should not be much.
On Tue, Sep 15, 2015 at 9:52 AM, Todd Fiala wrote:
> Yep looks like there's a decent interface to it. Thanks, Siva!
>
> I see there's some docs here too
On Tue, Sep 15, 2015 at 9:25 AM, Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> > The cmake builder runs in GCE and it uploads all test logs to Google
> Cloud Storage (including full host logs and server logs). I used a python
> script (running also in GCE) to download this data and t
I see a possible printf at DWARFCompileUnit.cpp:444
$> git grep -n ": \[.*-.*)"
Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:444:
printf ("0x%8.8x: [0x%16.16" PRIx64 " - 0x%16.16" PRIx64 ")\n",
GetOffset(), range.GetRangeBase(), range.GetRangeEnd());
Plugins/SymbolFile/DWARF/DWARFDebugAranges.
On Thu, Aug 6, 2015 at 4:17 PM, Siva Chandra wrote:
>
> On Thu, Aug 6, 2015 at 3:58 PM, Enrico Granata wrote:
>> The obvious mechanism is that the compiler has knowledge of the structure
>> of the type - so it can make printing decisions based on that type structure
>> In this case, I imagine a v
On Thu, Aug 6, 2015 at 3:58 PM, Enrico Granata wrote:
>
> On Aug 6, 2015, at 3:50 PM, Siva Chandra wrote:
>
>
>
> On Thu, Aug 6, 2015 at 3:38 PM, Enrico Granata wrote:
>
>>
>> On Aug 6, 2015, at 3:33 PM, Siva Chandra wrote:
>>
>>
>>
>> On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata
>> wrote:
On Thu, Aug 6, 2015 at 3:38 PM, Enrico Granata wrote:
>
> On Aug 6, 2015, at 3:33 PM, Siva Chandra wrote:
>
>
>
> On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata wrote:
>
>> To be honest, my favorite approach would be to modify clang’s TypePrinter
>> to do this, and then hooking up GetDisplayTyp
On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata wrote:
> To be honest, my favorite approach would be to modify clang’s TypePrinter
> to do this, and then hooking up GetDisplayTypeName() to use whatever flags
> would be necessary to invoke that bit of magic
>
Do you mean that clang's "pretty print
FWIW, GDB has a similar concept called type-printers:
https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html
On Thu, Aug 6, 2015 at 2:24 PM, Siva Chandra wrote:
> Hi Enrico,
>
> I was thinking about the same issue today. Could we add a concept
> called "TypeNameModifier" and pro
Hi Enrico,
I was thinking about the same issue today. Could we add a concept
called "TypeNameModifier" and provide ability to define modifiers in
scripts and command line? With this, a name like
std::__1::basic_string<...> can be modified into a more friendly name
like std::string? We could ofcour
24 matches
Mail list logo
