Thanks!
The general goal of mine with the LLVM & surrounding work is to turn on
all the features and to enable the execution of regular tests.
Building and testing LLDB or other software, on a buildbot, under LLVM
Sanitizers has not been planned and is beyond the scope with the current
resources.
On Thu, Feb 1, 2018 at 6:50 AM, Pavel Labath wrote:
> On 30 January 2018 at 23:21, Davide Italiano wrote:
>> I agree.
>
> Just to check: Does that apply to Tamas's paragraph below, as in
> that's the guidelines we should be giving to new language plugin
> implementors?
>
Yes, that's what I meant
Great work. Have you tried (or considered) setting up an LLDB buildbot
that runs the LLDB test suite with all of the sanitizers turned on?
On Thu, Feb 1, 2018 at 5:39 AM Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I've finished the interruption for LLVM Sanitizers:
>
> http
https://bugs.llvm.org/show_bug.cgi?id=36193
lab...@google.com changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.llvm.org/show_bug.cgi?id=36193
Bug ID: 36193
Summary: LoadUnloadTestCase.test_lldb_process_load_and_unload_c
ommands_dwarf fails when debugging from windows to
android
Product: lldb
Version: unspecifi
On 30 January 2018 at 23:21, Davide Italiano wrote:
> I agree.
Just to check: Does that apply to Tamas's paragraph below, as in
that's the guidelines we should be giving to new language plugin
implementors?
If that's the case, then I agree as well, although I think we should
be a bit more clean
I've finished the interruption for LLVM Sanitizers:
http://blog.netbsd.org/tnf/entry/the_llvm_sanitizers_stage_accomplished
Plan for the next milestone:
Keep upstreaming a pile of local compiler-rt patches.
Restore the LLDB support for traced programs with a single thread.
This work was spons
On 30 January 2018 at 16:39, Jan Kratochvil wrote:
> On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote:
>> so I'm writing this email to see if there's anyone
>> else interested in this topic, and to try to synchronize our efforts.
>
> I am sure interested in DWARF-5 .debug_names.
