Ok, sounds good.
> In the base class case we already import minimally (I think), but even
minimal import causes full import
This is deliberate. During construction of ASTImporter the minimal import
flag is set. And then when ASTImporter::ImportDefinition is called, it will
do a full import, even t
Hi Jaroslav,
Thank you for digging into this. I think it may be possible to not eagerly
import a RecordDecl. Perhaps we could control that from
clang::ASTNodeImporter::VisitPointerType and instead of a full import we
could just do a minimal import for the PointeeType always. Similarly to
referenc
Hi Jaroslav,
Thanks for working on this. Still, there are things that are unclear for me.
I see that `LayoutRecordType` is called superfluously during the second
evaluation of `c2.x`, ok.
But, could you explain why LLDB is calling that multiple times? Maybe it
thinks a type is not completed while
Hi,
Thank you guys for coming to the round table. I am trying to summarize what
we were talking about.
- Error handling: rollback mechanism
We agreed that this is something that would be incredibly problematic to
implement mostly because the AST is not designed to be trimmed. In normal
cases, the
Hi,
At the upcoming LLVM Dev Conf, we will have a round table discussion for
ASTImporter, right after the ASTImporter Tutorial.
The time slot for the round table is Wednesday, Oct 23 2:55-4:00.
I have gathered things about possible future work and improvements, bring
your own topic to discuss!
Th
ProcessID task_for_pid failed: ::task_for_pid (
>> target_tport = 0x0103, pid = 27646, &task ) => err = 0x0005 ((os/kern)
>> failure)
>>
>>
>> On Mon, Jul 22, 2019 at 6:10 PM Frédéric Riss wrote:
>>
>>> I think the system logs (in Console.app)
gt; debugserver and you should find attach failures. Then remove the filter and
>> look at what happens right before that. There should be a log from
>> taskgated or authd that is a little more explicit about what’s failing.
>>
>> Fred
>>
>> On Jul 22, 2019, at 8
for
> debugserver and you should find attach failures. Then remove the filter and
> look at what happens right before that. There should be a log from
> taskgated or authd that is a little more explicit about what’s failing.
>
> Fred
>
> On Jul 22, 2019, at 8:55 AM, Gábor Márto
Hi,
I am planning to submit a talk about ASTImporter to the upcoming Dev
Meeting at October 22-23, 2019.
I'd like to talk about
- the API,
- how it is used in CTU analysis and in LLDB,
- internal subtleties and difficulties (Error handling, ExternalASTSource,
...)
The goal would be to attract more
Some more info: I've stopped lldb (with the system lldb) when
" Process::SetExitStatus (status=-1 (0x), description="Error 1")"
is logged and gathered some more information.
Is it possible that some packet types are not implemented?
* frame #0: 0x7fff599452c6 libsystem_kernel.dylib`_
Yes, here it is.
egbomrt@msmarple ~/llvm2/build/release_assert $ ./bin/lldb ~/a.out
(lldb) target create "/Users/egbomrt/a.out"
Current executable set to '/Users/egbomrt/a.out' (x86_64).
(lldb) log enable lldb default
(lldb) r
Processing command: r
HandleCommand, cmd_obj : 'process launch'
Hand
Well, SIP is turned off and I experience the same with a binary I just
built:
```
egbomrt@msmarple ~/llvm2/build/release_assert $ csrutil status
System Integrity Protection status: disabled.
egbomrt@msmarple ~/llvm2/build/release_assert $ ./bin/lldb ~/a.out
(lldb) target create "/Users/egbomrt/a.ou
I am still struggling with this issue. Now I decided to work with the
codesigned version of the debugserver, becasue I had an error when I tried
to use the system debugserver.
So I've run scripts/macos-setup-codesign.sh
After a reboot and fresh build (I have removed the CMakeCache.txt and the
whole
Actually, it is embarrassing (perhaps for macOS and not for me) that after
a reboot the problem is gone.
Perhaps after "sudo /usr/sbin/DevToolsSecurity --enable" a reboot is
required, but could not find anything official about that.
On Fri, Jul 19, 2019 at 7:20 PM Gábor Márton wrote:
> This migh
This might not be related to the debugserver, I just realized that I get
"error: process exited with status -1 (Error 1)"
even with the simplest main.c.
This may be some kind of security issue on mac OS...
Though I've checked and I have SIP disabled and I have executed "sudo
/usr/sbin/DevToolsSecur
Hi Stefan,
Since the commit
"[CMake] Always build debugserver on Darwin and allow tests to use the
system's one"
I cannot use the system debugserver for testing.
I receive the following error message from lldb when I execute "ninja
check-lldb":
```
runCmd: run
runCmd failed!
error: process exited
Guilherme,
Could you please check if you have any structural differences between the
ASTs you see when
1) you first evaluate your expression at breakpoint A
2) you evaluate your expression the second time at breakpoint A ?
The AST of the expression evaluator's context is dumped once a TagDecl is
c
Hi,
Cross Translation Unit (CTU) static analysis on master(trunk) reached
a milestone.
Now we can CTU analyse a not trivial C project - TMUX in this case -
without any crashes.
We are preparing a buildbot which does this analysis of TMUX with the
help of CodeChecker (https://github.com/Ericsson/co
Hi guys,
I've seen that recently the test
lldb-Suite.macosx/queues.TestQueues.py fails non-deterministically.
E.g.
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/21271/testReport/
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/21244/testReport/
http://green.lab.llvm.org/green/
Yes, it works. Thanks!
On Tue, Mar 5, 2019 at 4:54 PM Davide Italiano wrote:
>
> I think this might have been fixed, try to pull.
>
> On Tue, Mar 5, 2019 at 3:10 AM Gábor Márton via lldb-dev
> wrote:
> >
> > Hi,
> >
> > On trunk I receive the following b
Hi,
On trunk I receive the following build error on Linux:
../../git/llvm/tools/lldb/include/lldb/lldb-forward.h:181:7: note:
forward declaration of 'lldb_private::ProcessInstanceInfoList'
class ProcessInstanceInfoList;
^
../../git/llvm/tools/lldb/source/Host/linux/Host.cpp:260:23: error:
me
; * -DLLDB_USE_SYSTEM_DEBUGSERVER=ON to use a copy of the system's debugserver
> instead
> * -DLLDB_NO_DEBUGSERVER=ON to have no debugserver at all
>
> Best
> Stefan
>
> On 10. Dec 2018, at 20:28, Gábor Márton via lldb-dev
> wrote:
>
> Hi,
>
> Recently I have upd
Hi,
I have discovered new test failures on Linux, on trunk. They seem to fail
when DWO is used (DWARF test cases pass).
https://bugs.llvm.org/show_bug.cgi?id=40048
https://bugs.llvm.org/show_bug.cgi?id=40049
https://bugs.llvm.org/show_bug.cgi?id=40050
Gabor
___
Hi,
There are 6 tests in the lldb test framework (ninja check-lldb) which fail
on Linux:
Failing Tests (6):
LLDB :: ExecControl/StopHook/stop-hook-threads.test
lldb-Suite ::
functionalities/data-formatter/data-formatter-stl/libcxx/function/TestLibCxxFunction.py
lldb-Suite ::
functional
Thank you Pavel!
On Mon, Dec 10, 2018 at 8:51 PM Pavel Labath wrote:
> On 10/12/2018 20:28, Gábor Márton via lldb-dev wrote:
> > Hi,
> >
> > Recently I have updated the LLDB source and now I cannot link the
> > debugserver.
> > I guess, the problem is started i
Hi,
Recently I have updated the LLDB source and now I cannot link the
debugserver.
I guess, the problem is started in one of the commits at last week, because
before that I had not experienced it.
Any help would be appreciated. I'd like to get a command line only solution
because I am building via
Hi,
Is there an LLDB counterpart to GDB's Checkpoint/Restart feature (
https://sourceware.org/gdb/onlinedocs/gdb/Checkpoint_002fRestart.html)? I
could not find anything here http://lldb.llvm.org/lldb-gdb.html. Is there a
way to mimic that feature somehow on macOS (or do reverse debugging) ?
Thank
> Thanks for reporting this problem. I cc:ed Mike, as he owns the bots,
and he should be able to help us with this.
> (I do have access to the Jenkins configuration but I don't feel
confident enough to make the change myself).
Hi Davide and Mike,
I have received an email from llvm.greendra...@gma
Sure, I have created the reports:
https://bugs.llvm.org/show_bug.cgi?id=39909
https://bugs.llvm.org/show_bug.cgi?id=39910
And there was one already which I extended:
https://bugs.llvm.org/show_bug.cgi?id=22988
Gabor
On Thu, Dec 6, 2018 at 6:39 PM Davide Italiano
wrote:
> On Thu, Dec 6, 2018 at
Hi Davide,
Thank you for your email.
> In particular, what's the error you get when lldb fails immediately
running the tests?
> Also, have you checked libcxx and libcxx-abi in your build? We might
> consider making that a mandatory dependency for the Cmake build.
Finally I could run the test sui
Dear LLDB Developers,
There is an ongoing activity to improve ASTImporter in Clang to make it
support
C++ (and C) completely and correctly. Our team works on cross translation
unit
(CTU) static analysis where we use the in-tree Clang static analyzer in
combination with the ASTImporter (via the sc
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
>> Foundation Collaborative Project
>>
>> -Original Message-
>> From: lldb-dev On Behalf Of Gábor Márton
>> via lldb-dev
>> Sent: Wednesday, September 19, 2018 11:04 AM
>
----
> From: lldb-dev On Behalf Of Gábor
> Márton via lldb-dev
> Sent: Wednesday, September 19, 2018 11:04 AM
> To: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] skip some tests with "check-lldb"
>
> I just realized that `dotest.py` has a --thread option. Is t
I just realized that `dotest.py` has a --thread option. Is that the
one which is used during the lit test (`ninja check-lldb`) ?
On Wed, Sep 19, 2018 at 6:00 PM Gábor Márton wrote:
>
> Hi,
>
> I'd like to skip some tests when I run "ninja check-lldb", because they fail.
> I am on release_70 branc
Hi,
I'd like to skip some tests when I run "ninja check-lldb", because they fail.
I am on release_70 branch.
I know I could use dotest.py directly, but that would exercise only one thread.
Is there a way to execute the tests parallel on all cores and in the
same time skip some of the tests?
Thank
Hi Hans,
> The final version of 7.0.0 has been tagged from the branch at r342370.
I'd like to fork from 7.0.0 final but I got confused:
The tip of release_70 branch is still r341805, which is identical to
rc3. This should be r342370 instead, shouldn't it? Or the final
(r342370) does not go into t
Just sending again the trace, because gmail broke the lines pretty badly.
(1)
=== "To" ASTContext A, "From" ASTContext X, MINIMAL import through
ExternalASTSource inteface
clang::ASTImporter::Import (this=0x13b3c50, FromT=...) at
../../git/llvm/tools/clang/lib/AST/ASTImporter.cpp:6983
lldb_privat
Lang,
I've done some more research on this and here is what I've found so far.
LLDB uses the ExternalASTSource interface and it provides its own
implementation for it (lldb_private::ClangASTSource).
ClangASTSource is being used in at least 3 modes (all of these uses
the ASTImporter):
(1) to do a
> It might be interesting to consider how this is addressed by the
> ExternalASTSource interface. There, we have separate "import the lexical
> contents of this AST node (including populating the lexical declarations list
> with all members, in the right order)", "import the lookup results for t
I have forgot to include the matcher I used for the test:
```
AST_MATCHER_P(CXXRecordDecl, hasMethodOrder, std::vector, Order) {
size_t Index = 0;
for (CXXMethodDecl *Method : Node.methods()) {
if (!Method->isImplicit()) {
if (Method->getName() != Order[Index])
return false;
Hi Lang, Alexey,
I dug deeper into this and it seems like the issue happens only when a
**minimal** import is used. LLDB uses the minimal import. CrossTU
static analyzer uses the normal mode.
In normal import mode, in `ImportDeclContext` we do import all the
methods in the correct order. However,
host compiler is being dynamically loaded here? You can
> > check this using 'ldd' (IIRC) on Linux or 'otool -l' on Darwin. Also, did
> > you take the extra step needed to preload the runtime
> > (LD_PRELOAD/DYLD_INSERT_LIBRARIES)?
> >
> > best,
Hi,
I'd like to run the tests, when LLVM, Clang and LLDB are all built with ASAN.
I am using release_60 version of LLDB.
The unittests just run fine, but with `dotest.py`, there is an error.
Maybe the LLDB build does not respect the global -DLLVM_USE_SANITIZER
flag of cmake ?
Any help would be ap
So, on Ubuntu "sudo apt-get remove python-lldb-4.0" solved this issue.
Thanks again for the guidance.
Cheers,
Gabor
On Fri, Jun 29, 2018 at 4:10 PM Gábor Márton wrote:
> I did a search for the "HLOp" symbol and it turned out it is only used by
> the "LLVMSupport.so" lib.
> So, this did not help
blldbTarget.a
> lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a
> lib/liblldbInterpreter.a lib/liblldbExpression.a
> lib/liblldbPluginProcessUtility.a lib/liblldbPluginCPlusPlusLanguage.a
> lib/liblldbPluginObjCLanguage.a lib/liblldbPluginExpressionParserClang.a
> lib/liblldbPluginE
to believe that this is caused by an uncommon (for lldb, at least)
> > >> build configuration. Can you share your cmake configuration?
> > >>
> > >> I suspect TestLinuxCore is also failing due to unexpected build
> > >> configuration, specifically missi
eek.
> On Tue, 26 Jun 2018 at 14:44, Gábor Márton via lldb-dev
> wrote:
> >
> > Hi
> >
> > By using "ninja check-lldb-unit" some of the unit tests fail with the
> tip of the master. (I am using Ubuntu Linux.) The error is always relate
Hi
By using "ninja check-lldb-unit" some of the unit tests fail with the tip
of the master. (I am using Ubuntu Linux.) The error is always related to
the CommandLine options:
FAIL: lldb-Unit ::
ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences
(1
> But there are two issues. First, cast<> has two template arguments, not
one. Second, template instantiation cannot guess what overload of cast
should be used in each case. I'm sorry, but after a few attempts of making
this code to compile, I have to ask you to elaborate a bit more once again.
Yo
Of course, I think there is no need to have different functions which
differ only in the cast operation. We can use a template template parameter
for the cast operation:
template class CastOp, typename DeclTy>
LLVM_NODISCARD bool import(DeclTy *&ToD, DeclTy *FromD) {
if (auto Res =
Hi Aleksei,
I think it is a very good idea to exploit [[nodiscard]] .
On the other hand I find a bit misleading some of the names of these
functions. `importCastedNonNull` does a simple `cast<>` inside, thus
perhaps a name `importAndCast` would better explain what happens.
Similarly, instead of `i
An other idea, couldn't we just pass the cast operation as a template
template parameter?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
52 matches
Mail list logo
