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

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

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

ssue go away 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 <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote: Our Ubuntu 14.10 buildbot at

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

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 on Linux? We forced a clean

[lldb-dev] swig generation and "six" module

r252764 changes finishSwigPythonLLDB.py to symlink the "six" module in site-packages. six.py is a symlink to /tools/lldb/third_party/Python/module/six/six.py. This assumes I have access to this build's sources when I run lldb, which I don't - our workstations don't have access to the buildbots'

Re: [lldb-dev] swig generation and "six" module

PM To: Ted Woodward; LLDB Subject: Re: [lldb-dev] swig generation and "six" module What about requiring that the user has done "pip install six" on their machine? On Wed, Dec 9, 2015 at 1:40 PM Ted Woodward via lldb-dev <lldb-dev@lists.llvm.org <mailto:lldb-d

[lldb-dev] Linux core dump doesn't show listing when loaded

I've been working on an old rev that we'd released on; now I'm much closer to ToT as we move towards our next major Hexagon release. Core dumps on the old rev would print out a listing/disassembly for each thread in the core dump. Now it doesn't. ToT does this, on x86 Linux: >bin/lldb

Re: [lldb-dev] bindings as service idea

For our builds at QUIC, we're not interested in hitting an external server to get code. So we'd either hit the server when needed and check in the resultant bindings, or (preferably) use bindings from upstream. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a

[lldb-dev] FW: LLDB Windows Python Bindings

Why can’t we use VS 2015 with Python 2.7? -- 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 Zachary Turner via

Re: [lldb-dev] Discrete code and data memories

What Tyro is describing is called a "Harvard architecture" - https://en.wikipedia.org/wiki/Harvard_architecture . It contrasts with the von Neumann architecture used by most machines today. Hexagon has a unified memory map, but I've worked with other DSPs (Motorola DSP56xxx) that have a code

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

to you to chase anyone who adds 2013-breaking changes... pl On 2 February 2016 at 23:42, Ted Woodward via lldb-dev <lldb-dev@lists.llvm.org> wrote: > No, it turned red Friday night/Saturday morning. > > > > Last good build: > > http://lab.llvm.org:8011/builders/lldb-x86-win

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

It looks like our bot, http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc , has tried to update to Python 3.5 and MSVC 2015, but it can’t find python or VC. I’ll talk to our buildmiester about it. Should we run this guy with 2013/py2.7 or 2015/py3.5? -- Qualcomm Innovation Center,

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

than my bot [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015]. If you want you could just remove your bot. If you want to keep it, then yea getting it on VS2015 and Python 3 would be the best idea. On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev <lldb-dev@lists.llvm

[lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

Background: Hexagon clang doesn't have JIT support, so lldb for Hexagon only uses the IR Interpreter (Codeplay wrote it for us). Sean, r260768 broke the expression parser with functions. Without connecting to a target, I can't get the info for main: (lldb) e main error: Can't run the

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

I did some digging and found where the ID is being changed from 0x5 to 0xa in the original code. IRForTarget::runOnModule() calls ResolveFunctionPointers(), which gets a Constant * from BuildFunctionPointer(). This Value has an ID of 0xa, and runOnModule() then calls the original Function’s

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

Unfortunately, that leads to another error, in the Instruction::Store case. IRInterpreter::ResolveConstantValue() returns an error because it doesn’t like the value id of FunctionVal. “Interpreter couldn't resolve a value during execution”. If I go back 1 commit from r260768 (r260767), it

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

I added this to ResolveConstantValue(): case Value::FunctionVal: if (const Function *constant_func = dyn_cast(constant)) { value = 0; return true; } break; value is an APInt &, so it won’t take

Re: [lldb-dev] lldb-mi and shared library path

, February 22, 2016 6:24 PM To: Ted Woodward Cc: LLDB Subject: Re: [lldb-dev] lldb-mi and shared library path > On Feb 4, 2016, at 1:51 PM, Ted Woodward via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > I’d expect “-gdb-set solib-search-path” to call “target modules search-paths &

[lldb-dev] Getting lldb tests working on Hexagon

I'm trying to get the lldb tests running using lldb built with Hexagon support. Some tests are running correctly, but others are failing/skipped etc. First, I'd like to get it to skip tests that shouldn't be run. For example, I see output that looks like this: Configuration: arch=x86_64

Re: [lldb-dev] Getting lldb tests working on Hexagon

archs doesn't include x86_64 On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote: I’m trying to get the lldb tests running using lldb built with Hexagon support. Some tests are running correctly, but others

[lldb-dev] problem with quoted strings in setting target.run-args

Quoted strings in target.run-args aren't handled correctly. (lldb) settings set target.run-args "foo bar" (lldb) settings show target.run-args target.run-args (array of strings) = [0]: "foo bar" This looks correct, but the Args in the ProcessLaunchInfo passed to the Platform doesn't

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

>> (lldb) file u:\lldb_test\dlopen >> Current executable set to 'u:\lldb_test\dlopen' (hexagon). >> (lldb) target modules load -f dlopen -s 0x2 >> (lldb) b main >> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = >> 0x00030018 >> >>

Re: [lldb-dev] Help needed regarding LLDB/MI

Hi Rishabh, It looks like you’re trying to use lldb commands when running lldb-mi. lldb-mi is the gdb-mi command layer on top of lldb, primarily used by tools like Eclipse to talk to lldb or gdb using a similar command set. These commands are documented here:

[lldb-dev] Get address for PIE-like "process"

We've got an OS that implements something they call a "user PD", which is a lot like a PIE process. To debug it, we need to get the address of the image and then slide the target's symbols. What's the best way to get the address from the remote stub? Linux lldb reads an AuxVector from lldb-server,

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

> (lldb) image dump sections dlopen > > Check to make sure all addresses for the sections look good. > > Now do: > > (lldb) gdb-remote tedwood-ubuntu:5556 > (lldb) image dump sections dlopen > > I am guessing that the sections have been moved... > > Let me

[lldb-dev] "target modules load" and breakpoints not working correctly

I'm seeing 2 issues with "target modules load": Issue #1: load address is forgotten after a connect: (lldb) file u:\lldb_test\dlopen Current executable set to 'u:\lldb_test\dlopen' (hexagon). (lldb) target modules load -f dlopen -s 0x2 (lldb) b main Breakpoint 1: where =

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

at 4:28 PM, Ted Woodward via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > I’m seeing 2 issues with “target modules load”: > > > > Issue #1: load address is forgotten after a connect: > > (lldb) file u:\lldb_test\dlopen > Current executable set to 'u:

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

"process launch" calls Target::Launch, which calls PlatformHexagon::DebugProcess, which calls Target::CreateProcess, which calls Target::DeleteCurrentProcess, which calls SectionLoadList::Clear, which erases the section-to-addr mappings. "gdb-remote" calls Platform::ConnectProcess, which calls

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

The assert is gone – the alias to an alias behaves as expected. There is one issue with my testcase, “command alias r run”. That’s “help r”. The last line is “'r' is an abbreviation for 'run -c /bin/sh --'”, but that’s not true. ‘run’ is an abbreviation for 'process launch -c /bin/sh --',

[lldb-dev] Windows lldb prompt issue

I run lldb on Windows and Linux, launching my gdb-server based Hexagon simulator automatically on a process launch. On Windows I'm seeing the (lldb) prompt before the stop message, and no prompt after. On Linux I see the prompt after. Windows: Current executable set to 'u:\lldb_test\factwin'

Re: [lldb-dev] Windows lldb prompt issue

at is not thread 1 from the initial thread list shown at the beginning, you should see your screen be: "hello world (lldb) " If you see: "(lldb) hello world (lldb) " Then you know that the erasing feature isn't working in Editline::PrintAsync() and it will explain why you see

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

Yes, it’s up for review. Please see http://reviews.llvm.org/D17860 . -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Adrian McCarthy [mailto:amcca...@google.com] Sent: Tuesday,

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

I think I see the problem; I’ll push up a fix. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Zachary Turner [mailto:ztur...@google.com] Sent: Thursday, March 03, 2016 11:54 AM

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

t; Ted: If you can't switch to the 3+2015 combination (which I *do* recommend >> you try), maybe you can go half-way and switch to 2.7+2015 (I can show you >> how to build python 2.7 with VS2015). If you stick with 2.7+2013 combo, it >> will soon be up to you to chase an

[lldb-dev] bug in TestMiGdbSetShow.test_lldbmi_gdb_set_target_async_off?

Packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py, in test_lldbmi_gdb_set_target_async_off we have this code: self.runCmd("-gdb-set target-async off") . self.runCmd("-exec-run") unexpected = [ "\*running" ] # "\*running" is async notification

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

t;> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >> >> -Original Message- >> From: jing...@apple.com [mailto:jing...@apple.com] >> Sent: Friday, May 06, 2016 2:41 PM >> To: Ted Woodwa

[lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

I'm stepping over the first line of a libcxx test (source https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condit ion/thread.condition.condvar/wait.pass.cpp ). The first line has an inlined function call. I expect lldb to step over the breakpoint, run to the end of the range

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

c)) >>> next_frame_sc.line_entry.file = new_file_spec; >>> } >>> >>> I've put up a patch on Phabricator with Jim as reviewer. >>> >>> -- >>> Qualcomm Innovation Center, Inc. >>> The Qua

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

source-map setting > On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > I’m stepping over the first line of a libcxx test (source > https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar

Re: [lldb-dev] LLDB Evolution

I don’t think we can completely get rid of the lldb coding conventions doc; we’ll need this type of thing as long as we use swig: * enumerations that might end up being in the lldb SB API's should all be written like: typedef enum EnumName { eEnumNameFirstValue,

Re: [lldb-dev] LLDB-MI from Eclipse hangs

I wanted a log with Eclipse talking to lldb-mi to see if it was doing anything odd. It's not: -exec-continue --thread-group i1 < 5> send packet: $c#63 -list-thread-groups i1 We have lldb-mi launch hexagon-sim automatically; it launches the same way debugserver does, with

Re: [lldb-dev] Question about -break-insert in lldb-mi

It looks like the current implementation expects the -f to be right before the break location. So "-break-insert main" or "-break-insert -t -f main -d" would work, but "-break-insert -t main -f -d" would not. It also looks as if restricting the breakpoint to the thread id (incorrectly) only

Re: [lldb-dev] LLDB-MI from Eclipse hangs

A few thoughts: 1) I think lldb-mi now takes lldb commands, so you could do the log in your manual copy/paste. The command you want is: log enable gdb-remote packets Do it after the stop, before the –break-insert. You’ll get a bunch of data after the –break-insert, then do the

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

Does lldb-mi support non-stop mode? If so, is there a way to set it besides "settings set target.non-stop-mode true"? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

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

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

target.async` option. Probably that's what you need. On Thu, Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > wrote: Does lldb-mi support non-stop mode? If so, is there a way to set it besides “settings set ta

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

Try "image search-paths add" as a replacement for "set solib-search-path" -- 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

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is historically ELFOSABI_SYSV, and used by a lot of things. So not all core files identified as ELFOSABI_NONE are Linux. Whe lldb loads a core file with a target binary, it will merge the 2 triples. If it can't identify the OS

Re: [lldb-dev] Python3 compatibility for the API

I just built lldb on Ubuntu 12 with Python 3.5.1. I needed to set python includes, python library and python executable in cmake. I found a problem with the tests - most ran fine, but I got errors with tests that tried to use pexpect, like TestConvenienceVariables.py. File

Re: [lldb-dev] Problem with watchpoints

I don't know if what I have >>>> written is even desirable. For instance, the corresponding >>>> breakpoint implementation is almost totally lacking in source doc. >>>> >>>> * I will need to rebase this patch on the reformatted code. That &

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

et_sp, lldb::ListenerSP listener_sp, const FileSpec *crash_file) { So you are handed the target. You can get the executable file from the target and also check the target's architecture or the main executable's architecture. There shouldn't be a problem figuring this out right? Greg >

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

That works fine for host debug, but not so much for embedded. On Hexagon, we support 2 OS cases - standalone (which means no OS, or an OS that lldb doesn't know anything about) and Linux. Both our standalone simulator and our Linux generate core dumps using ELFOSABI_NONE. We run lldb on both x86

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

Would the misalignment really be a problem on x86? I thought the core handled misaligned loads and stores. Unlike, say, PPC. Either way, I'd expect the compiler to automatically align a uint64. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

LLDB_DEFAULT_PYTHONHOME is an internal thing; I haven’t upstreamed it – for a while, it conflicted with Zach’s implementation, but I redid it, and everything is happy now. If you think it would be useful, I could upstream it. It’s fairly small, and plays nice with Zach’s Python stuff. The

[lldb-dev] "image search-paths add" removes all breakpoints from remote server

Is "image search-paths add" supposed to remove all breakpoints from the remote server? I don't think it should be doing this. PathMappingList::Append calls Target::ImageSearchPathsChanged, which calls Target::SetExecutableModule, which calls Target::ClearModules, which removes the breakpoints.

Re: [lldb-dev] "image search-paths add" removes all breakpoints from remote server

rom remote server > > > > On Nov 16, 2016, at 12:03 PM, Ted Woodward via lldb-dev d...@lists.llvm.org> wrote: > > > > Is “image search-paths add” supposed to remove all breakpoints from the > remote server? I don’t think it should be doing this. > > > >

[lldb-dev] unaligned cast in TCPSocket::Connect

TCPSocket::Connect has this line: host_str = ::inet_ntoa (*(struct in_addr *)*host_entry->h_addr_list); host_entry->h_addr_list is a char**, while struct in_addr contains a uint32_t. Casting like this (char * to uint_32t *) could cause a bus error on systems that don't allow

Re: [lldb-dev] LLDB can't find source...but it can?

0 1 0 0 is_stmt > > 0x0004896432811 1 0 0 is_stmt > > prologue_end > > > > > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora

Re: [lldb-dev] LLDB can't find source...but it can?

PM > To: Ted Woodward <ted.woodw...@codeaurora.org> > Cc: LLDB <lldb-dev@lists.llvm.org> > Subject: Re: [lldb-dev] LLDB can't find source...but it can? > > > > On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev d...@lists.llvm.org> wrote: > > > > Backg

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

I've also never seen either problem. I'm not debugging Windows apps, but Hexagon apps, running lldb and the Hexagon simulator on Win7. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >

Re: [lldb-dev] LLDB bare-metal and 'load' command

Hi Abid, How are you communicating with the ARM? lldb->gdbserver->jtag probe? We've discussed doing that kind of thing with Hexagon, but we're nowhere near implementing it. "process launch" on linux can download the target to the remote machine when connected in platform mode. If you make

Re: [lldb-dev] Prebuilt binary for Windows

The compiler redistributable is also widely available: https://www.microsoft.com/en-us/download/details.aspx?id=48145 The python 3.5 dll would still use the runtime dll; lldb should do the same. I’ve had crashes in the past because lldb and python used different runtimes. --

[lldb-dev] test decorator working on linux, but not on windows

packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has this decorator: @expectedFailureAll(compiler="clang", bugnumber="llvm.org/pr19238") On Linux, I'm building with hexagon-clang, and this decorator fires, so the test is xfailed. On Windows, I'm building with

Re: [lldb-dev] test decorator working on linux, but not on windows

swig_version=None, py_version=None, macos_version=None, remote=None): ... skip_for_compiler = _match_decorator_property( compiler, self.getCompiler()) and self.expectedCompilerVersion(compiler_version) On Fri, Jan 6, 2017 at 10:11 A

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

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

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

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

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

[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

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

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

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

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

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

[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

  1   2   >