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

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]

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

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

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

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

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

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

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.

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

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 Woodward via

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

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

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

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

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

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-

[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

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

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

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,

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 >

[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

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

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

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:

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

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

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

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

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:

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

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 cmake gui, and

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

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

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

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

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.

[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

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

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

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

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.

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:

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

[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

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

[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

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

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

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

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

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)

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

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

[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

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

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] Can I call a python script from LLDB c++ code?

> To: Ted Woodward <ted.woodw...@codeaurora.org> > 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-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

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

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,

[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] Command history line editing

<mailto:lldb-dev-boun...@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

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

[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

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

[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

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

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

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

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

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

[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

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

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

I found a hang in lldb-mi's -var-update. It checks to see if a var changed, then it checks each of the children recursively. If a child is a pointer back to a parent, as in this case: struct complex_type { int i; struct { long l; } inner; struct complex_type *complex_ptr; }; void

Re: [lldb-dev] Remote debugging ARM target from x86 host

The lldb-server launch line looks ok; it should take the port 0 arg and get a port from the OS. lldb is getting the port back from lldb-server in 4.0.1, as seen here: > GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 56543 > port But for 5.0.0 we see it fail the

Re: [lldb-dev] Remote debugging ARM target from x86 host

What should be happening is Handle_qLaunchGDBServer calls LaunchGDBServer with a port of UINT16_MAX, which tells it to use a port in its port list. It shouldn't have a port list, so should return 0. LaunchGDBServer calls StartDebugServerProcess with a port of 0 in the url.

Re: [lldb-dev] Forcing lldb to refresh process state

Perhaps a manual packet that tells your remote server that the next "s" packet is a reverse step, then run the lldb command "si". It would be simpler, from a packet log analysis standpoint, if you weren't stopped at a breakpoint location when you did this. -- Qualcomm Innovation

Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface

The original lldb-mi implementation was to get Eclipse talking to lldb. Since then there have been other people working on it, and other clients, but lldb-mi is not a full implementation of the MI protocol. The best thing to do is give us a list of commands that are failing, in a bug opened in

Re: [lldb-dev] Trying to use socketpair for lldb-server fails

This is big time overkill, but I wasn’t sure where the problem I was tracking down was: “lldb all:linux all:gdb-remote all” Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [lldb-dev] Python scripting in Windows LLDB

on scripting in Windows LLDB On Fri, Jun 30, 2017 at 12:39 PM Ted Woodward via lldb-dev <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote: Python support on Windows is much more problematic than support on something like MacOS or Linux. The python you use when you r

Re: [lldb-dev] Python scripting in Windows LLDB

Python support on Windows is much more problematic than support on something like MacOS or Linux. The python you use when you run lldb must be the same python used when you build it. Bad things happen – warnings, crashes, etc – when you use a different rev of the dll/so or the library directory

Re: [lldb-dev] Support for Error Strings in remote protocol

What we can't do is require the remote server to support the new protocol. lldb-server isn't the only thing we talk to, and failing because we didn't get a specific non-RSP conformant error packet would be bad. I like Pavel's idea of enabling it via a Q packet, and after being enabled it

[lldb-dev] issue with lldb-mi -var-update with pointers

I have a simple testcase that modifies the value pointed to by an int *. I've created a variable with -var-create, and then after the value has been updated, check it with -var-update. -var-update returns no changes, but the value has changed. test.c: #include int main(void) { int vec[] = {1,

Re: [lldb-dev] Documentation LLDB-MI

lldb-mi uses the gdb/mi interface, which is defined here: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html . The lldb-mi implementation is slightly different in some ways, but nothing that should affect what you want to do. Looking at the code (in /tools/lldb-mi/MICmdCmdFile.cpp)

Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"

To expand on Jim's message, "target modules search-paths add" can be used to help lldb find the host-side copies of shared libraries when they're not in the same directory as on the target system. For example, if you have libraries in /usr/lib on the target system, and have copies on the host

Re: [lldb-dev] Python scripting in Windows LLDB

ators. > E.g. a single VS build will create both debug and release configurations. I > suspect this is the reason why the check is written as it is now. > > I'm not sure what would be the appropriate behavior in this case if only one > of the pythons is available. > > On

Re: [lldb-dev] Python scripting in Windows LLDB

LLDBConfig.cmake has this: if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL)) message("Python installation is corrupt. Python support will be disabled for this build.") set(LLDB_DISABLE_PYTHON

Re: [lldb-dev] Using LLDB API on windows

I wonder if lldb isn’t using the windows platform. In the lldb command line, load up your target, then type “target list”. I’d like to see what plaform it chose, and what the triple is. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora

[lldb-dev] std::vector formatter question

On standalone Hexagon (no OS support), we use Dinkumware for the c/c++ library. LLDB isn't able to print out values of a vector: Process 1 stopped * thread #1: tid = 0x0001, 0x519c vector.elf`main + 76 at vector.cpp:10, stop reason = step in frame #0: 0x519c vector.elf`main + 76 at

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel Labath via lldb-dev Sent: Friday, March 17, 2017 4:48 AM > On 16 March 2017 at 21:43, Kamil Rytarowski wrote: >> I imagined a possible flow of ResumeAction calls like: >> [Generic/Native framework knows

Re: [lldb-dev] non-stop mode with lldb-mi?

gt;> That is just one of the many things that will have to be changed to > >> support non-stop mode. For now, non-stop mode is only likely to work > >> reliably if the threads you are allowing to run never stop - hit > >> breakpoints, crash or whatever - so worrying abo

  1   2   >