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
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
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
LLVM_NODISCARD bool import(DeclTy *, DeclTy *FromD) {
if (auto
> 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.
e, 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 related
> to the C
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
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
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,
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;
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
n (for lldb, at least)
> > >> build configuration. Can you share your cmake configuration?
> > >>
> > >> I suspect TestLinuxCore is also failing due to unexpected build
> > >> configuration, specifically missing targets in llvm (mips?). I'll try
> >
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
ib/liblldbBreakpoint.a lib/liblldbDataFormatters.a
> lib/liblldbInterpreter.a lib/liblldbExpression.a
> lib/liblldbPluginProcessUtility.a lib/liblldbPluginCPlusPlusLanguage.a
> lib/liblldbPluginObjCLanguage.a lib/liblldbPluginExpressionParserClang.a
> lib/liblldbPluginExpressionParserGo.a
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
--
> 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 that t
ion 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
>> To: lldb-dev@lists.
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 update
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
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) ?
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 ::
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
> 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
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
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
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:
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 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/
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
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
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
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
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
t;> target_tport = 0x0103, pid = 27646, ) => 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) would tell us more. Search for
>>> debugserver an
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
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
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'
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
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
nd 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árton via lldb-dev <
> lldb-dev@lists.llvm.or
es. 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árton via lldb-dev <
>> l
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
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,
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!
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
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
46 matches
Mail list logo
