Re: [lldb-dev] Need help with failing LLDB tests on Windows

run debug version of Python (python_d.exe) to load > debug version of liblldb.dll. I hope this will help you. > > > > *From:* lldb-dev *On Behalf Of *Adrian > McCarthy via lldb-dev > *Sent:* Tuesday, November 10, 2020 4:00 AM > *To:* Ted Woodward > *Cc:* LLDB &

Re: [lldb-dev] Need help with failing LLDB tests on Windows

org> > > Subject: [EXT] Re: [lldb-dev] Need help with failing LLDB tests on > Windows > > > > On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote: > > > For the past couple weeks, I've been trying to figure out why > > > approximately 900+ L

[lldb-dev] Need help with failing LLDB tests on Windows

For the past couple weeks, I've been trying to figure out why approximately 900+ LLDB tests have been failing for me on my local Windows builds. Bisect turned up nothing--the "good" version that was working for me no longer works. Since nobody else seems to be seeing these failures, I suspect

Re: [lldb-dev] lldb10 can not hit break point on windows platform

On Windows, LLVM is migrating to its own debug info reading code (the Native PDB reader) instead of relying on DIA (a Microsoft-provided Windows-only DLL for accessing debug info), so that might explain the difference between the older versions and the current. I don't know enough about LLDB's

Re: [lldb-dev] LLDB build searching for the wrong Python, again.

I've figured out some of the *what* but I still don't understand the *why*. I checked the Windows registry, and found some remnants referencing Python 3.6. I doubt that's related, but I obliterated them anyway. I scrutinized the very noisy output of Cmake and discovered two things: 1. Cmake

[lldb-dev] LLDB build searching for the wrong Python, again.

After rebasing, my local LLDB builds have again broken because it goes looking for the wrong Python DLL. I'm searching through git logs, but I'm not seeing a related change. Does anyone know what causes CMake to get confused about which Python versions are installed? LINK : fatal error LNK1104:

Re: [lldb-dev] [llvm-dev] buildbot slave able to run on python3

Thanks, Galina, for working on the BuildBot update. This update should make it possible for us to stop referring to build machines as "slaves," a terminology change that's overdue. Let us know if there's anything I or others in the community can do to help this along. On Wed, Jun 17, 2020 at

Re: [lldb-dev] LLDB_PYTHON_HOME

of using FindPython3 are worth bumping the minimum required CMake >>>> version (see lldb/CMakeLists.txt, line 2-4). Once LLVM moves to CMake 3.12 >>>> or later, all these problems should be fixed. We can then call FindPython3 >>>> once and rely on everything being

Re: [lldb-dev] LLDB_PYTHON_HOME

vlieghere.com> wrote: >>>> >>>>> Hey Adrian, >>>>> >>>>> Config.h gets generated by expanding the corresponding CMake >>>>> variables. If you look at LLDBConfig.cmake, you can see that >>>>> LLDB_PYTHON

Re: [lldb-dev] LLDB_PYTHON_HOME

red your specified PYTHON_HOME and decided to pick a different Python. >>>> I'm not sure why though, because I use a similar CMake invocation on >>>> Windows. >>>> >>>> > cmake ..\llvm-project\llvm -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo >>>> -DLLVM_ENABLE_PROJECTS=

Re: [lldb-dev] LLDB_PYTHON_HOME

gt; Python3_ROOT_DIR as a hint. Can you give that a try? If that works we > should populate that variable from PYTHON_HOME in > FindPythonInterpAndLibs.cmake. > > Cheers, > Jonas > > On Thu, Feb 27, 2020 at 10:10 AM Adrian McCarthy via lldb-dev < > lldb-dev@lists.llvm.org>

[lldb-dev] LLDB_PYTHON_HOME

Is there documentation on how lldb\include\lldb\host\config.h is generated? I'm again having the problem of the config trying to point to the wrong Python installation. When I run cmake, I explicitly point PYTHON_HOME to C:\Python36 like this: cmake -GNinja

Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

Just guessing: Does either machine have more than one Python installation? Windows Server is, by default, more locked down than the standard editions, which can affect the search path. Perhaps you're not getting the Python you think you're getting on one of the machines. Are both machines

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

Yes, I think it's pretty reasonable to expect a specific version of Python, especially if the pre-built Python DLLs for Windows are still built with versions as old as VS 2013. Once you get to VS 2015 or 2017, I think the compatibility improves. Perhaps the best thing for the pre-built LLDB is

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

ilt Windows LLDB binary has a > dependency on an external python36.dll? > > On 20/11/2019 23:53, Adrian McCarthy via lldb-dev wrote: > > That said, I didn't expect an explicit dependency on python36.dll. > > What kind of behavior did you expect? > > pl > ---

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

Here are some possibly related reviews. Note that some of these were abandoned, but I'm including them because the comments might give some context. https://reviews.llvm.org/D69684 https://reviews.llvm.org/D69931 https://reviews.llvm.org/D67942

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

There has been a lot of churn in the build process for Python on Windows over the past couple months. Older versions included a pre-built Python DLL on Windows because of ABI compatibility. That issue is resolved, though, and I thought that was already over by version 7 or earlier. Because

Re: [lldb-dev] issue with lldb9 and python3.5

+1 Yes, for Windows, I'd be happy if we said Python 3.6+. On Mon, Oct 28, 2019 at 10:07 AM Jonas Devlieghere via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On Mon, Oct 28, 2019 at 10:04 AM Jonas Devlieghere > wrote: > > > > On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard > wrote: > > > > > > On

Re: [lldb-dev] test setup for windows -- makefiles

I'm not sure this is entirely up to date, but I'd start here, especially the Software section: https://llvm.org/docs/GettingStartedVS.html We get most of those unix-y tools on Windows via GnuWin32. For LLDB development, you almost certainly want a Python 3 rather than the recommended 2.7.

Re: [lldb-dev] Who sets the 10-minute timeouts?

On Wed, Aug 14, 2019 at 2:47 PM Jim Ingham wrote: > > > > On Aug 14, 2019, at 1:41 PM, Adrian Prantl via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > > >> On Aug 14, 2019, at 11:26 AM, Adrian McCarthy via lldb-dev < > lld

[lldb-dev] Who sets the 10-minute timeouts?

A recent change is causing several LLDB tests on Windows to fail and several more to time out, which I intend to look into. It appears the timeout period is set to 600 seconds (10 minutes), which seems excessive and causes the Windows build bot to spend lots of time waiting. (e.g.,

[lldb-dev] How to debug "Python memory allocator called without holding the GIL" during LLDB tests?

Several LLDB tests on Windows are now failing for me like this: Fatal Python error: Python memory allocator called without holding the GIL Current thread 0x081c (most recent call first): File "D:\src\llvm\build\mono\lib\site-packages\lldb\__init__.py", line 14461 in GetNumChildren File

Re: [lldb-dev] Symbol Server for LLDB

I know several people here have been looking for a generic, cross-platform way to locate symbols. One idea here was to make the symbol fetcher a Python script that could use the SBAPI to interrogate the debugger to determine what's needed. This isn't that different than a separate binary, but it

Re: [lldb-dev] Trouble running Python tests on Windows

I can confirm that there are problems building with Swig 4. I've also just found that there's a bug in versions of Swig before 4 that makes the code it generates incompatible with Python 3.7. (See lldb-dev@ for a message I just sent out about this.) Python 3.6 with Swig 3.0.12 is working well

[lldb-dev] Swig/Python version incompatibility

tl;dr: To avoid a compatibility problem with Swig, don't upgrade to Python 3.7. While chasing down the cause of lots of lldb test failures on Windows, I discovered that there's a compatibility bug with Python 3.7 and Swig 3.0.12. Python 3.7 tighted up the tp_new API, which SWIG generates calls

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

I'd have no objection to individual .cpp files having a few using declarations for the specific types that file cares about: ... #include "llvm/ADT/ArrayRef.h" #include "llvm/ADT/Optional.h" ... using llvm::ArrayRef; using llvm::Optional; And then the rest of the file

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

I don't have a strong opinion, but I lean against the idea for two reasons: 1. The `llvm::` prefixes don't really hinder readability for me. They're like `std::` prefixes on all the C++ standard library types, which I'm perfectly happy to type and read--moreso than using declarations. Sure,

Re: [lldb-dev] Symbol Server for LLDB

Not currently (at least, not for the platforms I use primarily), but there is definitely interest in a symbol fetcher so there may be somebody working on it. On Sun, Mar 24, 2019 at 11:11 PM Murali Venu Thyagarajan via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello, > > Is there a way to

Re: [lldb-dev] LLDB not loading any debug information on windows

Sorry for the delay. There's definitely something going wrong here. If you specify the .pdb file (target symbols add a.pdb), it iterates through the objfile plugins to see if any match, and none of them do (because a PDB file is not a "module"). If you specify the .exe file (target symbols add

Re: [lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

OK, thanks all for the discussion. I'll try to fix the immediate problems (the build breakage and the Python detection). If I get more ambitious, I'll make another proposal. On Thu, Mar 7, 2019 at 12:55 PM Zachary Turner wrote: > Yes, Pavel pointed out one specific case where it is used, and

[lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

We have a build option to build LLDB without Python. This option is automatically set if Cmake can't find or "validate" your Python distribution. Since LLDB is rarely built with this option, nobody discovers when this configuration breaks. For example, if you try it today, you'll get a handful

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

Zach's right. On Windows, lldb can produce a minidump, but it just calls out to a Microsoft library to do so. We don't have any platform-agnostic code for producing a minidump. I've also pinged another Googler who I know might be interested in converting between minidumps and core files (the

Re: [lldb-dev] problems running the LLDB lit tests on Windows

> Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > > *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of > *Adrian > McCarthy via lldb-dev >

[lldb-dev] problems running the LLDB lit tests on Windows

I'm trying to figure out what's happening with the LLDB lit tests on Windows. I'm not sure how to proceed with debugging this. I execute this command: ninja check-lldb And several things happen very rapidly: 1. On the console, I get one warning that says:

Re: [lldb-dev] postmortem debugging (core/minidump) & modules

On Tue, Apr 10, 2018 at 3:12 PM, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Apr 10, 2018, at 2:30 PM, Leonard Mosescu wrote: > > Thanks Greg! It makes sense and looking at the code it's already > implemented along those lines:

Re: [lldb-dev] Virus in a test file?

It's several tests that use this input. Perhaps rebuilding it with clang-cl and lld-link would change it enough to appease the virus scanner. On Fri, Apr 6, 2018 at 10:59 AM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Best thing I can think of is to delete this test. This

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

Actually, it appears one of the lit tests is unexpectedly passing: Unexpected Passing Tests (1): lldb :: Expr/TestCallStdStringFunction.test lit then returns an error code, and ninja bails before starting the dotest.py tests: FAILED: cmd.exe /C "cd /D D:\src\llvm\build\mono\tools\lldb\lit

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

As of 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> wrote: > Cool, I'll work up a patch for this. > > And thanks for

Re: [lldb-dev] hashing pointers to strings

dn't find any > reference to pubnames in the DWARF 5 draft standard. > > > > We should check with Greg about this, but I don't think we're ever > likely to get any use out of DWARF pubnames tables. We should just delete > this code. > > > > Jim > > > > > &g

[lldb-dev] FYI: LLDB DWARF tests on Windows are broken

It looks like tests of DWARF-specific functionality on Windows are failing because we're actually generating CodeView in a PDB rather than DWARF. For example, TestSignedTypes.py fails for reasons completely unrelated to whether the types are signed or not. Apparently DWARF and CodeView consider

Re: [lldb-dev] PDB symbol reader status?

Basic PDB support is in LLDB if you're running on Windows. LLDB has a SymbolFilePDB plugin that relies on a PDB abstraction in LLVM. There is currently just one implementation of that abstraction, and it relies on DIA, which is a Microsoft-provided DLL on Windows for looking up information in a

Re: [lldb-dev] Prebuilt binary for Windows

> [UCRT] had been pushed to Vista, 7 and 8 via Windows Update I didn't think that was true in general. One of the redist options is to include an MSU in your installer that tells Windows Update to add UCRT to the list of components it updates. So some Vista, 7, and 8 users may have received it

Re: [lldb-dev] logging in lldb

On Wed, Jan 11, 2017 at 10:38 AM, Zachary Turner wrote: > > > On Wed, Jan 11, 2017 at 6:59 AM Pavel Labath wrote: > >> Happy new year everyone. :) >> >> I have refreshed the implementation at >> with something more

Re: [lldb-dev] logging in lldb

> (of those, 7 print the *wrong* function name) I think this is the best argument for automating the source information as much as possible. Refactoring moves stretches of code into new functions. Log lines get copy and pasted. Like comments, the fixed text in the log lines easily gets out of

Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7

I'm not able to repro at head (on Windows 7). On Tue, Dec 6, 2016 at 10:48 AM, Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > I've also never seen either problem. I'm not debugging Windows apps, but > Hexagon apps, running lldb and the Hexagon simulator on Win7. > > -- >

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

ent system. Then remote windows debugging would be possible. It would > end up using thee ProcessGDBRemote.cpp process plug-in then. Then the > ProcessWindows plugin directory would not be needed. Any thoughts on this? > > Greg > > > On Nov 18, 2016, at 4:00 PM, Adrian McCa

[lldb-dev] Refactoring in LLDB Windows Plugin

If you're not working in LLDB's Windows process plugin, you probably don't care about this message. FYI: I'm doing some refactoring (actually unfactoring) in the Windows process plugin. It'll take a series patches over a few days next week. If you're planning on working in this area, please

Re: [lldb-dev] LLDB Evolution - Final Form

My concern about this example: void do_something(foo *p) { assert(p); if (p) p->crash(); } Is that by skipping the operation when the pointer is null is that it's not clear what it should do if it's precondition isn't met. Sure, it won't crash, but it's also not going to "do

Re: [lldb-dev] Passing std::atomics by value

Methods like Address::SetOffset and Address::Slide seem to have data races despite m_offset being atomic. Callers of those methods would have to guarantee that nothing else is trying to write to m_offset. And if they're doing that, then there doesn't appear to be a need for std::atomic on that

Re: [lldb-dev] LLDB Evolution

I assume Christian Convey was referring to clang-format moving the "//breakpoint here" comments in the tests to different lines. On Thu, Aug 11, 2016 at 8:15 AM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > It's not possible. The problem is that lldb was dependent on order of

Re: [lldb-dev] Introductions

Cool. Welcome! I expect that's very do-able (and it was something on my to-do list, eventually). I believe the dump file is relatively trivial. The Windows API (::MiniDumpReadDumpStream) just returns ranges of the memory mapped dump file. I think you could essentially implement that API in a

Re: [lldb-dev] compile failure with VS 2015 Update 3

I left out some words. I meant: The answers on that StackOverflow question claim that 32-bit MSVC never does more than 32-byte alignment *for parameters*. On Thu, Jun 30, 2016 at 3:12 PM, Adrian McCarthy wrote: > `default_stop_addr` is an `Address` which contains a >

Re: [lldb-dev] compile failure with VS 2015 Update 3

Compiling for 32-bit or 64-bit? This question looks relevant: http://stackoverflow.com/questions/21743144/using-stdatomic-with-aligned-classes On Thu, Jun 30, 2016 at 1:19 PM, Philippe Lavoie via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello, > > has anyone tried to compile LLDB with

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

>Version numbers aren't strings, and they aren't floating point numbers, they are a series of integers separated by dots. I can't think of a project where interpreting version numbers that way won't work. TeX (asymptotically approaches pi), METAFONT (asymptotically approaches e), Opera (decimal

Re: [lldb-dev] Listing memory regions in lldb

> > Interestingly when I've worked on Windows core dumps before I've seen that > MiniDump, with the right flags, will deliberately insert a region in the > middle of the memory ranges to represent the unmapped space, on 64 bit it's > quite a large section. Are you saying that's a bug in the

Re: [lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

s.llvm.org> wrote: > > I would be happy to see these files go away if no one is using them... > > > >> On Mar 9, 2016, at 2:32 PM, Adrian McCarthy via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> > >> The test traces directory tends to accumulat

[lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

The test traces directory tends to accumulate thousands and thousands of TestStarted-XXX and TestFinished-XXX files. What purpose do they serve? I assume it's for trying to figure out why something went wrong. If you have a TestStarted-123 without a corresponding TestFinished-123, then you can

Re: [lldb-dev] FYI: a python crash running tests

Did you ever push a fix? I'm still seeing this problem, even after a fresh sync. I'm happy to take a look at it today if you don't already have a fix. On Thu, Mar 3, 2016 at 10:18 AM, Ted Woodward wrote: > I think I see the problem; I’ll push up a fix. > > > > --

[lldb-dev] Minidump support in LLDB

Below is an after-the-fact design doc on the minidump support in LLDB. We don't seem to have a documents repository, so I thought I'd post it here on the mailing list in case anyone wants to know more. Comments and questions welcome. Thanks, Adrian. --- Minidump support in LLDB Adrian

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

t method, the test method has locals, one of >>>>> which >>>>> is a SymbolList, a member of which is symbol context, which has the file >>>>> locked. >>>>> >>>>> Our best guess is that if you have something like this: >>&

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

uess is to try to call ScriptInterpreterPython::Clear within >>> test's tearDown call - e.g., expose Clear method as part of >>> SBCommandInterpreter and call it via SBDebugger::GetCommandInterpreter >>> >>> On Thu, Oct 15, 2015 at 8:50 AM, Adrian McCart

Re: [lldb-dev] Too many open files

Adding a printing destructor to threading.Event seems to aggravate timing problems, causing several tests to fail to make their inferiors and that seemingly keeps us below the open file limit. That aside, the destructor did fire many hundreds of times, so there's not a general problem stopping

Re: [lldb-dev] Too many open files

Different tools are giving me different numbers. At the time of the error, Windbg says there are about 2000 open handles, most of them are Event handles, not File handles. That's higher than I'd expect, but not really concerning. Process Explorer, however, shows ~20k open handles per Python

Re: [lldb-dev] Too many open files

Thanks for the ideas. With `--test-runner-name threading-pool`, I get too many open files. With `--test-runner-name multiprocessing-pool`, the suite runs fine. My machine has 40 logical cores. With `--threads=20`: SUCCESS (and perhaps _faster_). With `--threads=30`: SUCCESS. With