Re: [lldb-dev] hang bug in lldb-mi -var-update

s when you have an array with a million entries? > Long delay. Aggregate types should never say they changed. Only SBValue > objects that have values should claim to change. > > Greg > > > > On Aug 25, 2017, at 10:42 AM, Ted Woodward via lldb-dev d...@lists.llvm.org> w

Re: [lldb-dev] Linking the lldb C++API/library with other projects

lldb-mi, in /tools/lldb-mi , loads the shared library and uses the SB APIs. That might be a good start for you. main() is in MIDriverMain.cpp. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Proje

[lldb-dev] warnings in source/Plugins/Language/ObjC/NSArray.cpp

r310959 contains GNU extensions in source/Plugins/Language/ObjC/NSArray.cpp. Building with clang 3.8 and -WError, I see: /local/mnt/workspace/bots/llvmhexbot-sles11_sd_48/hexagon-clang-83/build/llv m/tools/lldb/source/Plugins/Language/ObjC/NSArray.cpp:181:7: error: anonymous structs are a GNU exte

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

I recently added Hexagon Linux support to lldb-server; I did what Greg suggested below - subclassed NativeRegisterContextLinux, like the other architectures did. I also added the software breakpoint opcode to NativeProcessLinux. After that, it was just a matter of getting the register accessor

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

We've done something similar in-house running on a Snapdragon with an ARM and a Hexagon DSP. We use Android Studio to debug an app on the ARM that sends work down to the Hexagon, running an app under Linux. On the Hexagon we ran lldb, and were able to debug both apps talking to each other. -- Q

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

We treat them as 2 separate targets. We're actually running 2 separate lldb instances - one in Android Studio, and 1 in a shell on Hexagon Linux. Android Studio is running on the host (x86 Linux or Windows PC). We have an adb shell open to android on the ARM, and from there ssh to Linux on the H

Re: [lldb-dev] check-lldb will start using in-tree clang by default

I think if clang exists in-tree, it should be used. If it doesn't, the compiler used to build lldb should be used. Unless, of course, the compiler is specified with the cmake variables. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a L

Re: [lldb-dev] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

We had the same problem internally on our bots. A clean build blew away the cmake caches and fixed the problem. Ted -- 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] SB Headers not in install?

In r309021, the headers in include/lldb/API were excluded from the install target. From cmake/modules/LLDBConfig.cmake: + PATTERN "API/*.h" EXCLUDE Are the SB Headers supposed to be excluded from an install? I just did "ninja install" from top of tree and the SB Headers are not there. Ted

Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu

I ran into the same problem with lldb 3.8 on Ubuntu 14.04. I created symlinks to get things working right. Now I can run "lldb" and it finds lldb-server. In /usr/bin: 0 lrwxrwxrwx 1 root root 26 Nov 17 15:22 /usr/bin/lldb -> /usr/lib/llvm-3.8/bin/lldb* 0 lrwxrwxrwx 1 root root 24 Jul 18 11:06 /u

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

> -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg > Clayton via lldb-dev > Sent: Wednesday, December 20, 2017 12:41 PM > To: Pavel Labath > Cc: lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] Resolving dynamic type based on RTTI fails in c

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

I disagree that understanding CMake is required to build LLVM. When I build top-of-tree on Linux (as opposed to a build that is Hexagon only) I make a build directory at the same level as my checkout, and simply run “cmake ../llvm”. I don’t need to know anything. -- Qualcomm Innovation Cent

[lldb-dev] display register fields?

Is there a way to define and display register fields, like gdb? Or would this need to be done in python? Example: (gdb) p/x $vac0 $3 = {value = 0xedcba111, fields = {LENGTH = 0x111, SRC4_BANK = 0xa, SRC3_BANK = 0xb, SRC2_BANK = 0xc, SRC1_BANK = 0xd, DEST1_BANK = 0xe}} -- Qualcomm Innovatio

Re: [lldb-dev] problem with TestLoadUnload.py

I tried to put @skipIf(...) before setUp, but it didn't work. Currently I have the build inside an if, checking for Hexagon. We don't support this use of shared libraries, so all tests are skipped. I certainly don't want to build the testcase 6 times, given that we're moving away from that! But we

[lldb-dev] Test fails with mutex lock fail?

Has anyone seen anything like this? RESULT: PASSED (1 passes, 0 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes) terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument [TestDataFormatterVarScriptFormatting.py FAILED] It s

Re: [lldb-dev] Command history line editing

It's not just Apple that avoids GPL. Many LLVM users cannot use GPL. Adding GPL code to LLDB is a non-starter. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -Original Message- > From:

Re: [lldb-dev] Command history line editing

@lists.llvm.org> ] On Behalf Of Ted > Woodward via lldb-dev > Sent: Wednesday, March 07, 2018 9:40 AM > To: 'Jan Kratochvil'; 'William Schmidt'; lldb-dev@lists.llvm.org > <mailto:lldb-dev@lists.llvm.org> > Subject: Re: [lldb-dev] Command history line edi

Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'

Also see http://llvm.org/docs/Contributing.html -- Qualcomm Innovation Center, Inc. The 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

[lldb-dev] tests xfailed globally with radar references

I was investigating TestWatchedVarHitWhenInScope.py, which tests that a watchpoint is hit in scope and not hit when out of scope. It's xfailed due to a radar: @unittest2.expectedFailure("rdar://problem/18685649") This is an actual bug - watchpoints are hit when the address is modified but the

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

I don't see 22 lldb-mi tests xfailed everywhere. I see a lot of tests skipped, but those are clearly marked as skip on Windows, FreeBSD, Darwin, Linux. I've got a good chunk of the lldb-mi tests running on Hexagon. I don’t want them deleted, since I use them. lldb-mi tests can be hard to debug, b

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

You might not need non-stop mode to debug both the CPU and GPU. We did a similar thing, using lldb to debug an Android app and an app running on the Hexagon DSP under Linux. We didn’t use the same lldb, but that’s because Android Studio doesn’t know about Hexagon. The Android app was debugged wi

[lldb-dev] Can I call a python script from LLDB c++ code?

LLDB for Hexagon can automatically launch and connect to the Hexagon simulator, much like LLDB can launch and connect to debugserver/lldb-server. I've got a copy of GDBRemoteCommunication::StartDebugserverProcess that does this. A copy because there are feature incompatibilities between hexagon-sim

Re: [lldb-dev] Can I call a python script from LLDB c++ code?

> To: Ted Woodward > Cc: lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] Can I call a python script from LLDB c++ code? > > > > > On Apr 3, 2018, at 12:18 PM, Ted Woodward via lldb-dev d...@lists.llvm.org> wrote: > > > > LLDB for Hexagon can automatically

Re: [lldb-dev] Advice on architectures with multiple address spaces

Hexagon has a single address space, so we don't need to do anything like this. When I worked on Motorola 56xxx DSPs we had memory spaces, but we didn't use RSP. We had our own protocol that used a struct for addreses, with the space (an enum, defined per supported core) and a uint32_t (later 2

Re: [lldb-dev] Proposal: Using LLD in tests

Our Windows buildbots use msys for gnuisms. The makefiles in the test suite run fine with minimal modifications (just the object delete hack Zach put in to use del instead of rm; msys make doesn't accept cmd syntax while Cygwin make does). Now, that's using clang to build Hexagon binaries, but

[lldb-dev] r329889 - Use in-tree dsymutil on Darwin

r329889 says "Use in-tree dsymutil on Darwin", but it's got these change in test/CMakeLists.txt: -set(LLDB_TEST_DEPS lldb) +set(LLDB_TEST_DEPS lldb dsymutil) ... + --dsymutil $ These changes aren't gated by a check for Darwin, so they happen on all systems. On my machine (Ubuntu 14), which doe

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

See my comment in https://reviews.llvm.org/D45333 . r330275 changed how lldb’s lit tests were set up. This gives cmake errors using the Visual Studio generator; I wouldn’t be surprised if what you’re seeing using ninja is the same issue. Short version: the cmake code that sets up the lit

Re: [lldb-dev] Welcome Alexander!

You'll still need HandleCommand for pass through commands. lldb commands send to lldb-mi are handled normally, so something like "file a.out" would set up a target using a.out. "-interpreter exec console " does the same thing. Other than that, I'm all for cleaning up lldb-mi. There were some fu

Re: [lldb-dev] Advice on architectures with multiple address spaces

You can conceptually take this a step further. I used to work at Freescale, and supported SoCs with multiple heterogeneous cores. I provided memory spaces that let the user access these memory views: - DCSR (debug memory, a separate bus) through the SoC - CCSR (memory mapped config registers) th

Re: [lldb-dev] LLDB fails to load C++ Plugin (sharedlib) - error: this file does not represent a loadable dylib

Also try running ldd /home/bkebianyor/eclipse-workspace/Model_LLDB_Debugger/Debug/libModel_LLDB_Debugger.so That will list dependencies that the loader can and cannot resolve. A possible alternative to a plugin could be to use "breakpoint set -p", which does a regular expression match on the so

Re: [lldb-dev] error: process launch failed: Lost debug server connection

FYI - the color you picked for this makes it unreadable against a white background. I had to convert it to plain text to read it. The error message “Lost debug server connection” occurs if the platform isn’t connected and it is not a host platform. What do you get if you type “platform st

Re: [lldb-dev] Cannot install from source

When I do a build on Linux, in /lib I see a directory called python2.7, with a subdirectory site-packages. Do you not see this? Are you building with a different python version than 2.7.x? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora

Re: [lldb-dev] Cannot install from source

It should be built by the “lldb” target. What does that do? -- 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 Quaquaraqu

[lldb-dev] Top of tree lldb crashes running target modules dump symfile twice

I have a very simple testcase, from the libc++ tests. get_id.pass.cpp. #include #include int main() { std::thread::id id = std::this_thread::get_id(); std::thread::id id2 = std::thread::id(); assert(id != std::thread::id()); } I built it with clang 3.8.0. I get the crash when I bui

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

Instead of setting the sysroot, try the command image search-paths add / /path/to/remote/shared/libraries/ That adds to the list that the dynamic loader uses to map shared object paths. It uses a simple text substitution, so in the above case, /usr/lib/libc.so Becomes /path/to/remote/sh

[lldb-dev] Problem with address breakpoints

Hi Jim, I found a breakpoint problem. Setting a breakpoint by address doesn't work if the process isn't running. I traced it back to r322348, "Fix Breakpoint::RemoveInvalidLocations to fix the exec testcase.", from January 11. With ToT from a few days ago on x86_64 Linux, I get the address of mai

[lldb-dev] Odd intermittent test error

Does anyone know what causes this? I see it on our bots intermittently, but haven't been able to reproduce it locally. The test passes, but something unnamed crashes, and the test is marked as failed. TEST 'lldb-Suite :: functionalities/data-formatter/synthcapping/TestSyn

Re: [lldb-dev] how to set a watchpoint on an "unsigned short" parameter ?

"w s v x" would be the command you want. (lldb) b f Breakpoint 1: where = watch`f + 12 at watch.c:5:4, address = 0x50ec (lldb) r hexagon-sim INFO: The rev_id used in the simulation is 0x4060 (v60a_512) hexagon-sim INFO: Setting up debug server on port 57824 Process 1 launched: '/usr2/tedw

Re: [lldb-dev] how to set a watchpoint on an "unsigned short" parameter ?

I don't see anything on this line that would change x: fprintf(stderr, "some string %lu %c\n", r==(void*)0UL)? 255UL : A_MACRO(r), x? '0' : '1' ); I suggest you set a breakpoint on the line and a breakpoint on the next line. Ver

Re: [lldb-dev] [RFC]The future of pexpect

> -Original Message- > From: lldb-dev On Behalf Of Pavel Labath > via lldb-dev > Sent: Thursday, February 21, 2019 8:35 AM > To: Davide Italiano > Cc: LLDB > Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect > > On 21/02/2019 00:03, Davide Italiano wrote: > > I found out that t

Re: [lldb-dev] When should ArchSpecs match?

Hexagon uses “hexagon-unknown-elf” as its triple when running standalone (no OS) or with QuRT (our embedded OS), which expands to “hexagon-unknown-unknown-elf” sometimes, or “hexagon-unknown--elf” other times. For Linux we use “hexagon-unknown-linux”. One issue I’ve seen is the Linux platform w

Re: [lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded

Hi Nat!, The best way to do this is to go to http://reviews.llvm.org . Under Differential, click Create Diff, then paste in the raw diff for your patch. We like to see a full context diff, so reviewers can easily see the full file. More info on how to submit a patch here: http://llvm.org/docs/Co

[lldb-dev] ThreadSanitizer reports lock-order-inversion running lldb on Ubuntu 14.04

We've been seeing intermittent test failures in some lit tests with this error message: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument We've only seen it on a buildbot running on SLES 11 - we can't reproduce it on our Ubuntu machines.

Re: [lldb-dev] ThreadSanitizer reports lock-order-inversion running lldb on Ubuntu 14.04

Some more info from my team: Debugger:Clear() is calling StopEventHandlerThread followed by a m_listener_sp->Clear() and from what I can tell the EventHandlerThread isn't fully stopped prior to the Clear being called. From: lldb-dev On Behalf Of Ted Woodward via lldb-dev Sent: Frida

[lldb-dev] Where did the python/c++ API documentation go?

The new LLDB website at http://lldb.llvm.org has an external resources page: http://lldb.llvm.org/resources/external.html It has 2 entries on it for Documentation: https://lldb.llvm.org/python_reference/index.html https://lldb.llvm.org/cpp_reference/html/index.html Both of these lead to "404 Not

Re: [lldb-dev] Where did the python/c++ API documentation go?

Ted Woodward > Cc: LLDB > Subject: [EXT] Re: [lldb-dev] Where did the python/c++ API documentation > go? > > > > > On Apr 22, 2019, at 10:59 AM, Ted Woodward via lldb-dev d...@lists.llvm.org> wrote: > > > > The new LLDB website at http://lldb.

Re: [lldb-dev] LLDB Website

That's the issue - lldb-python-doc depends on liblldb. From docs/CMakeLists.txt: if(EPYDOC_EXECUTABLE) find_program(DOT_EXECUTABLE dot) if(DOT_EXECUTABLE) set(EPYDOC_OPTIONS ${EPYDOC_OPTIONS} --graph all --dotpath ${DOT_EXECUTABLE}) endif() set(DOC_DIR "${CMAKE_CURRENT_SOURCE_

[lldb-dev] Odd behavior with test TestThreadSelectionBug.py

This test uses the responder and a python OS plugin. When I run the full test suite, it passes, with this thread list: runCmd: thread list output: Process 1 stopped * thread #1: tid = 0x0001, 0x, name = 'one', queue = 'queue1' thread #2: tid = 0x0002, 0x, name = 'two', queue = 'q

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

Run the cmake gui, and point it to the correct source and build directories. Look for key "SWIG_EXECUTABLE". If it doesn't exist, set it to your swig exe. Mine is C:/swigwin-3.0.12/swig.exe , for example. If you change it, hit the configure and then generate buttons, then rebuild and rerun the t

Re: [lldb-dev] Disassembling issue

The error is coming from source/Commands/CommandObjectDisassemble.cpp . It’s not able to create the disassembler for your architecture. The call to Disassembler::FindPlugin fails. My guess is something in the call to MCDisasmInstance::Create in source/Plugins/Disassembler/llvm/DisassemblerLLVMC.

Re: [lldb-dev] Disassembling issue

Hi Romaric, The call to Disassembler::FindPlugin should have arch set to your triple. If m_options.arch is not set on the disassembly command line, it will get it from the target: if (!m_options.arch.IsValid()) m_options.arch = target->GetArchitecture(); That leads me to wonder if your

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

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 for me on Windows. On Fri, May 31, 2019 at 9:15 AM Ted Woodward via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: Run the cmak

Re: [lldb-dev] Enabling single-step mode and acting on each executed instruction

You want to set up a stop-hook. See “help target stop-hook”, specifically “help target stop-hook add”. target stop-hook add -o “register read pc” will read the pc each time the target stops. From: lldb-dev On Behalf Of Vangelis Tsiatsianas via lldb-dev Sent: Friday, June 28, 2019 6:16 AM To: v

Re: [lldb-dev] [RFC] Removing lldb-mi

We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really like to keep it! 😊 Ted From: lldb-dev On Behalf Of Jonas Devlieghere via lldb-dev Sent: Monday, July 1, 2019 5:09 PM To: LLDB Subject: [EXT] [lldb-dev] [RFC] Removing lldb-mi Hi everyone, After long consideration, I wa

Re: [lldb-dev] Adding a new architecture into LLDB

When we added support for Linux running on Hexagon, we treated it like any other Linux. We added the correct register handling, and built it. The issues you’re facing we handled in the compiler/rootfs. We built a cross-compiler that ran on x86 Linux, targeting Hexagon Linux. We set up a rootfs

Re: [lldb-dev] [RFC] Removing lldb-mi

As of yesterday, lldb-mi has been removed from lldb and moved to https://github.com/lldb-tools/lldb-mi . Some questions: * Is the expected way to build lldb-mi to drop the lldb-tools/lldb-mi repo into /tools/lldb-mi? * The lldb-mi tests weren’t moved into the new repo on github. Do we p

Re: [lldb-dev] [Release-testers] [9.0.0 Release] The release branch is open; trunk is now 10.0.0

We saw the same thing internally. We don’t use lldb-vscode, so we turned off those tests. Greg, any thoughts on lldb-vscode tests running forever on Linux? From: lldb-dev On Behalf Of Brian Cain via lldb-dev Sent: Monday, July 22, 2019 10:44 PM To: Hans Wennborg Cc: llvm-dev ; Release-testers

[lldb-dev] How do I use lit to only run the lldb test suite, now that dotest multiprocessing capabilities have been removed?

RE: https://reviews.llvm.org/D65311 Internally we use dotest to run the lldb test suite with various RTOS configurations for the test binaries. In these runs we don't care about the lit tests or the unit tests, because they are OS agnostic. We do this by specifying the compiler, lldb, and test

Re: [lldb-dev] How do I use lit to only run the lldb test suite, now that dotest multiprocessing capabilities have been removed?

Thanks Jonas. Is full support for --param fairly recent? I tried it with a version of our master, based on top-of-tree from about a month ago, and it didn't work quite right. It's passing the dotest args, but it's also generating some args, so I'm seeing odd effects. Here is my run line: bin/p

Re: [lldb-dev] How do I use lit to only run the lldb test suite, now that dotest multiprocessing capabilities have been removed?

Hi Jonas, What I need is a way to run the test suite with arbitrary command line arguments. Sometimes I want to run one or more tests with -f, sometimes I want to run one or more test files with -p, and sometimes I want to run the entire suite, either in parallel or 1 at a time (--no-multiproce

Re: [lldb-dev] How do I use lit to only run the lldb test suite, now that dotest multiprocessing capabilities have been removed?

Thanks for the pointers, Jonas. I cloned a new repo, then ran cmake, setting up arbitrary test compiler and lldb locations. Then ran llvm-lit tools/lldb/lit/Suite , and the test suite ran as expected. There were a few failures, but I've got a plan now. Ted > -Original Message- > From:

Re: [lldb-dev] lldb-mi has been moved to its own GitHub repository

The build instructions in README.md are a tad sparse: Build cmake . ; cmake --build . Where do we put it in relation to an lldb build? Does it need the llvm/lldb sources? Is it built against an lldb build, or an lldb install? Ted From: lldb-dev On Behalf Of Raphael “Teemperor” Isemann via lld

[lldb-dev] "Correctly use GetLoadedModuleList to take advantage of libraries-svr4" can cause LLDB to abort

Hi Antonio, This is in regards to https://reviews.llvm.org/D64013 , specifically this code in ProcessGDBRemote::GetImageInfoAddress: if (addr == LLDB_INVALID_ADDRESS) { llvm::Expected list = GetLoadedModuleList(); if (!list) { Log *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSe

Re: [lldb-dev] Breakpoint matching with -n seems to have gotten too generous

I agree - I wouldn't expect class AA to be a match for "A::". > -Original Message- > From: lldb-dev On Behalf Of Pavel Labath > via lldb-dev > Sent: Friday, August 30, 2019 1:28 AM > To: Jim Ingham ; LLDB > Subject: [EXT] Re: [lldb-dev] Breakpoint matching with -n seems to have > gotten

Re: [lldb-dev] lldb access in Emacs via realgud

That’s probably the best thing to do. lldb-mi is no longer officially part of lldb, so it is not supported by the lldb community. lldb-vscode is officially part of lldb, and if it breaks we can go yell at Greg! 😊 From: lldb-dev On Behalf Of Rocky Bernstein via lldb-dev Sent: Thursday, Septembe

Re: [lldb-dev] help, how to get a debug build on windows (python37_d.lib)

Hi Larry, You can tell the Python installer to install the debug libraries. I recently switch from VS 2015 to VS 2017 to build LLDB. My debug builds stopped working – it couldn’t link with the Python debug library, even though I had it in the right place. My guess is the Python I’m using (3.5.1

Re: [lldb-dev] RFC: full support for python files, and avoid using FILE* internally

A bit of a tangent, but I've been getting requests to debug Python and C++ together. Things like TensorFlow start in Python, then call into C++ libraries. Users want to be able to debug the Python code as Python (not debugging into Python itself), then step into the C++ libraries. They want to g

[lldb-dev] LLDB finish_swig and Python module installation broken for multi-configuration generators

Starting in r372835 (Fix installing Python modules on systems using /usr/lib), the finish_swig and installation steps using multi-configuration generators (like Visual Studio or XCode) are broken. The problem is the symlink and install steps look for liblldb and site-packages the wrong director

Re: [lldb-dev] LLDB finish_swig and Python module installation broken for multi-configuration generators

The build step works with r374250, but the install step fails. It needs CMAKE_CFG_INTDIR added to: install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/ DESTINATION ${LLDB_PYTHON_RELATIVE_PATH} COMPONENT lldb-scripts) > -Original Message- >

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

Internally on Windows we use Python 3.5.1. I just ran our latest nightly, and was able to run the script interpreter in lldb without issues. I want to upgrade to 3.7.x, but I need to get permission from our lawyers to ship it. Looking forward to that… From: lldb-dev On Behalf Of Adrian McCarth

Re: [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to lldb's cmakery

I'm not going to comment on the change (my cmake knowledge is a hair more than yours, but not enough for this), but LLVM_DEFAULT_TARGET_TRIPLE is the default backend. LLVM_HOST_TRIPLE is the triple we're running on. In your example, LLVM_DEFAULT_TARGET_TRIPLE should be something like arm-apple-d

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

> > * Dynamically load any supported Python DLL if/when needed > That might be tricky since the different versions are not binary compatible in > general. But it is possible, as Apple folks have shown, though it amounts to > building multiple copies of ScriptInterpreterPython and then choosing th

[lldb-dev] Possible bug in DataExtractor::GetMaxU64Bitfield

Here's an interesting bug, in source/Utility/DataExtractor.cpp, DataExtractor::GetMaxU64Bitfield: uint64_t bitfield_mask = ((1ul << bitfield_bit_size) - 1); In Visual Studio 2017, ul is a 32 bit type. When I run it with a size of 36 (from large_packed in test/API/lang/c/bitfields/main.c), I

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

I first noticed this issue when running print(lldb.SBHostOS.GetLLDBPythonPath()) in the script interpreter. It worked as expected on Linux and with an LLDB that I built on my machine, but when I ran it in an LLDB that our buildbots built, I got the wrong value - /lib/site-packages/lib/site-pack

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

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 64-bit? Are you launching Python from a 32- or 64-bit process? Is it the same on both machines? On Fri, Feb 21, 2020 at 1:02 PM Ted Wo

Re: [lldb-dev] Default script language

I agree with Jim - it should be a cmake setting, defaulting to Python. If the person building lldb wants to change the default scripting language from Python to Lua, it should be easy. Since we now support 2 scripting languages, we should have an easy way for the user to see which are supported,

Re: [lldb-dev] LLDB problems on remote debugging

Hi Rui, What you describe is almost identical to what we do with the Hexagon simulator. There are 2 ways to launch your program - “run” (process launch) and gdb-remote (an attach). “run” will require some plumbing to launch your simulator the same way that lldb-server/debugserver is launched.

[lldb-dev] Minimum required swig version?

http://lldb.llvm.org/resources/build.html Says we need swig 2 or later: If you want to run the test suite, you'll need to build LLDB with Python scripting support. * Python * SWIG 2 or later. I don't think this is correct anymore. test/A

Re: [lldb-dev] LLDB problems on remote debugging

On Apr 29, 2020, at 9:28 PM, Rui Hong mailto:hongru...@mails.ucas.ac.cn>> wrote: First I would like to express my appreciation and thanks to you all especially Greg Clayton and Ted Woodward! Your advice and guidance are quite useful for me! You’re welcome! *4. by the way, does GDB has similar

Re: [lldb-dev] LLDB's disassemble function

Hi Rui, Disassembler::Disassemble calls ParseInstructions with prefer_file_cache set to false. Try setting prefer_file_cache to true. Ted From: lldb-dev On Behalf Of Rui Hong via lldb-dev Sent: Thursday, July 30, 2020 10:08 PM To: lldb-dev Subject: [EXT] [lldb-dev] LLDB's disassemble functio

[lldb-dev] Odd output issue with lldb -s

I have a very simple lldb script: thread select 1 disassemble --start-address $pc-24 --end-address $pc+24 When I run lldb with -o "process launch -s" and -s "dis.lldb", I get odd output - the disassembly from "thread select 1" and from the disassemble command run together. This is what I see

Re: [lldb-dev] [RFC] Segmented Address Space Support in LLDB

I agree with Pavel about the larger picture - we need to know the driver behind address spaces before we can discuss a workable solution. I've dealt with 2 use cases - Harvard architecture cores, and low level hardware debugging. A Harvard architecture core has separate instruction and data mem

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

To expand a bit on what Pavel has written, the lldb module should be in \lib\site-packages\lldb . In that directory is a file, _lldb.pyd, that should be a copy of \bin\liblldb.dll . Do both files exist? Is _lldb.pyd a copy of liblldb.dll? See function create_relative_symlink in llvm-project/lldb

Re: [lldb-dev] lldb versus visual studio

There was. Almost nobody used it. Nobody maintained it. > -Original Message- > From: lldb-dev On Behalf Of Franz > Fehringer via lldb-dev > Sent: Monday, March 22, 2021 2:28 PM > To: lldb-dev@lists.llvm.org > Subject: [EXT] Re: [lldb-dev] lldb versus visual studio > > Thank you very much,

Re: [lldb-dev] RFC: packet to identify a standalone aka firmware binary UUID / location

Hi Jason, A bit of a tangent here, but would you guys consider making your JTAG RSP server a bit more generic and releasing it open source for use with OpenOCD? They've got a stub for gdb, but it needs some work to behave better with lldb. Ted > -Original Message- > From: lldb-dev On

Re: [lldb-dev] how to attach to process with python scripting on lldb?

Try target.AttachToProcessWithID() instead of target.LaunchSimple(). LaunchSimple tells lldb to run, creating a new process, instead of attaching to an existing one. See the SBTarget Python documentation here: https://lldb.llvm.org/python_reference/lldb.SBTarget-class.html . You should also be

Re: [lldb-dev] RFC: siginfo reading/writing support

You should use Hg for this instead of Hc. Hc is used for step/continue, while Hg is used for everything else. > -Original Message- > From: lldb-dev On Behalf Of Michal Górny > via lldb-dev > Sent: Tuesday, January 11, 2022 6:38 AM > To: lldb-dev@lists.llvm.org > Subject: [lldb-dev] RFC

Re: [lldb-dev] lldb-vscode plugin information for Windows/Arm platform

The last 2 Hexagon release trains have shipped with vscode support on Linux and Windows. I worked with Greg to do what you want to do – make a vscode extension to allow it to use lldb-vscode as its debugger. I wrote a batch script that: * Removes the extension directory * Creates the ex

Re: [lldb-dev] How does attach work on non-Windows?

On Linux, according to the proc(5) man page, you look at /proc//status. There's a field "TracerPid" that gives the pid of the tracing process. The value is 0 if not being traced. TracerPid: 13849 TracerPid: 0 /proc/pid/stat has a field called "flags" that contains kernel flags, but

[lldb-dev] top-of-tree build failure when using configure on Linux?

Our Ubuntu 14.10 buildbot at http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.10 is failing, and I've been tasked to fix it because I'm the LLDB guy. It fails with things like: /var/lib/buildbot/slaves/hexagon-build-03/lldb-x86_64-ubuntu-14.10/llvm.obj/ Release+Asserts/lib/libclangCodeG

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

y on a clean build? Is it configure-based or cmake based? Just some thoughts. Good luck resolving! -Todd On Fri, Aug 28, 2015 at 10:56 AM, Ted Woodward via lldb-dev mailto:lldb-dev@lists.llvm.org> > wrote: Our Ubuntu 14.10 buildbot at http://lab.llvm.org:8011/builders/lldb-x86

Re: [lldb-dev] Windows build questions

Zachary, when you say x64 runtime support isn’t there yet, you mean for VS2015 and/or Win 10, right? I’ve been building x64 LLDB on Win 7 with VS 2013 for 2 years now. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundat

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

Project From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Ted Woodward via lldb-dev Sent: Thursday, September 03, 2015 1:34 PM To: 'Zachary Turner'; 'Todd Fiala' Cc: 'LLDB' Subject: Re: [lldb-dev] top-of-tree build failure when using configure o

Re: [lldb-dev] " Import error: No module named embedded_interpreter" on windows

A build with msbuild or from VS2013 using the .sln file produce the same directory structure. The error looks a lot like what I see when I don’t have lldb_d.pyd set up correctly. It can’t load the lldb python module (a link to the shared library), so it gets cranky. Was there an error in

Re: [lldb-dev] Does anyone depend on using LLDB with Python 2.6?

Ubuntu 10.04 uses 2.6 by default; Ubuntu 12.04 uses 2.7. We have a bunch of Ubuntu 10 machines here, but anything that runs lldb has 2.7 installed. I’m OK with dropping 2.6 support. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

<    1   2