Sorry for the re-post. I initially sent it to the old list address.
On Wed, Aug 5, 2015 at 5:59 PM, Siva Chandra wrote:
> Hi all,
>
> This broke LLDB build:
> http://llvm.org/viewvc/llvm-project?revision=244161&view=revision
>
> The areas in LLDB it touches are beyond the
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
wrote:
> Thanks Siva,
> This indeed looks somewhat related to the problems we are seeing here.
> I'm just having a read of your patch now and going to try it out here.
>
>
> On 05/11/2015 18:24, Siva Chandra wrote:
>>
>> On Thu, Nov 5, 2015 at 9:43 AM, Aidan Dodd
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
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
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, 20
>
> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra
> wrote:
>
>> 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
>> &
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
y",
>>> line 237, in inferior_print_exit
>>> context = self.expect_gdbremote_sequence()
>>> File
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py",
>>> line 549, in expect_gdbremote_s
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
entire test suite disable support
> for i386.
>
> On Mon, Feb 8, 2016 at 2:08 PM Siva Chandra wrote:
>>
>> 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
>>
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
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 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
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:
string? We could ofcourse have more complex modifications.
I think it is doable, but what is your (and the community's) opinion
about adding such a feature? If you are OK, I would like to take up
adding such a feature.
Thanks,
Siva Chandra
On Thu, Aug 6, 2015 at 2:15 PM, Enrico Granata via lldb-de
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 "Type
ng's "pretty printer" should be made extensible by a
script?
>
> On Aug 6, 2015, at 2:33 PM, Siva Chandra wrote:
>
> FWIW, GDB has a similar concept called type-printers:
> https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html
>
> On Thu, Aug 6
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
>>
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 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
>> I
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 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
ere's some docs here too:
> http://docs.buildbot.net/current/index.html
>
> On Tue, Sep 15, 2015 at 9:42 AM, Siva Chandra
> wrote:
>
>> On Tue, Sep 15, 2015 at 9:25 AM, Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> > Th
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
25 matches
Mail list logo
