[lldb-dev] [Bug 36224] lldb fails on loading a core file: Assertion failed: (template_counter >= 0), function ConsumeTemplateArgs

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=36224

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
   Assignee|lldb-dev@lists.llvm.org |ezemt...@google.com

--- Comment #1 from lab...@google.com ---
This looks like Eugene's name parser, so assigning it to him.

Roman, while Eugene responds, could you look up the exact name that triggers
this crash? It should be available in the CPlusPlusLanguage::MethodName::Parse
(frame #8 in your backtrace) under the name "m_full".

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Querying build configuration of (lib)lldb from tests.

[Pavel Labath via lldb-dev]

Hello all,

In  we have a feature that only works
when lldb was built with xml support. To  test this, we need the test
to know whether we were build with xml support.

The typical llvm solution would be to generate some dotest equivalent
of lit.site.cfg at build time, which we could then load from the test
and query for build settings.

However, it has occurred to me that the information about various
build properties (xml suport, libedit support, list of llvm targets we
support) is something that could be useful to other liblldb clients as
well. So, another way of exposing this would be to have a function
(maybe a static function on SBDebugger ?) that the test can call and
get the required information that way.

Do you have any thoughts on how this should be handled? Or maybe know
of an existing way that we could check this information already?

regards,
pavel
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36237] New: TestTargetSymbolsSepDebugSymlink fails when run remotely

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=36237

Bug ID: 36237
   Summary: TestTargetSymbolsSepDebugSymlink fails when run
remotely
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org

The root problem is in Platform::Install.
When given a symlink, it will try to create the same symlink on the target. 
However, Platform::CreateSymlink function is not implemented, but even if it
was, the target is unlikely to contain anything at the place where the symlink
points to. And even if it contain something, it would most likely be a
different object than the debugger will obtain when it resolves the symlink
locally.

I think that a more reasonable behavior here would be to copy the file contents
instead.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36237] TestTargetSymbolsSepDebugSymlink fails when run remotely

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=36237

Jan Kratochvil  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |jan.kratoch...@redhat.com
 Status|NEW |ASSIGNED
 CC||jan.kratoch...@redhat.com

--- Comment #1 from Jan Kratochvil  ---
Fix Bug 36237 - TestTargetSymbolsSepDebugSymlink fails when run remotely
https://reviews.llvm.org/D42908

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36237] TestTargetSymbolsSepDebugSymlink fails when run remotely

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=36237

Jan Kratochvil  changed:

   What|Removed |Added

   Assignee|jan.kratoch...@redhat.com   |lldb-dev@lists.llvm.org
 Status|ASSIGNED|NEW

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [RFC] Testsuite in lldb & possible future directions

[Davide Italiano via lldb-dev]

Hi,
in the last couple of months a lot of people put a lot of attentions
and energy into lldb and we're starting to see the first results. I
decided to sit down and write this e-mail to state where we are and
what are some possible future directions for the projects, in terms of
better quality/higher testability.

Current state:

1) We got the testsuite on MacOS to build with zero unexpected
successes and zero failures (modulo one change I'm going to push
tomorrow). This is a collaborative effort and it's very important
because it allows us to push for unexpected successes as failures on
the bots, allowing us to discover issues quicker. Other platform I
think are improving their state as well, mainly thanks to the work of
Pavel and Jan.

2) Adrian is pushing some changes that will allow us to build tests
out of tree. This is particularly good because it doesn't matter the
build directly and indirectly makes the testsuite more reliable as you
can just wipe the build directory when you're done and retry. It also
opens the path for new improvements, e.g. sharing a module cache
across all tests instead of creating a module cache per-test.

3) Vedant spent a lot of time fixing modules issues & ubsan/asan
failures, which. again, improved reliability.

Future:
1) I'm currently exploring ways of testing more akin to what llvm
does. We already have a bunch of unit tests, and I'm considering to
leverage `lldb-test` to experiment testing parts of the compilers that
don't really need interactivity (e.g. expression
parsing/autocomplete). I'm not sure whether this will lead to
anything, but if we can make the process easier for developers coming
from other bits of LLVM, I think we should (at least we should give it
a try).

2) Now that we raised the quality of our standards (we've been with
green bots for a while), I'd love to keep some time and focus on the
standards for future commits.
I think we should adhere to the LLVM policy here
https://llvm.org/docs/DeveloperPolicy.html#quality
So, commits that break tests/break the build/don't include a test
might be reverted. In addition, commits with design decisions not
previously discussed might be reverted if there are concerns about the
general direction.

3) In the short term I plan to remove support for unmaintained
languages (Java/Go/Swift). This allows us to bring them back again (or
bring new languages) but have a better plan for testability &
maintainability.

I'm pretty sure other people have ideas on what they're working
on/want to push/do next, so I'll let them speak.

Conclusions:
The reliability of the suite (and the health of the codebase) is very
important to us. If you have issues, let us know.
In general, I'm looking for any kind of feedback, feel free to speak!

Thanks,

--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev