[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

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 Vedant

[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

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

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

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

... >>> >>> 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 information for inlining is often a bit wonky... >>> >

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

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

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

;>>>> API means that fewer tests get written. I see a real need to make >>>>> expressive tests easier to write. >>>>> >>>>> vedant >>>>> >>>>>> On Aug 14, 2018, at 5:38 PM, Jason Molenda wrote: >>>&

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

s 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 get some form > of testing put together for my patches soon.

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

ure, 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@lists.llvm.org>> wrote: > Hel

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

ing the output of the >>>>> lldb driver command into the testsuite and these will eventually make it >>>>> much more difficult to change and improve the driver as we've accumulated >>>>> this style of test. >>>>> >>>&g

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

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

lldb driver -- they're hardcoding the output of the >>>> lldb driver command into the testsuite and these will eventually make it >>>> much more difficult to change and improve the driver as we've accumulated >>>> this style of test. >>>> >>&g

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

mes. >>> >>> f0 = thread.GetFrameAtIndex(0) >>> check that f0.GetFunctionName() == sink >>> check that f0.IsArtifical() == True >>> check that f0.GetLineEntry().GetLine() == expected line number >>> >>> >>> it's more verbose, but it's also

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

and > >> check the stack frames. > >> > >> f0 = thread.GetFrameAtIndex(0) > >> check that f0.GetFunctionName() == sink > >> check that f0.IsArtifical() == True > >> check that f0.GetLineEntry().GetLine() == expected line number > >&g

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

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

al() == 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 > >> On Aug 14, 2018, at 5:31 PM,

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'. > > My motivation is

[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',

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

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

comm 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, 2018

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

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 >

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

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

> On Feb 23, 2018, at 3:17 PM, Vedant Kumar via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Hi, > > At the moment, I'm seeing two issues with the unit tests on my machine. > > First, TestBase.LaunchModePreservesEnvir

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

this afternoon, 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 > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>&

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

[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: >

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

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

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] 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