Hi,
After compiling an example.cpp file with "-c -ffunction-sections" and
linking with "--gc-sections" (used ld.lld), I am still seeing debug info
for the sections deleted by garbage collector in the generated executable.
Are there any compiler/linker options and/or other tools in LLVM to get rid
Yes, I think that would be pretty cool. It is along the same lines we've been
talking about with using "ProcessMock", "ThreadMock" etc. plugins. However, I
think you need both. For instance if we bobble a gdb-remote packet, you will
see that in a bad state of one of these higher level state d
There are a couple of problems with using these reproducers in the testsuite.
The first is that we make no commitments that the a future lldb will implement
the "same" session with the same sequence of gdb-remote packet requests. We
often monkey around with lldb's sequences of requests to make
By the way, several weeks / months ago I had an idea for exposing a
debugger object model. That would be one very powerful way to create
reproducers, but it would be a large effort. The idea is that if every
important part of your debugger is represented by some component in a
debugger object mod
I assume that reproducing race conditions is out of scope?
Also, will it be possible to incorporate these reproducers into the test
suite somehow? It would be nice if we could create a tar file similar to a
linkrepro, check in the tar file, and then have a test where you don't have
to write any p
Great, thanks. This means that the lldb-server issues are not in scope for
this feature, right?
On Wed, Sep 19, 2018 at 10:09 AM, Jonas Devlieghere
wrote:
>
>
> On Sep 19, 2018, at 6:49 PM, Leonard Mosescu wrote:
>
> Sounds like a fantastic idea.
>
> How would this work when the behavior of the
That's okay, but is it possible to skip a few tests, when using lit? I was
thinking about moving the test files I want to skip, but that has obvious
drawbacks. Also --filter does not seem so useful in this case.
On Wed, 19 Sep 2018, 18:46 , wrote:
> Unless you pass --no-multiprocess to dotest,
> On Sep 19, 2018, at 6:49 PM, Leonard Mosescu wrote:
>
> Sounds like a fantastic idea.
>
> How would this work when the behavior of the debugee process is
> non-deterministic?
All the communication between the debugger and the inferior goes through the
GDB remote protocol. Because we captu
Sounds like a fantastic idea.
How would this work when the behavior of the debugee process is
non-deterministic?
On Wed, Sep 19, 2018 at 6:50 AM, Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi everyone,
>
> We all know how hard it can be to reproduce an issue or crash in L
Unless you pass --no-multiprocess to dotest, it should detect how many cores
your system has and use them.
--
Ted Woodward
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-Original Message-
Fro
Hi Gabor,
The revision Hans mentioned is essentially the revision that created
svn tag. Content-wise it's equal to the tip of release_70 branch.
On Wed, Sep 19, 2018 at 6:21 PM Gábor Márton via cfe-dev
wrote:
>
> Hi Hans,
>
> > The final version of 7.0.0 has been tagged from the branch at r342370
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
Hi everyone,
We all know how hard it can be to reproduce an issue or crash in LLDB. There
are a lot of moving parts and subtle differences can easily add up. We want to
make this easier by generating reproducers in LLDB, similar to what clang does
today.
The core idea is as follows: during normal
I am pleased to announce that LLVM 7 is now available.
Get it here: https://llvm.org/releases/download.html#7.0.0
The release contains the work on trunk up to SVN revision 338536 plus
work on the release branch. It is the result of the community's work
over the past six months, including: functio
16 matches
Mail list logo
