[lldb-dev] Allowing PlatformPOSIX::LoadImage to lazy bind symbols

Hello, I'd like to allow PlatformPOSIX::LoadImage to lazy bind symbols (instead of failing to load a library if one of its exported symbols is in fact unavailable). Essentially, I'd like for RTLD_LAZY to replace the current default of RTLD_NOW. In general, it seems like the debugger should all

Re: [lldb-dev] Deleting lldb/utils/test/

Sounds good, deleted as of 158f3360. > On Oct 27, 2020, at 10:46 AM, Jonas Devlieghere wrote: > > Last time I looked at these nothing seemed relevant (anymore) to me either. > I'm in favor of getting rid of the directory. > > On Tue, Oct 27, 2020 at 10:26 AM Ve

[lldb-dev] Deleting lldb/utils/test/

Hi, I'm considering deleting the lldb/utils/test/ directory as a cleanup. Does anyone has a reason to keep these scripts around? Here are the files in the directory: % ls lldb/utils/test README-disasm README-run-until-faultedlldb-disasm.py main.c

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

Hi Walter & Greg, Thanks for sharing this RFC, and for your work in this area. > On Sep 17, 2020, at 5:28 PM, Walter via lldb-dev > wrote: > > Hi all, > > Here I propose, along with Greg Clayton, Processor Trace support for LLDB. > I’m attaching a link to the document that contains this pro

Re: [lldb-dev] [llvm-dev] Why is lldb telling me "variable not available"?

> On Feb 26, 2020, at 3:29 PM, Brian Gesiak via lldb-dev > wrote: > > Vedant, Jeremy, > > Thanks a ton! I copied ASan's use of 'replaceDbgDeclare', think that worked! > > https://github.com/modocache/llvm-project/commit/afbc04e1dcba has some > extremely quick and dirty changes I made (with n

Re: [lldb-dev] [llvm-dev] Why is lldb telling me "variable not available"?

I haven't fully parsed this thread (sorry!), but I wanted to briefly mention that the SafeStack & ASan passes both do something similar (I think): move local variables backed by allocas onto a separate stack. These passes use replaceDbgDeclare to rewrite dbg.declares s.t. they point into the new

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

;> instance or just innovative and lldb will have to cope... >>> >>> Considered as a test about data formatters, it is a little silly to try to >>> drive it using next's since the push_backs are going to introduce a bunch >>> of inlining and the debug i

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

No worries, I’ve relaxed the test for now in r343899 to get the bots going again. Essentially, the test will just step one more time to make sure the full effect of the push_back() is visible. If folks on lldb-dev (cc’d) have a better idea we can try it out. vedant > On Oct 5, 2018, at 4:15 PM

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

Sadly, after this commit TestDataFormatterLibcxxList.py started failing with: ``` output: Process 67333 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x00010eb0 a.out`main at main.cpp:33:16 30 (text_list.push_back(std::string("smart"))

Re: [lldb-dev] Using FileCheck in lldb inline tests

27;d be easy to update FileCheck tests when changing the debugger (this >>>>> happens all the time in clang/swift). OTOH, the verbosity of the python >>>>> API means that fewer tests get written. I see a real need to make >>>>> expressive tests easier t

Re: [lldb-dev] Using FileCheck in lldb inline tests

the other hand, it’s a larger >> effort to create this system, but I think long term it would pay back >> enormously (it’s even useful as a general purpose debugger feature, not >> limited to testing) > > I'd volunteer to work on that. At the moment I really need to

Re: [lldb-dev] Using FileCheck in lldb inline tests

general purpose debugger feature, not > limited to testing) I'd volunteer to work on that. At the moment I really need to get some form of testing put together for my patches soon. vedant > > On Tue, Aug 14, 2018 at 5:31 PM Vedant Kumar via lldb-dev > mailto:lldb-dev@lis

Re: [lldb-dev] Using FileCheck in lldb inline tests

;>> I'd argue against this approach because it's exactly why the lit tests >>>>> don't run against the lldb driver -- they're hardcoding the output of the >>>>> lldb driver command into the testsuite and these will eventually make it >

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 15, 2018, at 10:15 AM, Jim Ingham via lldb-dev > wrote: > > > >> On Aug 14, 2018, at 7:48 PM, Zachary Turner via lldb-dev >> wrote: >> >> >> On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda wrote: >> >> >>> On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote: >>> >>> Having bugs

Re: [lldb-dev] Using FileCheck in lldb inline tests

>>>> I'd argue against this approach because it's exactly why the lit tests >>>> don't run against the lldb driver -- they're hardcoding the output of the >>>> lldb driver command into the testsuite and these will eventually make it >>

Re: [lldb-dev] Using FileCheck in lldb inline tests

> >>> This is a perfect test for a normal SB API. Run to your breakpoints and >>> check the stack frames. >>> >>> f0 = thread.GetFrameAtIndex(0) >>> check that f0.GetFunctionName() == sink >>> check that f0.IsArtifical() == True >>> check that

Re: [lldb-dev] Using FileCheck in lldb inline tests

. > >> > >> This is a perfect test for a normal SB API. Run to your breakpoints and > >> check the stack frames. > >> > >> f0 = thread.GetFrameAtIndex(0) > >> check that f0.GetFunctionName() == sink > >> check that f0.IsArtifical()

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 14, 2018, at 6:07 PM, Zachary Turner wrote: > > > > On Tue, Aug 14, 2018 at 5:56 PM Vedant Kumar > wrote: > > >> On Aug 14, 2018, at 5:34 PM, Zachary Turner > > wrote: >> >> I’ve thought about this in the past but the conclusion I

Re: [lldb-dev] Using FileCheck in lldb inline tests

> check that f0.IsArtifical() == True > check that f0.GetLineEntry().GetLine() == expected line number > > > it's more verbose, but it's also much more explicit about what it's checking, > and easy to see what has changed if there is a failure. > > > J

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Tue, Aug 14, 2018 at 5:31 PM Vedant Kumar via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > Hello, > > I'd like to make FileCheck available within lldb inline tests, in addition to > existing helpers like 'runCmd' and 'expect'.

[lldb-dev] Using FileCheck in lldb inline tests

Hello, I'd like to make FileCheck available within lldb inline tests, in addition to existing helpers like 'runCmd' and 'expect'. My motivation is that several tests I'm working on can't be made as rigorous as they need to be without FileCheck-style checks. In particular, the 'matching', 'subs

Re: [lldb-dev] run tests with ASAN (dotest.py)

Hi Gábor, That symbol appears to be defined in compiler-rt/lib/asan/asan_rtl.cc , so it should be provided by the asan runtime. Are you sure that the runtime expected by the host compiler is being dynamically loaded here? You can check this using 'ldd' (IIRC) on Linux or 'o

Re: [lldb-dev] increase timeout for tests?

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > >> -----Original Message- >> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Vedant >> Kumar via lldb-dev >> Sent: Tuesday, March 13

Re: [lldb-dev] increase timeout for tests?

As a first step, I think there's consensus on increasing the test timeout to ~3x the length of the slowest test we know of. That test appears to be TestDataFormatterObjC, which takes 388 seconds on Davide's machine. So I propose 20 minutes as the timeout value. Separately, regarding x-failed pe

Re: [lldb-dev] tests xfailed globally with radar references

I took a first cut at this in r327463. vedant > On Mar 13, 2018, at 2:39 PM, Vedant Kumar wrote: > > Hi Ted, > > Thanks for bringing this up. I'll volunteer to take a look at these tests and > file PRs where appropriate. I should get to this within a day or two. > > vedant > >> On Mar 13, 2

Re: [lldb-dev] tests xfailed globally with radar references

Hi Ted, Thanks for bringing this up. I'll volunteer to take a look at these tests and file PRs where appropriate. I should get to this within a day or two. vedant > On Mar 13, 2018, at 10:31 AM, Ted Woodward via lldb-dev > wrote: > > I was investigating TestWatchedVarHitWhenInScope.py, whic

Re: [lldb-dev] Current state of the unit tests

> On Feb 23, 2018, at 3:17 PM, Vedant Kumar via lldb-dev > wrote: > > Hi, > > At the moment, I'm seeing two issues with the unit tests on my machine. > > First, TestBase.LaunchModePreservesEnvironment is failing: > >> [ RUN ] TestBase.LaunchMode

Re: [lldb-dev] Current state of the unit tests

it seems ninja check-lldb runs only the lit tests and > not the dotest.py tests. Was this an intentional change? > > On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > Cool, I'll work up a patch for this. > > And t

Re: [lldb-dev] Current state of the unit tests

Cool, I'll work up a patch for this. And thanks for commenting on PR36494, I'm testing a fix out right now :). vedant > On Feb 23, 2018, at 3:35 PM, Pavel Labath wrote: > > On 23 February 2018 at 15:17, Vedant Kumar wrote: >> Second, TestClient::SendMessage is generating quite a lot of "INFO"

[lldb-dev] Current state of the unit tests

Hi, At the moment, I'm seeing two issues with the unit tests on my machine. First, TestBase.LaunchModePreservesEnvironment is failing: > [ RUN ] TestBase.LaunchModePreservesEnvironment > /Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:30: > Fa

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

Lit provides some helpful utilities which make it easier to write portable tests. E.g %t, for temporary test directories, and portable replacements for things like `diff -r`. This is how compiler-rt's end-to-end tests are structured, and we haven't needed any build-system like functionality ther

Re: [lldb-dev] Questions about the LLDB testsuite and improving its reliability

I would prefer having all of our test dependencies tracked by CMake for all the reasons Zach brought up, but I think we should defer that undertaking until after the bots are more stable. We have some immediate problems caused by stale in-tree test artifacts. As a first milestone, it'd be great

Re: [lldb-dev] [llvm-dev] [5.0.0 Release] Release Candidate 2 tagged

Hi, There are no regressions from RC1 on Darwin. I've uploaded clang+llvm-5.0.0-rc2-x86_64-apple-darwin.tar.xz to /data/testers-uploads. SHA 1: 8ffaf7ab44e7e7fe582dc9573aad9745ee63e186 SHA 256: 578c18ceb6485fd2fcac329a7a5fe7e55d1c70669a942651d49cdc3ea626a5af I've also resurrected the Darwin bo

Re: [lldb-dev] [Release-testers] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

I've uploaded the x86_64/Darwin package: SHA1(clang+llvm-5.0.0-rc1-x86_64-apple-darwin.tar.xz) = 66cb113cb735b7f0d3b7eebe155969f069c8a684 SHA256(clang+llvm-5.0.0-rc1-x86_64-apple-darwin.tar.xz) = ca13407528536f0c4e9b5bf00115a2f3d65d73f512737d334f69ad53bd18101c thanks! vedant > On Aug 3, 2017,

Re: [lldb-dev] Code Coverage with GCOV

Is it possible that the files are written to an unexpected directory? Have you tried running the program under strace/dtruss to conclusively determine whether or not the files are being written? Could you try running lldb-server in lldb and setting a breakpoint on `llvm_gcda_start_file'? vedant >

Re: [lldb-dev] Code Coverage with GCOV

Hi Ravitheja, Could you show us the diff to your cmake configuration? You may want to take a look at how the LLVM_BUILD_INSTRUMENTED cmake option is implemented to double-check that you've got something reasonable (see: llvm/CMakeLists.txt and cmake/modules/HandleLLVMOptions.cmake). Also, you may

Re: [lldb-dev] LLDB Evolution

FWIW, as a happy lldb user, it's exciting to read about these planned developments. I have two follow-up questions about the section on 'Testing Strategy Evaluation': (1) what is lldb's policy on including test updates with bug fix commits and functional changes, and (2) how is this policy enforce

[lldb-dev] Leaks from static variables

Hi lldb-dev, It looks like the debugger initializes static variables in llvm (see: SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up. Does this cause memory leaks? I'd assumed that it's necessary to call llvm_shutdown() somewhere to avoid this kind of leak. Is there a bu