Thank you all for your time in responding to my query.
My understanding was also similar to what you all mentioned here but wanted
to check if there are any recent developments in solving this problem.
Thanks,
Ramana
On Thu, Sep 20, 2018 at 9:32 PM, Rui Ueyama wrote:
> Right. Technically we ca
> On Sep 20, 2018, at 4:16 AM, Zachary Turner wrote:
>
> For the first, I think 99% of the time the bug is not caused by the sequence
> of gdb remote packets. The sequence of gdb remote packets just happens to be
> the means by which the debugger was put into the state in which it failed.
When I am working on some changes and there are tests I know I've broken but
don't want to fix just yet, I just edit the test file and skip it using the
skip decorators. You have to remember not to check in the skips when you check
in whatever change you are making - but presumably by the time
> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
> Davide Italiano via llvm-dev
> Sent: Thursday, September 20, 2018 10:55 AM
> To: ramana.venka...@gmail.com; Cary Coutant
> Cc: llvm-dev; LLDB
> Subject: Re: [llvm-dev] [lldb-dev] [LLD] How to get
On Wed, Sep 19, 2018 at 8:35 PM Venkata Ramanaiah Nalamothu via
lldb-dev wrote:
>
> 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 gene
> On Sep 20, 2018, at 2:25 PM, Gábor Márton wrote:
>
> Hi Jonas,
>
> Thanks for the clarification.
> Finally I could skip some of the tests by using a negative lookahead
> regex passed to --filter. I wouldn't say that this is so convenient
> and easy to overview, but works.
> For example, to sk
Hi Jonas,
Thanks for the clarification.
Finally I could skip some of the tests by using a negative lookahead
regex passed to --filter. I wouldn't say that this is so convenient
and easy to overview, but works.
For example, to skip the TestCalculatorMode.py and TestPrintArray.py
tests I used the fo
For the first, I think 99% of the time the bug is not caused by the
sequence of gdb remote packets. The sequence of gdb remote packets just
happens to be the means by which the debugger was put into the state in
which it failed. If there is another, stable way of getting the debugger
into the sam
When using lit as the driver (which is the case for check-lldb), the test
granularity is at file-level: lit invokes dotest.py for every test file. You
should be able to specify files to skip with lit's --filter.
With regards to threading, lit will schedule one instance of dotest.py on every
threa
