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

[Ted Woodward via lldb-dev]

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 extension directory 
(%USERPROFILE%\.vscode\extensions\qualcomm-hexagon.lldb-vscode-8.5)
  *   Copies package.json to the extension directory
  *   Copies a dragon image I made (based on one from the llvm site) to 
\images
  *   Uses mklink /j to link the bin and lib directories from my toolset 
installation

The internal name of the extension defaults to lldb-vscode. I change this to 
include our release number, since it’s valid to have multiple toolset 
installations that are installed where the user wants, and we don’t want 8.5 to 
conflict with 8.6, etc.

Because it’s valid to install multiple releases, I link to the bin and lib 
directories for this extension’s installation. This also lets me have release 
and debug extensions – copy the release extension, change the internal plugin 
name in package.json, and point the links to my bin and lib directories. Then I 
can change the plugin name in my testcase’s tasks.json to point to my debug or 
release extension.

If you have any questions, please feel free to contact me.

On Jan 20, 2022, at 4:40 PM, Omair Javaid 
mailto:omair.jav...@linaro.org>> wrote:

Hi Greg,

I intend to understand requirements to set up the lldb-vscode tool for Windows 
on Arm. I have been looking at your vscode readme from 
https://github.com/llvm/llvm-project/blob/cfae2c65dbbe1a252958b4db2e32574e8e8dcec0/lldb/tools/lldb-vscode/README.md

If I understood correctly Windows on Arm platform is missing a vscode adapter 
plugin required to make lldb-vscode tool work on Arm/Windows platform. Similar 
adapter plugin is available for Windows x64 through third parties but I am 
wondering if there is an official version of the same plugin which can be 
packaged after porting for Windows on Arm.

Right now we don’t distribute a lldb-vscode through the marketplace so you just 
need to build it yourself and then create the directory as mentioned in the 
readme.


Basically you just need to download the LLDB sources to a Windows on Arm 
machine and build “lldb-vscode”. Then you take the “lldb-vscode.exe” binary and 
the LLDB DLL and put then into the extension’s bin folder. Then make sure that 
you can launch the program from the terminal and make sure it finds the DLL 
right next to the program

I am not sure if where the VSCode extensions live on a windows user folder, but 
the readme is saying:

~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin

So you would want to end up with:

~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin/lldb-vscode.exe
~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin/lldb.dll

(not sure of the name of the lldb library name on windows)

And then copy the package.json to the folder:

cp package.json ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0

Then you should be able to restart your VS code IDE and the extension should be 
available. It is important to make sure that the program lauches from the 
command line to make sure that the program is able to locate the lldb shared 
library (DLL). If you launch the program and it doesn’t complain, it will just 
sit there waiting for input. If it can’t find the DLL, then it should cause an 
error and you will need to figure where the DLL needs to be relative to the 
program. I am not familiar with exactly how this works on windows for a given 
EXE and how it locates the DLLs the main executable needs.

Let me know if you are able to get things working!

Greg



I ll really appreciate any sort of help/pointer to accelerate further progress.

Thanks!

--
Omair Javaid
www.linaro.org

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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: siginfo reading/writing support
> 
> Hello,
> 
> TL;DR: I'd like to implement at least partial support for reading/writing 
> siginfo
> via LLDB.  I can't think of a better approach than copying the GDB's idea of
> "magical" $_siginfo variable that works through the expression evaluator.  I'd
> like to know your opinion/ideas.
> 
> 
> POSIX defines a siginfo_t structure that is used to pass additional signal
> information -- such as more detailed signal code, faulting memory address in
> case of SIGSEGV or PID of the child process in case of SIGCHLD.  LLDB already
> uses ptrace(2) to obtain this information and use it internally but it doesn't
> expose it to the user.
> 
> The GDB Remote Serial protocol provides the ability to read/write siginfo via
> qXfer:siginfo:... packets [1].  GDB exposes this information to the user via a
> special $_siginfo variable [2].
> 
> A few things to note:
> 
> 1. Some targets (e.g. Linux, NetBSD) support overwriting siginfo, some (e.g.
> FreeBSD) only reading.
> 
> 2. Siginfo is generally associated with a single thread, so the packets should
> be combined with respective thread selection (Hg or Hc?).
> 
> 3. The exact type of siginfo_t differs per platform (POSIX specifies a minimal
> subset).
> 
> 
> My rough idea right now is to follow GDB here.  While using "$_siginfo"
> may seem hacky, it has the nice advantage that it can easily support all
> different siginfo_t structures used by various platforms.
> 
> The plan would be to:
> 
> 1. Implement the qXfer:siginfo:... packets in lldb-server, and add tests to
> them.
> 
> 2. Implement support for "$_siginfo" in the client (I suppose this means
> hacking on expression evaluator).
> 
> 3. (Optionally) implement hardcoded siginfo_t definitions for common
> platforms to make things work without debug info.
> 
> WDYT?
> 
> 
> [1]
> https://www.sourceware.org/gdb/onlinedocs/gdb/General-Query-
> Packets.html#qXfer-siginfo-read
> [2] https://sourceware.org/gdb/current/onlinedocs/gdb.html#Signals
> 
> 
> --
> Best regards,
> Michał Górny
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 able to attach using the lldb command line, then go into the 
scripting interface and get the debugger object with lldb.debugger . Or attach 
using debugger.HandleCommand() to run an lldb command from the scripting 
interface.

Ted

From: lldb-dev  On Behalf Of Pi Pony via 
lldb-dev
Sent: Wednesday, November 3, 2021 10:20 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] how to attach to process with python scripting on lldb?


WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.
Hello,

I have been trying for some days to resolve a symbol of address using lldb 
python api but I haven't found how to do that.
So I think that I need to attach to the PID using python but it's not working, 
I tried:

target = lldb.debugger.FindTargetWithProcessID(71321)
process = target.LaunchSimple(None, None, os.getcwd())
process.GetState() --> Returns 0  ... Why?

So I could use the ResolveSymbolAddress function because if I attach it outside 
of scripting then I do not own the self – debugger object.

I appreciate your help.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 Behalf Of Jason
> Molenda via lldb-dev
> Sent: Tuesday, March 23, 2021 1:02 AM
> To: Greg Clayton ; Pavel Labath 
> Cc: LLDB 
> Subject: [EXT] [lldb-dev] RFC: packet to identify a standalone aka firmware
> binary UUID / location
>
> Hi, I'm working with an Apple team that has a gdb RSP server for JTAG
> debugging, and we're working to add the ability for it to tell lldb about the
> UUID and possibly address of a no-dynamic-linker standalone binary, or
> firmware binary.  Discovery of these today is ad-hoc and each different
> processor has a different way of locating the main binary (and possibly 
> sliding
> it to the correct load address).
>
> We have two main ways of asking the remote stub about binary images
> today:  jGetLoadedDynamicLibrariesInfos on Darwin systems with
> debugserver, and qXfer:libraries-svr4: on Linux.
>
>  jGetLoadedDynamicLibrariesInfos has two modes: "tell me about all
> libraries" and "tell me about libraries at these load addresses" (we get
> notified about libraries being loaded/unloaded as a list of load addresses of
> the binary images; binaries are loaded in waves on a Darwin system).  The
> returned JSON packet is heavily tailored to include everything lldb needs to
> know about the binary image so it can match a file it finds on the local disk 
> to
> the description and not read any memory at debug time -- we get the mach-
> o header, the UUID, the deployment target OS version, the load address of
> all the segments.  The packets lldb sends to debugserver look like
> jGetLoadedDynamicLibrariesInfos:{"fetch_all_solibs":true}
> or
> jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[4294967296,14073373
> 5313408,..]}
>
>
> qXfer:libraries-svr4: returns an XML description of all binary images loaded,
> tailored towards an ELF view of binaries from a brief skim of
> ProcessGDBRemote.  I chose not to use this because we'd have an entirely
> different set of values returned in our xml reply for Mach-O binaries and to
> eliminate extraneous read packets from lldb, plus we needed a way of asking
> for a subset of all binary images.  A rich UI app these days can link to five
> hundred binary images, so fetching the full list when only a couple of 
> binaries
> was just loaded would be unfortunate.
>
>
> I'm trying to decide whether to (1) add a new qStandaloneBinaryInfo packet
> which returns the simple gdb RSP style "uuid:;address:0xADDR;"
> response, or (2) if we add a third mode to jGetLoadedDynamicLibrariesInfos
> (jGetLoadedDynamicLibrariesInfos:{"standalone_binary_image_info":true})
> or (3) have the JTAG stub support a qXfer XML request (I wouldn't want to
> reuse the libraries-svr4 name and return an XML completely different, but it
> could have a qXfer:standalone-binary-image-info: or whatever).
>
>
> I figured folks might have opinions on this so I wanted to see if anyone cares
> before I pick one and get everyone to implement it.  For me, I'm inclined
> towards adding a qStandaloneBinaryInfo packet - the jtag stub already knows
> how to construct these traditional gdb RSP style responses - but it would be
> trivially easy for the stub to also assemble a fake XML response as raw text
> with the two fields.
>
>
>
> J
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb versus visual studio

[Ted Woodward via lldb-dev]

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, this essentially meets my expectations (no eclipse
> debugging with Windows/VC++), i am a little surprised that there is no
> working lldb integration for eclipse, is this really the whole truth (or did i
> misunderstand)?
>
>
> Am 22.03.2021 um 19:28 schrieb Greg Clayton:
> >
> >> On Mar 20, 2021, at 8:57 AM, Franz Fehringer via lldb-dev  d...@lists.llvm.org> wrote:
> >>
> >> Dear lldb-dev community,
> >>
> >> First a disclaimer: If my question is inappropriate for this (developer) 
> >> list
> please ignore or guide me to a more appropriate list (it is possibly more of 
> an
> end user question).
> >> Is it possible to debug Visual Studio generated (with pdb debug info)
> executables (2017 or 2019, C++ only)  with lldb?
> > LLDB does have PDB parsing abilities, though I am unsure how well they
> work out of the box with no extra configuration. There are two PDB parsers
> in LLDB at the moment, one that uses a DLL from Visual Studio that knows
> how to parse a PDB file, and one that tries to parse the PDB file manually. So
> if you are natively on windows, I believe you might need to set run the batch
> file that sets up environment variables for finding these DLLs. The native PDB
> parser should work, but I am not sure if the native version always takes
> precedence when running on the Windows OS.
> >
> > Maybe someone that did the PDB integration could chime in?
> >
> >
> >> And if so is there a full integration into eclipse so i can debug Visual 
> >> Studio
> generated executable with eclipse?
> > The only integration that I am aware of was one that used lldb-mi, or the
> GDB remote machine interface. But the lldb-mi was dropped from the top of
> tree LLDB a while ago because it was not tested and was bit rotting.
> >
> > We do have a lldb-vscode binary that implements the Microsoft Visual
> Studio Code DAP (Debug Adaptor Protocol). If there are any Eclipse plug-ins
> that integrated with the VS Code DAP plug-ins, that would be the option I
> would suggest looking into. Is using Visual Studio Code an option, or only
> Eclipse?
> >
> >> The platform in question is Microsoft Windows 10 (recent versions).
> >>
> >> Thx in advance
> >>
> >> Franz
> >>
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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/CMakeLists.txt for 
the copy (on non-unix hosts) procedure.

Did you recently change your version of swig? LLDB requires swig 2, but, as you 
pointed out last year, there are issues with some versions of swig. We use 
4.0.1 on Windows.

> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Wednesday, November 4, 2020 2:49 AM
> To: Adrian McCarthy ; LLDB  d...@lists.llvm.org>
> Subject: [EXT] Re: [lldb-dev] Need help with failing LLDB tests on Windows
>
> On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote:
> > For the past couple weeks, I've been trying to figure out why
> > approximately 900+ LLDB tests have been failing for me on my local
> > Windows builds.  Bisect turned up nothing--the "good" version that was
> > working for me no longer works.  Since nobody else seems to be seeing
> > these failures, I suspect it's something environmental.
> >
> > There are three categories of errors.  I'm currently focused on
> > failures that look like this:
> >
> > FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py (732
> > of 2180)
> >  TEST 'lldb-api ::
> > lang/objc/unicode-string/TestUnicodeString.py' FAILED
> > 
> > Script:
> > --
> > C:/Program Files/Python38/python.exe
> > D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS
> > -u CFLAGS --enable-crash-dialog --env
> > LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64
> > --build-dir D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
> > D:/src/llvm/build/ninja_dbg/lldb-test-traces --lldb-module-cache-dir
> > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> lldb\lldb-api
> > --clang-module-cache-dir
> > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> clang\lldb-api
> > --executable D:/src/llvm/build/ninja_dbg/./bin/lldb.exe --compiler
> > D:/src/llvm/build/ninja_dbg/bin/clang.exe --dsymutil
> > D:/src/llvm/build/ninja_dbg/./bin/dsymutil.exe --filecheck
> > D:/src/llvm/build/ninja_dbg/./bin/FileCheck.exe --yaml2obj
> > D:/src/llvm/build/ninja_dbg/./bin/yaml2obj.exe --lldb-libs-dir
> > D:/src/llvm/build/ninja_dbg/./lib
> > D:\src\llvm\llvm-project\lldb\test\API\lang\objc\unicode-string -p
> > TestUnicodeString.py
> > --
> > Exit Code: 1
> >
> > Command Output (stdout):
> > --
> > lldb version 12.0.0 (https://github.com/llvm/llvm-project.git
> >  revision
> > 0fdcd1ae1c988fa19d0c97e9e8678b93a0da)
> >clang revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
> >llvm revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
> >
> > --
> > Command Output (stderr):
> > --
> > Traceback (most recent call last):
> >File
> > "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
> > line 35, in 
> >  import _lldb
> > ModuleNotFoundError: No module named '_lldb'
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >File "D:/src/llvm/llvm-project/lldb\test\API\dotest.py", line 7,
> > in 
> >  lldbsuite.test.run_suite()
> >File
> > "D:\src\llvm\llvm-
> project\lldb\packages\Python\lldbsuite\test\dotest.py",
> > line 874, in run_suite
> >  import lldb
> >File
> > "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
> > line 38, in 
> >  from . import _lldb
> > ImportError: cannot import name '_lldb' from partially initialized
> > module 'lldb' (most likely due to a circular import)
> > (D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py)
> >
> >
> > It looks like the code in question is generated by Swig (so perhaps it
> > depends on the version of Swig?).  The relevant bit seems to be:
> >
> > try:
> >  # Try an absolute import first.  If we're being loaded from lldb,
> >  # _lldb should be a built-in module.
> >  import _lldb
> > except ImportError:
> >  # Relative import should work if we are being loaded by Python.
> > from . import _lldb
> >
> >
> > I don't have much background in Python modules or how Swig produces
> > the bindings.  It seems suspicious to me that both import attempts are
> > failing (and that we need two).
>
> The reason behind the two imports is that lldb+python have two ways of
> loading each other, depending on who is "on top".
>
> If you're starting with a c++ program (e.g. lldb driver), then the (lib)lldb 
> library
> will be loaded 

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

[Ted Woodward via lldb-dev]

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 memories. These 
often use the same addresses, so to distinguish between them you need address 
spaces. The Motorola DSP56300 had 1 program and 2 data memories, called p, x 
and y. p:100, x:100 and y:100 were all separate memories, so "address 100" 
isn't enough to get what the user needed to see.

For low level hardware debugging (often using JTAG), many devices let you 
access memories in ways like "virtual using the TLB", or "virtual == physical, 
through the core", or "physical, through the SoC, not cached". Memory spaces, 
done right, can give the user the flexibility to pick how to view memory.


Are these the use cases you were envisioning, Jonas?

> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Tuesday, October 20, 2020 12:51 PM
> To: Jonas Devlieghere ; LLDB  d...@lists.llvm.org>
> Subject: [EXT] Re: [lldb-dev] [RFC] Segmented Address Space Support in
> LLDB
>
> There's a lot of things that are unclear to me about this proposal. The
> mechanics of representing an segmented address are one thing, but I I think
> that the really interesting part will be the interaction with the rest of 
> lldb. Like
> - What's going to be the source of this address space information? Is it going
> to be statically baked into lldb (a function of the target architecture?), or
> dynamically retrieved from the target or platform we're debugging? How
> would that work?
> - How is this going to interact with Object/SymbolFile classes? Are you
> expecting to use existing object and symbol formats for address space
> information, or some custom ones? AFAIK, none of the existing formats
> actually support encoding address space information (though that hasn't
> stopped people from trying).
>
> Without understanding the bigger picture it's hard for me to say whether the
> proposed large scale refactoring is a good idea. Nonetheless, I am doubtful of
> the viability of that approach. Some of my reasons for that are:
> - not all addr_ts represent an actual address -- sometimes that is a 
> difference
> between two addresses, which still uses addr_t, as that's guaranteed to fit.
> - relatedly to that, there is a difference (I'd expect) between the operations
> supported by the two types. addr_t supports all integral operations (though I
> hope we don't use all of them), but I wouldn't expect to be able to do the
> same with a SegmentedAddress. For one, I'd expect it wouldn't be possible
> to add two SegmentedAddresses together (which is possible for addr_t).
> OTOH, adding a SegmentedAddress and an addr_t would probably be fine?
> Would subtracting two SegmentedAddresses should result in an addr_t? But
> only if they have matching address spaces (and assert otherwise)?
> - I'd also be worried about over-generalizing specialized code which can
> afford to work with plain addresses, and where the added address space
> would be a nuisance (or a source of bugs). E.g. ELF has no notion of address
> space, so I don't think I'd find it helpful to replace all plain integer 
> calculations
> in elf parsing code with something more complex.
> (I'm aware that some people are using elf to encode address space
> information, but this is a pretty nonstandard extension, and it'd take more
> than type substitution to support anything like that.)
> - large scale refactorings are very much not the norm in llvm
>
>
>
> On 19/10/2020 23:56, Jonas Devlieghere via lldb-dev wrote:
> > We want to support segmented address spaces in LLDB. Currently, all of
> > LLDB’s external API, command line interface, and internals assume that
> > an address in memory can be addressed unambiguously as an addr_t (aka
> > uint64_t). To support a segmented address space we’d need to extend
> > addr_t with a discriminator (an aspace_t) to uniquely identify a
> > location in memory. This RFC outlines what would need to change and
> > how we propose to do that.
> >
> > ### Addresses in LLDB
> >
> > Currently, LLDB has two ways of representing an address:
> >
> >   - Address object. Mostly represents addresses as Section+offset for
> > a binary image loaded in the Target. An Address in this form can
> > persist across executions, e.g. an address breakpoint in a binary
> > image that loads at a different address every execution. An Address
> > object can represent memory not mapped to a binary image. Heap, stack,
> > jitted items, will all be represented as the uint64_t load address of
> > the object, and cannot persist across multiple executions. You must
> > have the Target object available to get the current load address of an
> > Address object in the current process run. Some parts of lldb do not
> > have a Target available to 

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

[Ted Woodward via lldb-dev]

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 with top-of-tree on Ubuntu 16:

bin/lldb /bin/ls -o "process launch -s" -s dis.lldb
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) process launch -s
Process 32258 launched: '/bin/ls' (x86_64)
(lldb) command source -s 0 'dis.lldb'
Executing commands in '/local/mnt/ted/tip/full/dis.lldb'.
(lldb) thread select 1
(lldb) disassemble --start-address $pc-24 --end-address $pc+24
* thread #1, name = 'ls', stop reason = signal SIGSTOP
frame #0: 0x77dd7c30 ld-2.23.so`_start
ld-2.23.so`_start:
->  0x77dd7c30 <+0>: movq   %rsp, %rdi
0x77dd7c33 <+3>: callq  0x77dd89b0; _dl_start at 
rtld.c:353

ld-2.23.so`_dl_start_user:
0x77dd7c38 <+0>: movq   %rax, %r12
0x77dd7c3b <+3>: movl   0x225037(%rip), %eax  ; _dl_skip_args
ld-2.23.so`oom:
0x77dd7c18 <+13>: xorl   %eax, %eax
0x77dd7c1a <+15>: callq  0x77de88f0; _dl_dprintf at 
dl-misc.c:275
0x77dd7c1f <+20>: movl   $0x7f, %edi
0x77dd7c24 <+25>: callq  0x77df24f0; __GI__exit at 
_exit.c:27
0x77dd7c29:   nopl   (%rax)
ld-2.23.so`_start:
->  0x77dd7c30 <+0>:  movq   %rsp, %rdi
0x77dd7c33 <+3>:  callq  0x77dd89b0; _dl_start at 
rtld.c:353

ld-2.23.so`_dl_start_user:
0x77dd7c38 <+0>:  movq   %rax, %r12
0x77dd7c3b <+3>:  movl   0x225037(%rip), %eax  ; _dl_skip_args
0x77dd7c41 <+9>:  popq   %rdx
0x77dd7c42 <+10>: leaq   (%rsp,%rax,8), %rsp
0x77dd7c46 <+14>: subl   %eax, %edx
(lldb)

Note that the address goes from c3b to c18 right after ld-2.23.so`oom.

How can I separate the outputs of thread select and disassemble? If I stick in 
something like "register read pc" in between the thread select and the dis, I 
get the output from it before the output from the thread select and dis.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 function

Hi LLDB devs,

I have almost finished porting LLDB to my architecture, now LLDB communicates 
well with my GDB stub of my simulator and can do debugging actions like 
breakpoint, continue, step, reading memory, reading registers and so on. Thanks 
to all of your kind advice~

Now I consider adding disassemble function. Our compiler is LLVM(of course 
after porting it to our new architecture) and a LLVM disassembler has already 
been implemented, which can do great objdump from the ELF file that LLVM 
generates, creating a .map file containing disassemble. LLDB leverages the 
disassembler from LLVM, so our LLDB can easily use that disassembler plug-in. 
Here comes problems:
I found that when LLDB deals with command "disassemble/dis/di", it would detect 
the current frame, confirm the disassemble address range, send a "m" packet to 
read the corresponding memory to get the program, and use LLVM disassembler 
plug-in to disassemble the code, which I would like to call it "dynamic 
disassembling". But in our architecture, program and data are in separated 
memory which have the same address space. When reading memory, we just read the 
data memory not the program memory, in other words, program/code cannot be 
accessed from processor, only from ELF file(program/code won't be altered 
during run time, we use hardware breakpoint).

So:
Can LLDB do "static disassembling"? (which just uses program/code from the ELF 
executable file without reading memory from the processor during run time)

Kind regards,
Rui

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 command like "log enable gdb-remote 
packets" in lldb to print all the RSP packet exchange?

“set debug remote 1”
Unlike with lldb, this doesn’t work when you do a run. It only works when you 
do a target remote (at least with the default gdb installed on Ubuntu 16.04).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Minimum required swig version?

[Ted Woodward via lldb-dev]

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/API/python_api/sbenvironment/TestSBEnvironment.py has this line:
env.Set("FOO", "bar", overwrite=True)

lldb built with swig 2.0.11 fails this test with the error:
env.Set("FOO", "bar", overwrite=True)
TypeError: Set() got an unexpected keyword argument 'overwrite'

It works when lldb is built with swig 3.0.8.

inspect.getsource(lldb.SBEnvironment) gives the following:
swig 2.0.11:
  """Set(SBEnvironment self, char const * name, char const * value, bool 
overwrite) -> bool"""\nreturn _lldb.SBEnvironment_Set(self, *args)\n\n
swig 3.0.8:
"""Set(SBEnvironment self, char const * name, char const * value, bool 
overwrite) -> bool"""\nreturn _lldb.SBEnvironment_Set(self, name, 
value, overwrite)\n\n\n

Is swig 3 required? Do we need to update the build page?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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. That’s fairly involved, so I’m going to 
skip it for now.


For the attach case, you run your simulator, with the program on the command 
line. Then in a separate shell you launch lldb with the program, and run the 
gdb-remote command to connect to it. You’ve got this already, from your message 
below.

When you attach to the simulator, it comes up stopped, probably at the 
entrypoint, but that’s dependent on your simulator. To continue, issue a 
“continue” command. You’ll probably want to set a breakpoint first!

To answer your questions:

  1.  There is no “load” command, but if you make a platform for your target 
you can add one. Existing platforms (like the remote Linux platform) have the 
capability to send the binary to the remote server and tell it to run. For 
Hexagon we don’t do that; instead when we “run” we build a hexagon-sim command 
line that tells the simulator to load the program. If you’re launching the 
simulator separately for the attach case it’s easiest to include the binary on 
the simulator command line.
  2.  No, “gdb-remote” only makes the RSP connection.
  3.  That depends on your simulator. It looks like it just does an attach, and 
you’ll need to do the continue manually. That’s probably best, because lldb 
expects the remote gdbserver to be stopped when you connect to it.
  4.  No, but it’s probably easiest.

Ted

From: lldb-dev  On Behalf Of Rui Hong via 
lldb-dev
Sent: Thursday, April 16, 2020 4:31 AM
To: lldb-dev 
Subject: [EXT] [lldb-dev] LLDB problems on remote debugging

Hi LLDB devs,

I'm working on porting LLDB to work with an existing simulator(which has GDB 
stub, remote debugging). This simulator used to work with GDB. When using with 
GDB, the target file(ELF) is loaded by GDB command "load" or "remote put".
>From a LLVM talk project which is very similar to my project, their target 
>file is loaded by the simulator itself(   ./sim a.out   , something like 
>that), and lldb sets breakpoint, use "gdb-remote" command to connect to the 
>simulator, the program starts to run immediately and stop at the breakpoint.
I can't find any lldb command that is equal to "load" in GDB. And right now 
when I use "gdb-remote" to connect lldb to my simulator, lldb has command line 
output "Process 10115 stopped，thread #1, stop reason = signal SIGTRAP，frame #0: 
0x". Does this mean the program has already started to run? I 
haven't loaded the binary.

To sum my questions:
1. Does lldb has similar command like "load/remote put" in GDB?
2. Does "gdb-remote" command in lldb do the "loading binary" job?
3. Will the program start to run immediately after "gdb-remote" command in lldb?
4. Do I have to let my simulator to load the binary by itself?

Kind regards,
Rui

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Default script language

[Ted Woodward via lldb-dev]

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, and which is 
the default if there are more than 1 supported. Maybe in lldb --version?

Ted

-Original Message-
From: lldb-dev  On Behalf Of Jim Ingham via 
lldb-dev
Sent: Wednesday, April 1, 2020 5:43 PM
To: Ed Maste 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] Default script language

Right now, Lua is not nearly as well supported as Python, so it makes sense 
that if both Python and Lua are available Python should be the default.  But at 
some point Lua will become an equal to Python.  When that happens, it seems to 
me the default scripting language choice should be up to the package 
distributor.  I don’t see why we need to weigh in on that.  That would imply 
that the default should be an independent build setting.  Not sure that means 
we need to do it that way now, but if we don’t want to do it twice…

Jim


> On Apr 1, 2020, at 2:09 PM, Ed Maste via lldb-dev  
> wrote:
>
> In lldb/include/lldb/lldb-enumerations.h we have:
> eScriptLanguageDefault = eScriptLanguagePython
>
> I'd like to do something like:
> #if LLDB_ENABLE_PYTHON
> eScriptLanguageDefault = eScriptLanguagePython #elif LLDB_ENABLE_LUA
> eScriptLanguageDefault = eScriptLanguageLua #else
> eScriptLanguageDefault = eScriptLanguageNone #endif
>
> if we could include Config.h, or achieve the same effect in some other
> way if we cannot. Does this seem reasonable?
>
> I'm interested in this for lldb in the FreeBSD base system. We have
> lua available already (and no python) and I've integrated our liblua
> it into lldb, but it required "--script-language lua" on the command
> line. For now I'll just change the default to be eScriptLanguageLua in
> our tree, but would like to have this "just work" upstream.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

I believe there are more than 1 python install on the machines, but we set the 
PYTHON_HOME cmake variable to get it to use the Python we want. Both copies 
spit out 3.5.1 when I print sys.version (but both are using the same 
python35.dll).

Both machines are 64 bit; I’m launching lldb from both a cmd window and by 
double clicking its icon. Behavior is the same either way.

Looking into differences, I’m using swig 3.0.12 and the bot is using swig 
3.0.2. I’m building with 3.0.2 on my machine right now, but it will take a 
while to finish!

From: Adrian McCarthy 
Sent: Friday, February 21, 2020 3:12 PM
To: Ted Woodward 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 
copies of liblldb.dll/_lldb.pyd)

Just guessing:  Does either machine have more than one Python installation?

Windows Server is, by default, more locked down than the standard editions, 
which can affect the search path.  Perhaps you're not getting the Python you 
think you're getting on one of the machines.

Are both machines 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 
mailto:lldb-dev@lists.llvm.org>> wrote:
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-packages.

I checked both versions using Process Explorer to see loaded dlls. The version 
I built on my Windows machine (Win 10, VS 2017, Python 3.5.1, works) shows 
liblldb.dll. The version built on the bot (Windows Server 2016, VS 2017, Python 
3.5.1, but doesn’t work) shows _lldb.pyd and liblldb.dll.

In both cases we use cmake to build a VS solution. On my machine I built lldb 
in Visual Studio. On the bot we call msbuild to build the RELEASE 
configuration. The bot then does an install. I also did an install, and my 
installed version works correctly.

Does anybody have any idea why lldb built on the bot would load the dll twice, 
but lldb built on my machine would load it once?

Ted
___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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

I checked both versions using Process Explorer to see loaded dlls. The version 
I built on my Windows machine (Win 10, VS 2017, Python 3.5.1, works) shows 
liblldb.dll. The version built on the bot (Windows Server 2016, VS 2017, Python 
3.5.1, but doesn't work) shows _lldb.pyd and liblldb.dll.

In both cases we use cmake to build a VS solution. On my machine I built lldb 
in Visual Studio. On the bot we call msbuild to build the RELEASE 
configuration. The bot then does an install. I also did an install, and my 
installed version works correctly.

Does anybody have any idea why lldb built on the bot would load the dll twice, 
but lldb built on my machine would load it once?

Ted
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 get a mask of 0x0f.
I think that should be 1ull, or (uint64_t) 1, not 1ul.

MSDN problem talking about the size of ul:
https://developercommunity.visualstudio.com/content/problem/226112/vs2017-1ul-32-is-evaluated-to-0-in-watch-window-du.html

Thoughts?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

> > * 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 the
> right one at runtime.

It's not just the python dll; it's the modules directory as well. My 
experiments with different versions of Python on Linux led me to just ship the 
right python with our distribution.

I saw things like building with 2.7.6 but using the 2.7.3 library/modules (and 
vice versa) would crash, and building with 2.7.6 but running with 2.6.x seemed 
to be OK, mostly. On Windows, I had crashes when loading Python 2.7.8 from 
python.org (built with VS 2008) in lldb built with VS 2013, so you have to 
think about other library dependencies too.

My conclusion - you MUST use the same python that lldb was built with. Period.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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-darwin and 
LLVM_HOST_TRIPLE should be something like x86_64-apple-darwin. I'm not sure 
what the exact triples are :-)

When we build Hexagon tools, LLVM_DEFAULT_TARGET_TRIPLE, LLVM_TARGET_ARCH and 
TARGET_TRIPLE are hexagon-unknown--elf. LLVM_HOST_TRIPLE is either 
x86_64-unknown-linux or x86_64-pc-windows.

> -Original Message-
> From: lldb-dev  On Behalf Of Jim Ingham via
> lldb-dev
> Sent: Wednesday, October 30, 2019 1:37 PM
> To: LLDB 
> Subject: [EXT] [lldb-dev] Making LLVM_DEFAULT_TARGET_TRIPLE available to
> lldb's cmakery
>
> Hi, all...
>
> Saleem submitted a patch to work around some other changes in llvm
> cmakery that was making LLVM_DEFAULT_TARGET_TRIPLE undefined when
> lldb went to use it for the macOS debugserver build.
>
> That was:
>
> commit 55eec2ba96bd9c19ccb5d4d13cb8c88d4abcebc6
> Author: Saleem Abdulrasool 
> Date:   Tue Oct 29 08:20:58 2019 -0700
>
> build: workaround stale caches (NFC)
>
> `LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it
> may actually be unset.  Furthermore, in standalone builds, the variable
> may be fully undefined.  Apply the regular expression over the empty
> string in such a case.  This should improve the state of the green
> dragon bot.
>
> But that change:
>
> -string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> ${LLVM_DEFAULT_TARGET_TRIPLE})
> +string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> +"${LLVM_DEFAULT_TARGET_TRIPLE}")
>
> didn't work.  If LLVM_DEFAULT_TARGET_TRIPLE is not set, then CMake fails
> with:
>
> CMake Error at tools/debugserver/source/MacOSX/CMakeLists.txt:13 (string):
>   string sub-command REGEX, mode MATCH regex "^[^-]*" matched an empty
>   string.
>
> and the generation stops.
>
> It seems weird to me that successfully matching against an empty string is an
> error, I'd think you would copy an empty string to the target variable.  But 
> my
> knowledge of CMake pretty much stops at "the C and the M are capitalized,
> the rest aren't..."
>
> Anyway, another way to do this would be something like:
>
> #if (${LLVM_DEFAULT_TARGET_TRIPLE})
>   string(REGEX MATCH "^[^-]*" LLDB_DEBUGSERVER_ARCH
> "${LLVM_DEFAULT_TARGET_TRIPLE}")
> #else()
> #  set(LLDB_DEBUGSERVER_ARCH "")
> #endif()
>
> Which would then dial up the default architecture (x86_64) further on.  But
> Vedant thought instead of this, it would be more generally useful to assure
> that LLVM_DEFAULT_TARGET_TRIPLE was exported, like:
>
> diff --git i/llvm/cmake/modules/LLVMConfig.cmake.in
> w/llvm/cmake/modules/LLVMConfig.cmake.in
> index 7fdca536c1f..e875e661a02 100644
> --- i/llvm/cmake/modules/LLVMConfig.cmake.in
> +++ w/llvm/cmake/modules/LLVMConfig.cmake.in
> @@ -92,6 +92,7 @@ set(LLVM_TOOLS_INSTALL_DIR
> "@LLVM_TOOLS_INSTALL_DIR@")  set(LLVM_HAVE_OPT_VIEWER_MODULES
> @LLVM_HAVE_OPT_VIEWER_MODULES@)
> set(LLVM_CONFIGURATION_TYPES @CMAKE_CONFIGURATION_TYPES@)
> set(LLVM_ENABLE_SHARED_LIBS @BUILD_SHARED_LIBS@)
> +set(LLVM_DEFAULT_TARGET_TRIPLE "@LLVM_DEFAULT_TARGET_TRIPLE@")
>
>  if(NOT TARGET LLVMSupport)
>set(LLVM_EXPORTED_TARGETS "@LLVM_CONFIG_EXPORTS@")
>
> I'm a little hesitant to propose this change as I don't have a good sense of 
> the
> ramifications of doing this, or why it wasn't done this way to begin with.
>
> LLVM_DEFAULT_TARGET_TRIPLE seems like an oddly named variable to use
> for the host OS that we're building for.  If I build an x86_64-darwin hosted
> compiler but only included the arm backend, it would be odd to have the
> default target triple be x86_64-darwin, so I'm surely missing something...
>
> Anyway, so I wanted first to float the question here before suggesting a
> change.
>
> Jim
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 McCarthy 
via lldb-dev
Sent: Monday, October 28, 2019 12:10 PM
To: Jonas Devlieghere 
Cc: Serge Guelton ; LLDB Dev 
Subject: [EXT] Re: [lldb-dev] issue with lldb9 and python3.5

+1 Yes, for Windows, I'd be happy if we said Python 3.6+.

On Mon, Oct 28, 2019 at 10:07 AM Jonas Devlieghere via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
On Mon, Oct 28, 2019 at 10:04 AM Jonas Devlieghere
mailto:jo...@devlieghere.com>> wrote:
>
> On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard 
> mailto:tstel...@redhat.com>> wrote:
> >
> > On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> > > Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> > > and Python 3.7. I'm sorry if we forgot that in the release notes.
> > >
> >
> > Is there a specific reason why 3.5 is not supported?  Is it
> > because of this issue?
>
> Not really other than the lack of testing/CI.
>
> - The Linux bots are all running with Python 2.7.
> - I know that on macOS we ran into issues with some older versions. I
> don't remember if it was this particular issue and I'm not even sure
> if that was using Python 3.5 or Python 3.6. Our bots on GreenDragon
> all run with Python 3.7.
> - Stella's Windows bot is running Python 3.6 so we should consider
> that supported as well.

For completeness, Python 2.7 is not supported on Windows at all. The
docs specify Python 3.5 or later. Maybe we should bump that to 3.6
too?

>
> >
> > -Tom
> >
> > > On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
> > > mailto:lldb-dev@lists.llvm.org>> wrote:
> > >>
> > >> + lldb-dev
> > >>
> > >> On 10/28/2019 07:06 AM, Tom Stellard wrote:
> > >>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
> >  Hi everyone,
> > 
> >  I have lldb crashing since I've updated to lldb9. Seems like there is 
> >  a issue with python3.5. Everything seems to work fine with python3.7.
> >  Am I missing something? Or is it a known issue?
> > 
> > >>>
> > >>> We have seen this too with python 3.6, but we haven't found the root 
> > >>> cause yet.
> > >>> For now, we've worked around this by disabling the readline module with 
> > >>> the
> > >>> attached patch.
> > >>>
> > >>> -Tom
> > >>>
> >  $ lldb
> >  (lldb) script
> >   #0 0x7f3d324c9c2a 
> >  llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
> >  (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bfc2a)
> >   #1 0x7f3d324c7af5 llvm::sys::RunSignalHandlers() 
> >  (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdaf5)
> >   #2 0x7f3d324c7c0c SignalHandler(int) 
> >  (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdc0c)
> >   #3 0x7f3d31bfe0e0 __restore_rt 
> >  (/lib/x86_64-linux-gnu/libpthread.so.0+0x110e0)
> >   #4 0x7f3d2d18f81b PyModule_GetState 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x6881b)
> >   #5 0x7f3d230e1621 _init 
> >  (/usr/lib/python3.5/lib-dynload/readline.cpython-35m-x86_64-linux-gnu.so
> >   +0x3621)
> >   #6 0x7f3d2e3dece1 rl_initialize 
> >  (/usr/lib/x86_64-linux-gnu/libedit.so.2+0x1dce1)
> >   #7 0x7f3d230e1f3e _init 
> >  (/usr/lib/python3.5/lib-dynload/readline.cpython-35m-x86_64-linux-gnu.so
> >   +0x3f3e)
> >   #8 0x7f3d2d32d710 _PyImport_LoadDynamicModuleWithSpec 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x206710)
> >   #9 0x7f3d2d330fe7 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x209fe7)
> >  #10 0x7f3d2d198259 PyCFunction_Call 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71259)
> >  #11 0x7f3d2d2c8ff2 PyEval_EvalFrameEx 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a1ff2)
> >  #12 0x7f3d2d38b074 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074)
> >  #13 0x7f3d2d2c7adf PyEval_EvalFrameEx 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a0adf)
> >  #14 0x7f3d2d2c96ad PyEval_EvalFrameEx 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> >  #15 0x7f3d2d2c96ad PyEval_EvalFrameEx 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> >  #16 0x7f3d2d2c96ad PyEval_EvalFrameEx 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> >  #17 0x7f3d2d2c96ad PyEval_EvalFrameEx 
> >  (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad)
> > 

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

[Ted Woodward via lldb-dev]

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-
> From: Michał Górny 
> Sent: Friday, October 11, 2019 8:35 AM
> To: Ted Woodward ; LLDB  d...@lists.llvm.org>; h...@google.com; antonio.afo...@gmail.com
> Subject: [EXT] Re: LLDB finish_swig and Python module installation broken for
> multi-configuration generators
>
> On Thu, 2019-10-10 at 23:11 +, Ted Woodward wrote:
> > 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 directories.
> >
> > For the symlink, I get this output:
> >  Making symlink from ..\..\..\bin\liblldb.dll to
> > i:\obj\lib\site-packages\lldb\_lldb.pyd
> > ...
> >  WindowsError: [Error 2] The system cannot find the file specified:
> '..\\..\\..\\bin\\liblldb.dll'
> >
> > Because the cwd is I:\obj\Lib\site-packages\lldb, not the correct
> I:\obj\Release\Lib\site-packages\lldb. liblldb.dll is in i:\obj\Release\bin, 
> not
> i:\obj\bin. Also, the link itself should be in i:\obj\Release\lib, not 
> i:\obj\lib.
> >
> > The problem is the cmake code went from using
> LLVM_LIBRARY_OUTPUT_INTDIR to CMAKE_BINARY_DIR. CMAKE_BINARY_DIR
> is not complete for multi-configuration generators - you need to specify the
> configuration as well.
> >
> [...]
> > Michal, please try this and see if it still works for the issue you fixed in
> r372835.
>
> Actually, I see that Haibo has already addressed this 2 days ago.  Could you
> test if his solution (r374250) works for you?
>
> --
> Best regards,
> Michał Górny

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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

For the symlink, I get this output:
 Making symlink from ..\..\..\bin\liblldb.dll to 
i:\obj\lib\site-packages\lldb\_lldb.pyd
...
 WindowsError: [Error 2] The system cannot find the file specified: 
'..\\..\\..\\bin\\liblldb.dll'

Because the cwd is I:\obj\Lib\site-packages\lldb, not the correct 
I:\obj\Release\Lib\site-packages\lldb. liblldb.dll is in i:\obj\Release\bin, 
not i:\obj\bin. Also, the link itself should be in i:\obj\Release\lib, not 
i:\obj\lib.

The problem is the cmake code went from using LLVM_LIBRARY_OUTPUT_INTDIR to 
CMAKE_BINARY_DIR. CMAKE_BINARY_DIR is not complete for multi-configuration 
generators - you need to specify the configuration as well.

To fix it, in lldb/CMakeLists.txt change
if(LLDB_BUILD_FRAMEWORK)
  set(lldb_python_build_path 
"${liblldb_build_dir}/LLDB.framework/Resources/Python/lldb")
else()
  set(lldb_python_build_path 
"${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/lldb")
endif()

to:
if(LLDB_BUILD_FRAMEWORK)
  set(lldb_python_build_path 
"${liblldb_build_dir}/LLDB.framework/Resources/Python/lldb")
else()
  if(CMAKE_CFG_INTDIR)
   # use CMAKE_BUILD_TYPE here because CMAKE_CFG_INTDIR is ${Configuration}
# using Visual Studio, which won't work in cmake_install.cmake
# because it is a VS variable, not a cmake variable
install(DIRECTORY 
${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  else()
install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  endif()
endif()


In the install step we have a similar failure. The install in 
lldb/CMakeLists.txt again uses CMAKE_BINARY_DIR. To fix it, change:
  install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
  DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
  COMPONENT lldb-scripts)
to:
  if(CMAKE_CFG_INTDIR)
install(DIRECTORY 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  else()
install(DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_PYTHON_RELATIVE_PATH}/
DESTINATION ${LLDB_PYTHON_RELATIVE_PATH}
COMPONENT lldb-scripts)
  endif()


Michal, please try this and see if it still works for the issue you fixed in 
r372835.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 go up and down 
the stack, switching languages as needed. "What was my Python code doing when 
it called into the library. Now what is the library doing?"

> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Tuesday, September 24, 2019 6:11 AM
> To: Larry D'Anna 
> Cc: lldb-dev@lists.llvm.org
> Subject: [EXT] Re: [lldb-dev] RFC: full support for python files, and avoid 
> using
> FILE* internally
>
> On 23/09/2019 20:54, Larry D'Anna wrote:
> >
> >
> >> On Sep 23, 2019, at 7:11 AM, Pavel Labath  wrote:
> >>
> >> On 20/09/2019 17:35, Larry D'Anna via lldb-dev wrote:
> >>> Hi lldb-dev.
> >>> I want to be able to use LLDB inside of iPython, so I can have mixed
> python and LLDB debug session.
> >>> To this end, I’d like to update LLDB to have full support for python
> >>> file objects, so the outputs of
> debugger commands can be redirected into iPython’s own streams.
> >>> This however, is difficult to do, because LLDB makes use of FILE* streams
> in a number of places.   This presents two problems.  The first is that there 
> is
> no really
> >>> correct way to create SWIG typemaps that handle conversion to FILE*
> and get the ownership semantics correct.   The second problem is that there
> is not a portable
> >>> way to make a FILE* with arbitrary callbacks for reading and writing.   On
> Darwin and BSD there’s funopen, and on linux there’s something else, and I
> don’t know if
> >>> there’s any way on windows.
> >>> I made an attempt at this a while ago using funopen a while ago, here:
> >>> https://reviews.llvm.org/D38829
> >>> Zachary Turner suggested a more thorough approach. where instead of
> >>> trying to use funopen to paper over all the use of FILE* streams, we
> should make lldb_private::File capable of doing the dynamic dispatch and
> excise all the unnecessary FILE* stuff in favor of lldb_private::File.
> >>> That’s what I’ve done here:
> >>> https://github.com/smoofra/llvm-project/tree/files
> >>> I’ve posted the first few patches to phabricator for review.
> >>> https://reviews.llvm.org/D67793
> >>> https://reviews.llvm.org/D67792
> >>> https://reviews.llvm.org/D67789
> >>> What do you think?
> >>
> >>
> >>
> >> Hello Larry,
> >>
> >> thanks for starting this thread.
> >>
> >> So, judging by your problem description, it sounds to me like you're
> primarily interested in the SBCommandInterpreter::HandleCommand family of
> functions (and by extension, the SBCommandReturnObject class). Would that
> be a fair thing to say?
> >
> > Not really.  I want to be able to embed a full LLDB session inside of 
> > iPython,
> which means redirecting anything that prints to the debugger's main output
> and error streams. Yes, in most cases that will be coming from
> HandleCommand(), but I really want to avoid the situation where some output
> that would normally be printed to the terminal is missed under iPython.
>
> Ok, that's fair.
>
> >
> >> The reason I am asking this is that I'm wondering what is the scope of the
> thing you're proposing to do (and then, whether this is the best way to
> accomplish that). For instance, if we were only interested in the
> HandleCommand api, then it might be possible to plug the python in at a
> higher level (Stream instead of File). I am hoping that doing that might be
> easier as the Stream class has a simpler interface, and already supports
> multiple backing implementations (StreamFile, StreamString, ...).
> >>
> >> Also, doing that would allow to side step some complicated questions. One
> of the reasons why getting rid of FILE* is so complicated (you're not the 
> first
> person to try that) is that there are some APIs (libedit mainly), that we just
> cannot change, and which require a FILE*.
> >
> > I saw that.   My strategy for dealing with that was to audit the codebase 
> > for
> any use of File::GetStream().   I found the only two places I could not remove
> the use of GetStream() was libedit and IOHandlerCursesGUI.In my
> prototype, I deal with that by checking for NULL from GetStream() before
> libedit or IOHandlerCursesGUI are enabled. In other words, If a File can
> produce a FILE*, it will.   But you can still  have a valid File that will 
> return NULL
> from GetStream.   If you set your debugger streams to Files that return 
> NULL
> from GetStream, then libedit and the curses GUI will be disabled.I think 
> this
> is a reasonable approach.For my use-case in particular, there is no need 
> for
> either libedit or the curses gui, because the whole point is to use iPython as
> the gui.  In general, libedit and curses only really make sense if the IO
> streams are a terminal anyway, so it’s 

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

[Ted Woodward via lldb-dev]

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) was built 
with 2015, and the 2017 linker didn’t like linking against the debug library 
built with 2015.

I switched from a Debug build to RelWithDebInfo, and it worked.

Ted

From: lldb-dev  On Behalf Of Larry D'Anna via 
lldb-dev
Sent: Sunday, September 22, 2019 1:21 PM
To: lldb-dev@lists.llvm.org
Subject: [EXT] [lldb-dev] help, how to get a debug build on windows 
(python37_d.lib)

Hi lldb-dev.

I can’t seem to figure out how to build a debug lldb on windows.   It wants to 
link against a debug version of Python, which isn’t there.

My cmake line looks like this:

cmake -G Ninja `
"-DPYTHON_HOME=C:\Program Files (x86)\Microsoft Visual 
Studio\Shared\Python37_64" `
"-DLLVM_ENABLE_PROJECTS=clang;lldb;libcxx;libcxxabi;lld" `
 "-DSWIG_EXECUTABLE=C:\ProgramData\chocolatey\bin\swig.exe" `
"C:\Users\smoofra\llvm-project\llvm"
I also made this change, to tell it to link against the release python.

--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -227,7 +227,7 @@ function(find_python_libs_windows)
   else()
 # Lookup for concrete python installation depending on build type
 if (CMAKE_BUILD_TYPE STREQUAL Debug)
-  set(LOOKUP_DEBUG_PYTHON TRUE)
+  set(LOOKUP_DEBUG_PYTHON FALSE)
 else()
   set(LOOKUP_DEBUG_PYTHON FALSE)
 endif()
But somehow at the very end, the link still fails because python37_d.lib isn’t 
there.

Anybody know what I’m doing wrong?  Thank you.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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, September 12, 2019 9:48 PM
To: Adrian Prantl 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] lldb access in Emacs via realgud

Your guess is as good as mine. The one you project link you give looks more 
akin to what I was looking for.

At any rate, rather than try to fix up lldb-mi, I'd put my (limited) resources 
into using one of these and beefing it up if it needs improvement.

On Thu, Sep 12, 2019 at 10:33 PM Adrian Prantl 
mailto:apra...@apple.com>> wrote:



On Sep 12, 2019, at 4:45 PM, Rocky Bernstein 
mailto:r...@dustyfeet.com>> wrote:



On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl 
mailto:apra...@apple.com>> wrote:


> On Sep 12, 2019, at 2:24 PM, Rocky Bernstein 
> mailto:r...@dustyfeet.com>> wrote:
>
>
>
> On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl 
> mailto:apra...@apple.com>> wrote:
>>
>> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev 
>> > mailto:lldb-dev@lists.llvm.org>> wrote:
>> >
>> >
>> > Hi - I just wanted to mention that if there are emacs users there is an 
>> > interface to lldb via realgud. See https://github.com/realgud/realgud-lldb
>> >
>> > A MELPA package and ELPA packageElpa package are available too
>>
>> Nice. It's always exciting to see wider adoption through better editor 
>> integration. Out of curiosity, how does this compare to regular gud.el? 
>> (https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html)
>
> "Regular" gud? The most recent copyright on that link is 2008. I see a gud.el 
> in 26.2 and in the GNU savannah git sources, but neither mentions lldb. 
> Assuming that file is really from 2008, has lldb changed since then? (This is 
> a rhetorical question).  But the broader question is really who is 
> maintaining that file you link, clearly it is not the GNU Emacs community. 
> And how easy is it to do so? I see an "arch" tag on the file, so I guess this 
> in version control somewhere. But if there is a bug in this file, what does 
> one do? (This is not a rhetorical question; if you know the answer, I am 
> interested.)

I think this file is effectively abandoned as it is neither part of the LLDB 
repository nor is it shipping with emacs in macOS any longer.

> Adapted from https://github.com/realgud/realgud/blob/master/realgud.el
>
>> Here we make use of more modern programming practices, more numerous and 
>> smaller files, unit tests, and better use of Emacs primitives, e.g. buffer 
>> marks, buffer-local variables, structures, rings, hash tables. Although 
>> there is still much to be desired, this code is more scalable and suitable 
>> as a common base for an Emacs front-end to modern debuggers.
>> Oh, and because global variables are largely banned, we can support several 
>> simultaneous debug sessions.

> gdb-mi has a nicer multi-frame display,  but you were linking to gud.el which 
> doesn't have that as far as I know. realgud-lldb at this point probably knows 
> more about lldb. But you guys can probably verify that, and if realgud-lldb 
> is lacking, I'd be interested to learn what should be added.
>
> gud has always been a bit too monolithic - it contains every debugger 
> (including some obsolete ones - does anyone really still use dbx, and if so 
> inside Emacs?). All of this is in that one several-thousand-line file. I find 
> this ironic because the principal author is wrote something about "Cathedral 
> versus Bazaar" and this is clearly Cathedral style.
>
> It took me quite a while to be able to break realgud into several distinct 
> files. In fact I had to write my own nodejs-like "require" package to be able 
> to do internal or relative module linking. And then after that, more work was 
> done to split off the debuggers from the core debugger module into separate 
> github projects.

Thanks for explaining the differences!

Is realgud scraping lldb's console output like gud was or is it using the LLDB 
scripting API? If it isn't already you might want to consider using the 
scripting API since LLDB's console output is not necessarily stable, but the 
scripting API is.

Yes, it scrapes console output and that is a problem. A big problem.

I looked at the LLDB API and that seems pretty extensive and seems to cover a 
lot more of what interaction from Emacs would like and is currently missing.

However as is in its current state, this isn't going to cut it because Emacs 
uses its own Lisp, not Python.

I have toyed with the idea of hooking into something more standard, and as I 
said, there are so many to choose from. For example, the V8 debugger protcol 
works over a websocket,  and speaking over a websocket is something you can 
expect IDEs to grok.  Python LLDB's API to say Microsoft's Debug Adaptor 

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

[Ted Woodward via lldb-dev]

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 too generous
> 
> On 30/08/2019 02:33, Jim Ingham via lldb-dev wrote:
> > If I have a program like:
> >
> > class A {
> > public:
> >int AMethod() { return 100; }
> > };
> >
> > class AA {
> > public:
> >int AMethod() { return 200; }
> > };
> >
> > int
> > main()
> > {
> >A myA;
> >AA myAA;
> >myA.AMethod();
> >myAA.AMethod();
> >return 0;
> > }
> >
> > Build and run it under lldb, and do:
> >
> > (lldb) b s -n A::AMethod
> > Breakpoint 1: 2 locations.
> > (lldb) break list
> > Current breakpoints:
> > 1: name = 'A::AMethod', locations = 2
> >1.1: where = many_names`A::AMethod() + 8 at many_names.cpp:3:19,
> address = many_names[0x00010f78], unresolved, hit count = 0
> >1.2: where = many_names`AA::AMethod() + 8 at many_names.cpp:8:19,
> > address = many_names[0x00010f88], unresolved, hit count = 0
> >
> > I think that's wrong.  The point of the fuzziness in -n is that you can 
> > leave out
> containing namespaces, or arguments, and we'll still match what you've given
> us.  But IMO that should only expand the search into containing contexts.  It 
> is
> surprising to me that if I specify A::AMethod, I also match the one in the
> namespace AA.  If you wanted to match .*A::AMethod, you could do that with
> a regular expression.  But there's no easy way to not pick up extra 
> breakpoints
> if you happen to have overlaps like this, so it seems like expanding -n to 
> strstr
> type matches seems like a bad idea.
> >
> > I wondered if other folks thought this was desirable behavior.
> 
> I was surprised by this behavior too. I wouldn't have expected AA::AMethod
> to match this.
> 
> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
  LLDB_LOG_ERROR(log, list.takeError(), "Failed to read module list: {0}");
} else {
  addr = list->m_link_map;
}
  }

If LLVM_ENABLE_ABI_BREAKING_CHECKS is set to 1 (which is true when asserts are 
enabled), llvm::Expected will call abort() if there is an error.
GetLoadedModuleList() has many reasons to set an error, including when XML is 
not available, or when the stub doesn't support remote modules.

I don't think we ever want to crash LLDB if the remote stub doesn't support 
something. I don't think llvm::Expected is the right solution here, and I think 
it should be removed.

Ted
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 lldb-dev
Sent: Tuesday, August 13, 2019 3:18 AM
To: LLDB 
Subject: [EXT] [lldb-dev] lldb-mi has been moved to its own GitHub repository

Hi all,

lldb-mi has been moved out of the LLDB source tree into its own GitHub 
repository here: https://github.com/lldb-tools/lldb-mi lldb-mi is now a 
standalone tool that builds against LLDB, but is no longer build as part of 
LLDB. The implications for users are:

1. Package maintainers need to package lldb-mi and no longer receive the 
lldb-mi executable as a side product of LLDB. The lldb-mi build system is very 
simple, so I don’t expect a lot of problems arising from this change. Note: You 
can *NOT* drop in the lldb-mi source into the old folder inside the LLDB source 
tree. You need to first build LLDB and then build lldb-mi against it.

2. If you encounter bugs with lldb-mi, please file a report on the GitHub 
project and *NOT* on the LLVM bugzilla. We closed all lldb-mi bugs on bugzilla, 
so if you think your issue with lldb-mi still exists, please copy your bug 
report to GitHub.

In other news: lldb-mi is also in need of a maintainer!

The good thing is that with this change lldb-mi you can now make pull requests 
against the project, we set up a CI system and in general its easier to get 
started with lldb-mi. Note that during the move lldb-mi lost its test suit, 
meaning that there are currently no tests run in the CI. This was mostly 
because we couldn’t port over the old test suit (which depended on the internal 
LLDB python test suit) and because most of the tests we had were anyway 
disabled due to random failures. If you want to get started, feel free to make 
pull requests with tests (preferable more reliable than the old ones we had).

I’m mostly writing this as the change was buried in the RFC thread last month 
and it seems all downstream folks are still completely unaware this.

TL;DR: LLDB no longer provides the lldb-mi executable. You now need to 
get lldb-mi from the GitHub repository above.

Cheers,
- Raphael

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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: Jonas Devlieghere 
> Sent: Friday, August 9, 2019 4:57 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: [EXT] Re: How do I use lit to only run the lldb test suite, now that
> dotest multiprocessing capabilities have been removed?
> 
> So far the only thing that changed by removing multiprocess is that `--no-
> multiprocess` is always enabled. Everything else you describe is still 
> possible,
> and will continue to be possible.
> 
> Even when we remove the driver functionality from dotest.py this will all
> continue to work. The only difference is that dotest.py will operate on a 
> single
> file after being invoked by some other driver. The problem you describe with
> the dual arguments seems relatively easy to fix by loading a different
> configuration in lit. It's not something I've looked at yet, because 
> everything
> we care about is configurable from CMake or overridable by passing --params
> to lit.
> 
> 
> On Fri, Aug 9, 2019 at 1:30 PM Ted Woodward 
> wrote:
> >
> > 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-multiprocess). I might 
> be
> running from a directory where I've built lldb (but not clang, using clang 
> from
> an arbitrary location), a directory where I've built everything (but in this 
> case
> we set everything up with cmake), or a directory where I've checkout out just
> the sources and have copied the binaries from a distribution, so no cmake.
> >
> > dotest used to handle these cases; how do I handle them now?
> >
> > In our environment, lldb will launch and connect to the hexagon simulator,
> much like how it launches and connects to debugserver or lldb-server. But it
> has to use a specific version of clang, because we've found that if we have
> mismatches in clang/simulator/RTOS, bad things can happen. User code is in a
> shared library that gets loaded by a wrapper run under the RTOS. The RTOS,
> wrapper and user code all need to be built with the same complier and c/c++
> libraries.
> >
> > Ted
> >
> > > -Original Message-
> > > From: Jonas Devlieghere 
> > > Sent: Friday, August 9, 2019 3:18 PM
> > > To: Ted Woodward 
> > > Cc: LLDB 
> > > Subject: [EXT] Re: How do I use lit to only run the lldb test suite,
> > > now that dotest multiprocessing capabilities have been removed?
> > >
> > > Hey Ted,
> > >
> > > On Thu, Aug 8, 2019 at 2:08 PM Ted Woodward 
> > > wrote:
> > > >
> > > > 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.
> > >
> > > It's not something I touched recently, but it's always possible they
> > > made some changes in LLVM.
> > >
> > > > Here is my run line:
> > > > bin/python bin/llvm-lit /local/mnt/ted/8.4/llvm/lldb/lit/Suite
> > > > --param
> > > 'dotest-args=-A v66 -C
> > > /prj/dsp/qdsp6/release/internal/HEXAGON/branch-
> > > 8.4/linux64/latest/Tools/bin/hexagon-clang --executable
> > > /local/scratch/ted/8.4/build/bin/lldb -t -v -f
> > > RecursiveTypesTestCase.test_recursive_type_1_dwarf'
> > > >
> > > > I only want to run
> > > > RecursiveTyepsTestCase.test_recursive_type_1_dwarf,
> > > but it's running the whole test suite.
> > >
> > > Do you know about the lldb-dotest binary? You can still use it to
> > > invoke a single test, similar to how lit does it. You should be able
> > > to just pass your arguments to that.
> > >
> > > Here's a dotest line from the run:
> > > >
> > > > /local/mnt/ted/8.4/build/bin/python
> > > > /local/mnt/ted/8.4/llvm/lldb/test/dotest.py -q --arch=v66 -s
> > > > /local/mnt/ted/8.4/build/lldb-test-traces --build-dir
> > > > /local/mnt/ted/8.4/build/lldb-test-build.noindex -S nm -u CXXFLAGS
> > > > -u CFLAGS --executable /local/mnt/ted/8.4/build/./bin/lldb
> > > > --dsymutil /local/mnt/ted/8.4/build/./bin/dsymutil --filecheck
> > > > /local/mnt/ted/8.4/build/./bin/FileCheck -C
> > > > /local/mnt/ted/8.4/build/./bin/clang --env ARCHIVER=/usr/bin/ar
> > > > --env OBJCOPY=/usr/bin/objcopy -A v66 -C
> > > > /prj/dsp/qdsp6/release/internal/HEXAGON/branch-8.4/linux64/latest/
> > > > Tool s/bin/hexagon-clang --executable
> > > > /local/scratch/ted/8.4/build/bin/lldb
> > > > -t -v -f RecursiveTypesTestCase.test_recursive_type_1_dwarf --env
> > > > LLVM_LIBS_DIR=/local/mnt/ted/8.4/build/./lib
> > > > 

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

[Ted Woodward via lldb-dev]

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-multiprocess). I might be 
running from a directory where I've built lldb (but not clang, using clang from 
an arbitrary location), a directory where I've built everything (but in this 
case we set everything up with cmake), or a directory where I've checkout out 
just the sources and have copied the binaries from a distribution, so no cmake.

dotest used to handle these cases; how do I handle them now?

In our environment, lldb will launch and connect to the hexagon simulator, much 
like how it launches and connects to debugserver or lldb-server. But it has to 
use a specific version of clang, because we've found that if we have mismatches 
in clang/simulator/RTOS, bad things can happen. User code is in a shared 
library that gets loaded by a wrapper run under the RTOS. The RTOS, wrapper and 
user code all need to be built with the same complier and c/c++ libraries.

Ted

> -Original Message-
> From: Jonas Devlieghere 
> Sent: Friday, August 9, 2019 3:18 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: [EXT] Re: How do I use lit to only run the lldb test suite, now that
> dotest multiprocessing capabilities have been removed?
> 
> Hey Ted,
> 
> On Thu, Aug 8, 2019 at 2:08 PM Ted Woodward 
> wrote:
> >
> > 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.
> 
> It's not something I touched recently, but it's always possible they made some
> changes in LLVM.
> 
> > Here is my run line:
> > bin/python bin/llvm-lit /local/mnt/ted/8.4/llvm/lldb/lit/Suite --param
> 'dotest-args=-A v66 -C /prj/dsp/qdsp6/release/internal/HEXAGON/branch-
> 8.4/linux64/latest/Tools/bin/hexagon-clang --executable
> /local/scratch/ted/8.4/build/bin/lldb -t -v -f
> RecursiveTypesTestCase.test_recursive_type_1_dwarf'
> >
> > I only want to run RecursiveTyepsTestCase.test_recursive_type_1_dwarf,
> but it's running the whole test suite.
> 
> Do you know about the lldb-dotest binary? You can still use it to invoke a
> single test, similar to how lit does it. You should be able to just pass your
> arguments to that.
> 
> Here's a dotest line from the run:
> >
> > /local/mnt/ted/8.4/build/bin/python
> > /local/mnt/ted/8.4/llvm/lldb/test/dotest.py -q --arch=v66 -s
> > /local/mnt/ted/8.4/build/lldb-test-traces --build-dir
> > /local/mnt/ted/8.4/build/lldb-test-build.noindex -S nm -u CXXFLAGS -u
> > CFLAGS --executable /local/mnt/ted/8.4/build/./bin/lldb --dsymutil
> > /local/mnt/ted/8.4/build/./bin/dsymutil --filecheck
> > /local/mnt/ted/8.4/build/./bin/FileCheck -C
> > /local/mnt/ted/8.4/build/./bin/clang --env ARCHIVER=/usr/bin/ar --env
> > OBJCOPY=/usr/bin/objcopy -A v66 -C
> > /prj/dsp/qdsp6/release/internal/HEXAGON/branch-8.4/linux64/latest/Tool
> > s/bin/hexagon-clang --executable /local/scratch/ted/8.4/build/bin/lldb
> > -t -v -f RecursiveTypesTestCase.test_recursive_type_1_dwarf --env
> > LLVM_LIBS_DIR=/local/mnt/ted/8.4/build/./lib
> > /local/mnt/ted/8.4/llvm/lldb/packages/Python/lldbsuite/test/functional
> > ities/breakpoint/debugbreak -p TestDebugBreak.py
> >
> >
> > It's got both --arch= and -A, -C is set to my build directory clang as well 
> > as the
> clang I told it to use, --executable is set twice, and it's got -f
> RecursiveTypesTestCase.test_recursive_type_1_dwarf and -p
> TestDebugBreak.py .
> 
> Both lit and lldb-dotest are configured using the dotest arguments that we can
> configure at CMake configuration time. That would explain where the extra
> options come from. If those are not the ones you want, you can still invoke
> dotest.py directly.
> 
> >
> > These tests that do a "process launch" (which is most of them) invoke the
> hexagon simulator, but it was never launched. There was also only 1 testcase
> built in /local/mnt/ted/8.4/build/lldb-test-build.noindex -
> types/TestRecursiveTypes.test_recursive_type_1_dwarf .
> 
> Other than the extra arguments I can't think of any reason why this would
> behave differently. Lit is just a simple wrapper that invokes dotest.py with 
> the
> right arguments.
> 
> > This does not have the patch that removes multiprocess support from
> dotest.
> >
> > Ted
> >
> > > -Original Message-
> > > From: Jonas Devlieghere 
> > > Sent: Thursday, August 8, 2019 2:50 PM
> > > To: Ted Woodward 
> > > Cc: LLDB 
> > > Subject: [EXT] Re: How do I use lit to only run the lldb test suite,
> > > now that dotest multiprocessing capabilities have been removed?
> > >
> > > Hey Ted,
> > >
> > > 1. You can run just the dotest-tests by pointing lit at the `lit/Suite`
> 

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

[Ted Woodward via lldb-dev]

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/python bin/llvm-lit /local/mnt/ted/8.4/llvm/lldb/lit/Suite --param 
'dotest-args=-A v66 -C 
/prj/dsp/qdsp6/release/internal/HEXAGON/branch-8.4/linux64/latest/Tools/bin/hexagon-clang
 --executable /local/scratch/ted/8.4/build/bin/lldb -t -v -f 
RecursiveTypesTestCase.test_recursive_type_1_dwarf'

I only want to run RecursiveTyepsTestCase.test_recursive_type_1_dwarf, but it's 
running the whole test suite. Here's a dotest line from the run:

/local/mnt/ted/8.4/build/bin/python /local/mnt/ted/8.4/llvm/lldb/test/dotest.py 
-q --arch=v66 -s /local/mnt/ted/8.4/build/lldb-test-traces --build-dir 
/local/mnt/ted/8.4/build/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS 
--executable /local/mnt/ted/8.4/build/./bin/lldb --dsymutil 
/local/mnt/ted/8.4/build/./bin/dsymutil --filecheck 
/local/mnt/ted/8.4/build/./bin/FileCheck -C 
/local/mnt/ted/8.4/build/./bin/clang --env ARCHIVER=/usr/bin/ar --env 
OBJCOPY=/usr/bin/objcopy -A v66 -C 
/prj/dsp/qdsp6/release/internal/HEXAGON/branch-8.4/linux64/latest/Tools/bin/hexagon-clang
 --executable /local/scratch/ted/8.4/build/bin/lldb -t -v -f 
RecursiveTypesTestCase.test_recursive_type_1_dwarf --env 
LLVM_LIBS_DIR=/local/mnt/ted/8.4/build/./lib 
/local/mnt/ted/8.4/llvm/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak
 -p TestDebugBreak.py


It's got both --arch= and -A, -C is set to my build directory clang as well as 
the clang I told it to use, --executable is set twice, and it's got -f 
RecursiveTypesTestCase.test_recursive_type_1_dwarf and -p TestDebugBreak.py .

These tests that do a "process launch" (which is most of them) invoke the 
hexagon simulator, but it was never launched. There was also only 1 testcase 
built in /local/mnt/ted/8.4/build/lldb-test-build.noindex - 
types/TestRecursiveTypes.test_recursive_type_1_dwarf .

This does not have the patch that removes multiprocess support from dotest.

Ted

> -Original Message-
> From: Jonas Devlieghere 
> Sent: Thursday, August 8, 2019 2:50 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: [EXT] Re: How do I use lit to only run the lldb test suite, now that
> dotest multiprocessing capabilities have been removed?
> 
> Hey Ted,
> 
> 1. You can run just the dotest-tests by pointing lit at the `lit/Suite` 
> directory.
> 2. You can pass arguments to dotest by passing `dotest-args` in --param.
> 
> The invocation would look something like this:
> 
> /path/to/llvm/bin/llvm-lit /path/to/lldb/lit/Suite --param 'dotest-args=--foo 
> --
> bar'
> 
> Hope that helps,
> Jonas
> 
> On Thu, Aug 8, 2019 at 9:31 AM Ted Woodward 
> wrote:
> >
> > 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 flavor (static testcase + os, dynamic library 
> testcase
> loaded by an OS image, dynamic library testcase loaded by an OS image
> running the OS’ debug stub).
> >
> >
> >
> > With the multiprocess testrunner removed, how do I have lit:
> >
> > Only run the lldb test suite
> > Run dotest with specific arguments
> >
> >
> >
> > We’re not running cmake; we’re taking an existing tools build and running
> the tests from the source directory using the toolset.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 flavor (static testcase + os, dynamic library 
testcase loaded by an OS image, dynamic library testcase loaded by an OS image 
running the OS' debug stub).

With the multiprocess testrunner removed, how do I have lit:

  1.  Only run the lldb test suite
  2.  Run dotest with specific arguments

We're not running cmake; we're taking an existing tools build and running the 
tests from the source directory using the toolset.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 
; clangd-...@lists.llvm.org; openmp-dev 
(openmp-...@lists.llvm.org) ; LLDB Dev 
; cfe-dev ; 
libcxx-...@lists.llvm.org
Subject: [EXT] Re: [lldb-dev] [Release-testers] [9.0.0 Release] The release 
branch is open; trunk is now 10.0.0

Uploaded ubuntu 14.

I had to kill some tests executing "lldb-vscode", they had been running for 12+ 
hours without completing.

b57383860c7e4317b0194d1a91836e01bd637c95  
clang+llvm-8.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz

On Thu, Jul 18, 2019 at 7:19 AM Hans Wennborg via Release-testers 
mailto:release-test...@lists.llvm.org>> wrote:
Hello everyone,

The release branch for LLVM 9 and its sub-projects was just created
from trunk at r366426, and the trunk version was subsequently bumped
to 10.0.0.

Release blockers are tracked by https://llvm.org/PR42474 Please mark
any bugs, old or new, that need to be fixed before the release as
blocking that.

To get a change committed to the branch, first commit it to trunk as
usual, and then request it to be merged --- ideally by filing a
blocker bug on https://llvm.org/PR42474, or by cc'ing me on the commit
email. (Please don't request merges over IRC; there's a high risk I'll
miss them.)

Please help with the release by notifying me about any bugs, commits,
or other issues you think might be relevant. If it's not already
tracked as a blocker of the release bug, or I'm not cc'd on an email
about it, I will probably miss it.

When the branch is in good enough shape, hopefully by tomorrow, the
first release candidate (RC1) will be tagged and testing can begin.
The release schedule can be found under "Upcoming Releases" to the
right at https://llvm.org

Many thanks,
Hans
___
Release-testers mailing list
release-test...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers


--
-Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 plan 
on moving them?
  *   If we don’t move them, do we just rely on the lldb-mi executable not 
existing to keep from trying to run them?
  *   If we do move them, how do we run them?

Ted

From: lldb-dev  On Behalf Of Jonas Devlieghere 
via lldb-dev
Sent: Friday, July 5, 2019 11:44 AM
To: Raphael “Teemperor” Isemann 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] [RFC] Removing lldb-mi

Thank you for doing this, Raphael. I believe this shows that it's possible to 
keep lldb-mi alive, without today's maintenance burden on the LLDB community, a 
solution that seems to appease everyones concerns in this thread. I hope this 
sparks interest for somebody to step up as a maintainer.

I went ahead and created a diff to add the proposed deprecations to the LLVM 
release notes: https://reviews.llvm.org/D64254
I'll put up another diff to remove the code, which we can land once LLVM 9 has 
branched.

Thank you,
Jonas

On Thu, Jul 4, 2019 at 12:24 PM Raphael “Teemperor” Isemann via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
I just went forward with this and made a quick test repo with an out-of-tree 
lldb-mi that compiles against the system LLDB: 
https://github.com/Teemperor/lldb-mi This seems to work fine with the exception 
of the python tests which require LLDB’s python code for testing which isn’t 
installed alongside LLDB. I guess we will have to see if we copy the related 
test code there or we just rewrite the test suite (which is anyway broken). On 
the upside, we can now just use Travis for CI as we don’t have to compile 
LLVM/Clang/LLDB, so that’s nice.

I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give downstream 
time until 10.0.0 (or X.0.0 :) ) to package out-of-tree lldb-mi for users. 
Given how simple lldb-mi is, this seems like a reasonable timeframe.

- Raphael


On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:



On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

We're using it with Eclipse and Eclipse based product, so I'd like to keep as 
well! :-)...

Zdenek

I do understand that there's desire from people to keep this around (from an 
user perspective), but I guess this fundamentally misses Jonas' original mail 
point.
lldb-mi has been unmaintained for a long time (at least the past two years from 
what I can tell), and we tried to use it in emacs without success.
It has never been a priority for many of the parties putting effort in lldb and 
I'm under the impression the situation won't change in the foreseeable future.
Unless somebody steps up as maintainer I don't think there's a lot of future 
for the tool.
Maybe a good compromise would be that of having lldb-mi living in a separate 
repo somewhere on GitHub, as it only uses the SBAPI, which is public and set in 
stone?

--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 with all of the 
relevant headers and libraries (MUSL for the C library), told cmake that we 
were targeting Hexagon, and let it fly.

Later on we set up a buildbot that built BusyBox, and had it build our native 
llvm tools as well. We can ssh into a board running Hexagon Linux, and run 
clang/lldb natively. It looks just like x86 Linux.

Ted
From: lldb-dev  On Behalf Of Romaric Jodin via 
lldb-dev
Sent: Monday, July 15, 2019 5:00 AM
To: Greg Clayton 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] Adding a new architecture into LLDB

Indeed, that's exactly what I've done. I've got a "lldb-server-dpu", and the 
only modification I made to have it working as expected is to have a second 
"liblldbHost.a" ("liblldbHostDpu.a"), with a single modification in 
"HostInfoBase::ComputeHostArchitectureSupport" 
(https://github.com/upmem/lldb/commit/d35bbb8376096fd3ab3047b1c5ec507c96731deb#diff-7a05d638d592248e1fbb10192911affbR298)
Seems to work well for the moment.

Romaric

On Fri, Jul 12, 2019 at 11:11 PM Greg Clayton 
mailto:clayb...@gmail.com>> wrote:



On Jun 18, 2019, at 7:08 AM, Romaric Jodin via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

Hello everyone,

I am trying to add a new architecture into LLDB.
My architecture is a accelerator with its own ISA for which we have a LLVM 
backend (release 7.1).

I have started by creating a new NativeProcessProtocol for my architecture. So 
I have a lldb-server that run on a x86, but which takes care of process of my 
architecture. I have forced it to use my NativeProcessProtocol.
I have a issue with this method because as the lldb-server is compile to run on 
a x86, some part of the code think that it is managing x86 process.

Maybe I am going in the wrong direction to add such new architecture to LLDB, I 
would be happy to try any other suggestions.

lldb-server is currently meant to build a native debugging GDB server that can 
be used with lldb. If you want to always build a cross build lldb-server for 
your architecture, you will want to add a new tool that gets built in the 
CMakeList.txt in the tools/lldb-server directory. You will need to build it 
into a different binary like "lldb-server-dpu". I am not sure how much trouble 
you will run into doing this though as much of the lldb-server build assumes 
things match the current host.


If you are interested, you can have a look at my branch "dev/rjodin/lldb_dpu" 
in our forked repo of LLDB "https://github.com/upmem/lldb;. The branch is not 
clean, but it can help you understand what I did.

Thanks,
--
Romaric JODIN
UPMEM
Software Engineer


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png@01D53B0A.FB29CCB0]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 want to propose removing lldb-mi from the 
repository. It is basically unmaintained, doesn't match the LLDB code style, 
and worst of all the tests are unreliable if not already disabled. As far as I 
can tell it's missing core functionality to be usable from something like say 
emacs.

Thanks,
Jonas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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: via lldb-dev 
Cc: Vangelis Tsiatsianas 
Subject: [EXT] [lldb-dev] Enabling single-step mode and acting on each executed 
instruction

Hello,

I would like to set the target in single-step mode and perform an action right 
after each instruction is executed. Notably, it is crucial to do so 
transparently, i.e. without interfering with user breakpoints, watchpoints, 
stepping etc..

Could you provide me with some guidance on how to accomplish it? 

I have found the target.process.thread.trace-thread option and the relevant 
classes (ThreadPlanTracer and ThreadPlanAssemblyTracer), which although seem to 
not work and also crash the debugger when enabled.

Thank you very much, in advance.


― Vangelis

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

The bug that makes swig before 4 fail with Python 3.7 may turn into a big 
issue, given that swig is now licensed under GPL v3. I believe Apple has said 
in the past that they can’t move past a certain version of swig 2.x, since the 
license changed from GPL v2 to GPL v3.

From: Adrian McCarthy 
Sent: Monday, June 24, 2019 6:43 PM
To: Ted Woodward 
Cc: Alexandre Ganea ; LLDB 

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

I can confirm that there are problems building with Swig 4.

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

Python 3.6 with Swig 3.0.12 is working well 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 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 tests.

I haven’t built with swig 4, just swig 3. I’ll let someone else answer if swig 
4 works!

From: lldb-dev 
mailto:lldb-dev-boun...@lists.llvm.org>> On 
Behalf Of Alexandre Ganea via lldb-dev
Sent: Friday, May 31, 2019 10:42 AM
To: lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
Subject: [EXT] [lldb-dev] Trouble running Python tests on Windows

Hi,

I can’t seem to run the lldb python tests on my Windows 10 setup. I use the 
following cmd-line to generate:

cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release 
-DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld 
-DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang -DLLVM_TOOL_LLD_BUILD=true 
-DLLVM_TOOL_CLANG_BUILD=true -DLLVM_ENABLE_PDB=true -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_EXTERNAL_LLDB_SOURCE_DIR=f:/svn/lldb -DLLVM_TOOL_LLDB_BUILD=true 
-DPYTHON_HOME="C:\Users\aganea\AppData\Local\Programs\Python\Python37"

Followed by: ninja check-all, which ends up in a bunch of:

 TEST 'lldb-Suite :: 
tools/lldb-server/TestAppleSimulatorOSType.py' FAILED 
Unable to find 'RESULT: PASSED' in dotest output:

lldb version 9.0.0 (https://aga...@llvm.org/svn/llvm-project/lldb/trunk 
revision 361826)
  clang revision 361826
  llvm revision 361826
LLDB library dir: F:\svn\buildninja\bin
LLDB import library dir: F:\svn\buildninja\bin\..\lib
Traceback (most recent call last):
  File "F:/svn/lldb/test/dotest.py", line 7, in 
lldbsuite.test.run_suite()
  File "F:\svn\lldb\packages\Python\lldbsuite\test\dotest.py", line 1243, in 
run_suite
import lldb
  File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1500, in 

class SBAddress(object):
  File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1675, in 
SBAddress
__swig_getmethods__["module"] = GetModule
NameError: name '__swig_getmethods__' is not defined

Swig 4.0.0 is there in %PATH%. I’m using MSVC 19.16.27031.1 for compiling. I’ve 
tried with Clang 8.0, same issues.
Any idea on what could be missing?

Thanks in advance!
Alex.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Disassembling issue

[Ted Woodward via lldb-dev]

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 triple is set correctly after you do the run. 
What is the output from these commands, when you’re stopped?:

target list
platform status

My guess is you’re connected to a remote gdb-server on a simulator for dpu, and 
it’s telling lldb that the triple is x86_64.x.x.

If target list says the arch is dpu before the run, and x86_64 after the run, 
we should look at the RSP log. Before the run, type
log enable -f  gdb-remote packets

Attach the file to your next message.

Ted

From: Romaric Jodin 
Sent: Thursday, June 13, 2019 1:16 AM
To: Ted Woodward 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] Disassembling issue

Hi Ted,

Thank you for the answer.
I'm not sure I understand you well. It seems to me that my program call 
"Disassembler::FindPlugin" with the "m_options.arch" set to "x86_64". But my 
toolchain does not contain a LLVM supporting x86_64, so it feels normal to me 
that it is not able to create this disassembler. What is weird is that the 
first time I'm executing it, it managed to do so.

I also have kind of the same issue with breakpoint. It's like if I'm missing 
the debug information after I do the "run" command:

(lldb) file test
Current executable set to 'test' (dpu).
(lldb) b main
Breakpoint 1: where = test`main + 24 at test.c:8, address = 0x8078
(lldb) r
Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu)
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = Thread finished
frame #0: 0x80c0
(lldb) b main
Breakpoint 2: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.

When I'm doing the disassembly, I can manage to disassemble if I add the option 
with my architecture to the command line, but as you can see below, I also do 
not have the debug information that I had at the first disassembly:

(lldb) file test
Current executable set to 'test' (dpu).
(lldb) dis -s 0x8000
test`__bootstrap:
test[0x8000] <+0>:  jnzid, 0x8020
test[0x8008] <+8>:  move   r0, 0xff
test[0x8010] <+16>: release r0, 0x0, nz, 0x8018
test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
(lldb) r
Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu)
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = Thread finished
frame #0: 0x80a0
(lldb) dis -s 0x8000
error: Unable to find Disassembler plug-in for the 'x86_64' architecture.
(lldb) dis -s 0x8000 -A dpu
0x8000: jnzid, 0x8020
0x8008: move   r0, 0xff
0x8010: release r0, 0x0, nz, 0x8018
0x8018: subr0, r0, 0x1, pl, 0x8010

Any ideas about it?
Thanks,
Romaric

On Wed, Jun 12, 2019 at 6:55 PM Ted Woodward 
mailto:tedw...@quicinc.com>> wrote:
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.cpp is failing. Step through 
that and make sure everything there is working.

Ted

From: lldb-dev 
mailto:lldb-dev-boun...@lists.llvm.org>> On 
Behalf Of Romaric Jodin via lldb-dev
Sent: Wednesday, June 12, 2019 8:23 AM
To: lldb-dev@lists.llvm.org
Subject: [EXT] [lldb-dev] Disassembling issue

Hi everyone,

I'm trying to have lldb being able to debug my architecture. It does it well 
after loading my elf. But then I run it, stop it in middle, try to disassemble 
and at that point it seems that I lost some information about my architecture. 
lldb tries to disassemble it for x86, which in not possible with my toolchain.

Here is a log of what I am doing:

(lldb) file test
Current executable set to 'test' (dpu).
(lldb) dis -s 0x8000
test`__bootstrap:
test[0x8000] <+0>:  jnzid, 0x8020
test[0x8008] <+8>:  move   r0, 0xff
test[0x8010] <+16>: release r0, 0x0, nz, 0x8018
test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
(lldb) r
Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu)
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = Thread stopped
frame #0: 0x8090
(lldb) dis -s 0x8000
error: Unable to find Disassembler plug-in for the 'x86_64' architecture.
(lldb)

Any ideas of what I am missing in my implementation?
Thanks,
--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png@01D521DB.DDFD0A00]


--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png@01D521DB.DDFD0A00]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org

Re: [lldb-dev] Disassembling issue

[Ted Woodward via lldb-dev]

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.cpp is failing. Step through 
that and make sure everything there is working.

Ted

From: lldb-dev  On Behalf Of Romaric Jodin via 
lldb-dev
Sent: Wednesday, June 12, 2019 8:23 AM
To: lldb-dev@lists.llvm.org
Subject: [EXT] [lldb-dev] Disassembling issue

Hi everyone,

I'm trying to have lldb being able to debug my architecture. It does it well 
after loading my elf. But then I run it, stop it in middle, try to disassemble 
and at that point it seems that I lost some information about my architecture. 
lldb tries to disassemble it for x86, which in not possible with my toolchain.

Here is a log of what I am doing:

(lldb) file test
Current executable set to 'test' (dpu).
(lldb) dis -s 0x8000
test`__bootstrap:
test[0x8000] <+0>:  jnzid, 0x8020
test[0x8008] <+8>:  move   r0, 0xff
test[0x8010] <+16>: release r0, 0x0, nz, 0x8018
test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
(lldb) r
Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu)
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = Thread stopped
frame #0: 0x8090
(lldb) dis -s 0x8000
error: Unable to find Disassembler plug-in for the 'x86_64' architecture.
(lldb)

Any ideas of what I am missing in my implementation?
Thanks,
--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png@01D52114.183385F0]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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

I haven't built with swig 4, just swig 3. I'll let someone else answer if swig 
4 works!

From: lldb-dev  On Behalf Of Alexandre Ganea 
via lldb-dev
Sent: Friday, May 31, 2019 10:42 AM
To: lldb-dev@lists.llvm.org
Subject: [EXT] [lldb-dev] Trouble running Python tests on Windows

Hi,

I can't seem to run the lldb python tests on my Windows 10 setup. I use the 
following cmd-line to generate:

cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release 
-DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld 
-DLLVM_EXTERNAL_CLANG_SOURCE_DIR=f:/svn/clang -DLLVM_TOOL_LLD_BUILD=true 
-DLLVM_TOOL_CLANG_BUILD=true -DLLVM_ENABLE_PDB=true -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_EXTERNAL_LLDB_SOURCE_DIR=f:/svn/lldb -DLLVM_TOOL_LLDB_BUILD=true 
-DPYTHON_HOME="C:\Users\aganea\AppData\Local\Programs\Python\Python37"

Followed by: ninja check-all, which ends up in a bunch of:

 TEST 'lldb-Suite :: 
tools/lldb-server/TestAppleSimulatorOSType.py' FAILED 
Unable to find 'RESULT: PASSED' in dotest output:

lldb version 9.0.0 (https://aga...@llvm.org/svn/llvm-project/lldb/trunk 
revision 361826)
  clang revision 361826
  llvm revision 361826
LLDB library dir: F:\svn\buildninja\bin
LLDB import library dir: F:\svn\buildninja\bin\..\lib
Traceback (most recent call last):
  File "F:/svn/lldb/test/dotest.py", line 7, in 
lldbsuite.test.run_suite()
  File "F:\svn\lldb\packages\Python\lldbsuite\test\dotest.py", line 1243, in 
run_suite
import lldb
  File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1500, in 

class SBAddress(object):
  File "F:\svn\buildninja\lib\site-packages\lldb\__init__.py", line 1675, in 
SBAddress
__swig_getmethods__["module"] = GetModule
NameError: name '__swig_getmethods__' is not defined

Swig 4.0.0 is there in %PATH%. I'm using MSVC 19.16.27031.1 for compiling. I've 
tried with Clang 8.0, same issues.
Any idea on what could be missing?

Thanks in advance!
Alex.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 = 'queue2'
  thread #3: tid = 0x0003, 0x, name = 'three', queue = 'queue3', stop 
reason = signal SIGINT

When I run the test by itself, it fails with this thread list:
runCmd: thread list
output: Process 1 stopped
* thread #2: tid = 0x1, 0x, name = 'one', queue = 'queue1'
  thread #3: tid = 0x2, 0x, name = 'two', queue = 'queue2'
  thread #4: tid = 0x3, 0x, name = 'three', queue = 'queue3', 
stop reason = signal SIGINT

Anyone have any idea why this is?

packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestThreadSelectionBug.py
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Website

[Ted Woodward via lldb-dev]

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_DIR}/doc")
file(MAKE_DIRECTORY "${DOC_DIR}")
#set(ENV{PYTHONPATH} 
${CMAKE_CURRENT_BINARY_DIR}/../../../lib/python2.7/site-packages)
add_custom_target(lldb-python-doc
  ${EPYDOC_EXECUTABLE}
  --html
  lldb
  -o ${CMAKE_CURRENT_BINARY_DIR}/python_reference
  --name "LLDB python API"
  --url "http://lldb.llvm.org;
  ${EPYDOC_OPTIONS}
  DEPENDS swig_wrapper liblldb
  WORKING_DIRECTORY 
${CMAKE_CURRENT_BINARY_DIR}/../../../lib${LLVM_LIBDIR_SUFFIX}/python2.7/site-packages
  COMMENT "Generating LLDB Python API reference with epydoc" VERBATIM
)
endif(EPYDOC_EXECUTABLE)


> -Original Message-
> From: lldb-dev  On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Wednesday, April 24, 2019 1:16 AM
> To: Jonas Devlieghere ; Tanya Lattner
> 
> Cc: LLDB 
> Subject: [EXT] Re: [lldb-dev] LLDB Website
> 
> On 24/04/2019 03:19, Jonas Devlieghere via lldb-dev wrote:
> >
> >
> > On Tue, Apr 23, 2019 at 6:04 PM Jonas Devlieghere
> > mailto:jo...@devlieghere.com>> wrote:
> >
> >
> >
> > On Tue, Apr 23, 2019 at 5:43 PM Tanya Lattner  > > wrote:
> >
> >
> >
> >> On Apr 23, 2019, at 5:06 PM, Jonas Devlieghere
> >> mailto:jo...@devlieghere.com>> wrote:
> >>
> >>
> >>
> >> On Tue, Apr 23, 2019 at 5:00 PM Tanya Lattner
> >> mailto:tanyalatt...@llvm.org>> wrote:
> >>
> >>
> >>
> >>> On Apr 23, 2019, at 11:54 AM, Jonas Devlieghere
> >>> mailto:jo...@devlieghere.com>>
> wrote:
> >>>
> >>> Hey Tanya,
> >>>
> >>> On Tue, Apr 23, 2019 at 11:51 Tanya Lattner
> >>> mailto:tanyalatt...@llvm.org>> wrote:
> >>>
> >>> Jonas,
> >>>
> >>> Ignore what I said before as these do need to be
> >>> separate targets. It appears the new targets are
> >>> running doxygen. This isn’t something we typically do
> >>> as a post commit hook since it takes awhile. I’ll
> >>> need to do this via the doxygen nightly script. Any
> >>> concerns?
> >>>
> >>> That sounds perfect. Can we still do the regular website
> >>> post commit?
> >>
> >> Yes, so it will do docs-lldb-html on every commit.
> >>
> >>
> >> Perfect!
> >>
> >>
> >> So I am able to generate the cpp reference docs:
> >> https://lldb.llvm.org/cpp_reference/index.html
> >>
> >> However, the main website links to
> >> https://lldb.llvm.org/cpp_reference/html/index.html. Do
> >> you want the html in that url? I can change the alias. We
> >> strip for other doxygen.
> >>
> >>
> >> Let's keep it without the html. I'll update a link on the
> >> website and add a redirect.
> >>
> >>
> >> As for python docs, what is required to build those? It's
> >> not showing up as a target for me.
> >>
> >>
> >> This is probably because you don't have `epydoc` installed
> >> (sudo pip install epydoc).
> >> I think you'll have to re-run cmake after for it to pick it
> >> up. The corresponding target should then be `lldb-python-doc`.
> >>
> >> https://lldb.llvm.org/cpp_reference/index.html
> >
> > Well installing epydoc did the trick, but I don’t think the
> > doxygen script is the right place for this target. I have not
> > dug into it yet but it appears to require some LLVM libraries
> > and is building those. I’m letting it finish to verify it builds
> > but I’ll have to sort out the best way of doing this on the
> > server. We have other scripts that generate other documentation
> > that build parts of LLVM. Ideally, I would want to leverage that
> > and reduce build times.
> >
> >
> > Yeah, the annoying thing about the Python documentation is that it
> > builds the C++ API, then runs swig to generate the Python wrapper,
> > and finally generates the docs from that.
> 
> It should be possible to solve this by tweaking the dependency graph a bit.
> There's no fundamental reason why you need to build anything in order to
> run swig. It is purely a textual step -- it ingests header files and interface
> definitions and spits out python and cpp files. The inputs are present as 
> static
> checked in source, so the swig step could theoretically be the very first 
> build
> command that we run.
> 
> > I wonder if we can just use the static bindings that are checked-in
> > instead. I will look into that later today/tomorrow.
> >
> >
> > Right, so the reason is 

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

[Ted Woodward via lldb-dev]

Great, thanks Jim. Glad to see people are already on this.

But where do I go if I need to look at the python API right now?
(besides web.archive.org, which is what I ended up doing)

> -Original Message-
> From: jing...@apple.com 
> Sent: Monday, April 22, 2019 1:35 PM
> To: 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.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 Found”:
> > The requested URL /python_reference/index.html was not found on this
> server.
> > The requested URL /cpp_reference/html/index.html was not found on this
> server.
> >
> > Where do I go to find the python/c++ API documentation now?
> >
> > BTW, I don’t think LLDB’s API documentation is an “External Resource”.
> Those links should be on the main page, along with a link to the llvm main
> page.
> 
> Both of these are known issues.  Jonas is going to move the API docs to the 
> top
> level.  IIUC this also needs some website admin intervention, which Jonas is
> waiting on.
> 
> Jim
> 
> 
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 Found":
The requested URL /python_reference/index.html was not found on this server.
The requested URL /cpp_reference/html/index.html was not found on this server.

Where do I go to find the python/c++ API documentation now?

BTW, I don't think LLDB's API documentation is an "External Resource". Those 
links should be on the main page, along with a link to the llvm main page.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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.


We build lldb with tsan turned on, and see a lock-order-inversion error with 
just a run/quit. Could this be the cause of our crash?


Build was done with ToT on Ubuntu 14.04, using clang 7.0.1 with this cmake line:
CC=clang CXX=clang++ cmake -G Ninja -DLLVM_USE_SANITIZER=Thread 
-DLLVM_ENABLE_LIBCXX=On ../llvm/

Output from the run:

> TSAN_OPTIONS=second_deadlock_stack=1 bin/lldb
(lldb) quit
==
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=11107)
  Cycle in lock order graph: M1739 (0x7b1c00b0) => M1745 (0x7b3c0040) 
=> M1739

  Mutex M1745 acquired here while holding mutex M1739 in thread T1:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Debugger::DefaultEventHandler() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1537:16 
(liblldb.so.9svn+0xd5f783)
#3 lldb_private::Debugger::EventHandlerThread(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1609:22 
(liblldb.so.9svn+0xd5fba9)
#4 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:69:10
 (liblldb.so.9svn+0xe438f2)

  Mutex M1739 previously acquired by the same thread here:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Debugger::DefaultEventHandler() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1537:16 
(liblldb.so.9svn+0xd5f783)
#3 lldb_private::Debugger::EventHandlerThread(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:1609:22 
(liblldb.so.9svn+0xd5fba9)
#4 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Host/common/HostNativeThreadBase.cpp:69:10
 (liblldb.so.9svn+0xe438f2)

  Mutex M1739 acquired here while holding mutex M1745 in main thread:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 (lldb+0x4441ae)
#1 std::__1::recursive_mutex::lock()  (libc++.so.1+0x52ea5)
#2 lldb_private::Listener::Clear() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Utility/Listener.cpp:78:19 
(liblldb.so.9svn+0x1005e58)
#3 lldb_private::Debugger::Clear()::$_0::operator()() const 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:841:20 
(liblldb.so.9svn+0xd60237)
#4 decltype(std::__1::forward(fp)()) 
std::__1::__invoke(lldb_private::Debugger::Clear()::$_0&&)
 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/type_traits:4345:1
 (liblldb.so.9svn+0xd601cc)
#5 void 
std::__1::__call_once_param
 >::__execute<>(std::__1::__tuple_indices<>) 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:621
 (liblldb.so.9svn+0xd601cc)
#6 
std::__1::__call_once_param
 >::operator()() 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:613
 (liblldb.so.9svn+0xd601cc)
#7 void 
std::__1::__call_once_proxy
 >(void*) 
/opt/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-14.04/bin/../include/c++/v1/mutex:649
 (liblldb.so.9svn+0xd601cc)
#8 std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) 
 (libc++.so.1+0x53317)
#9 lldb_private::Debugger::Clear() 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:837:3 
(liblldb.so.9svn+0xd5b358)
#10 
lldb_private::Debugger::Destroy(std::__1::shared_ptr&) 
/local/mnt/ted/tip/llvm/tools/lldb/source/Core/Debugger.cpp:699:16 
(liblldb.so.9svn+0xd5b9e6)
#11 lldb::SBDebugger::Destroy(lldb::SBDebugger&) 
/local/mnt/ted/tip/llvm/tools/lldb/source/API/SBDebugger.cpp:276:3 
(liblldb.so.9svn+0x9ddef5)
#12 Driver::MainLoop() 
/local/mnt/ted/tip/llvm/tools/lldb/tools/driver/Driver.cpp:764:3 (lldb+0x4b518f)
#13 main /local/mnt/ted/tip/llvm/tools/lldb/tools/driver/Driver.cpp:957:26 
(lldb+0x4b5aa6)

  Mutex M1745 previously acquired by the same thread here:
#0 pthread_mutex_lock 
/local/mnt/workspace/bcain_clang_bcain-ubuntu_14427/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:4071:3
 

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

[Ted Woodward via lldb-dev]

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/Contributing.html

Ted

> -Original Message-
> From: lldb-dev  On Behalf Of Nat! via lldb-
> dev
> Sent: Wednesday, March 6, 2019 8:47 AM
> To: lldb-dev@lists.llvm.org
> Subject: [EXT] [lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded
> 
> I couldn't figure out how to post a patch to reviews.llvm.org, so here it is 
> per
> email, with the hope that someone adopts it :)
> 
> Basically it's just moving the `bool print_oneline` out of the execution 
> path, if
> no children are
> 
> printed, since this value is then never used. This may not seem like a big 
> deal,
> but solves a big
> 
> problem in my debugger :)
> 
> 
> 
> ```
> 
> void ValueObjectPrinter::PrintChildrenIfNeeded(bool value_printed,
>     bool summary_printed) {
>    // this flag controls whether we tried to display a description for this
>    // object and failed if that happens, we want to display the children, if 
> any
>    bool is_failed_description =
>    !PrintObjectDescriptionIfNeeded(value_printed, summary_printed);
> 
>    auto curr_ptr_depth = m_ptr_depth;
>    bool print_children =
>    ShouldPrintChildren(is_failed_description, curr_ptr_depth);
> 
>    //
>    // DataVisualization::ShouldPrintAsOneLiner is often called for
>    // print_oneline (see below) and it is very expensive, so use an
>    // early exit, if we are not printing children (also easier to read)
>    //
>    if (!print_children) {
>      if (m_curr_depth >= m_options.m_max_depth && IsAggregate() &&
>     ShouldPrintValueObject()) {
>    m_stream->PutCString("{...}\n");
>      } else
>    m_stream->EOL();
>      return;
>    }
> 
>    //
>    // TODO: maybe move the bool print_oneline line to #1#, but its unclear to
>    // me if DataVisualization::ShouldPrintAsOneLiner can modify *m_valobj or
> not
>    //
>    bool print_oneline =
>    (curr_ptr_depth.CanAllowExpansion() || m_options.m_show_types ||
>     !m_options.m_allow_oneliner_mode || m_options.m_flat_output ||
>     (m_options.m_pointer_as_array) || m_options.m_show_location)
>    ? false
>    : DataVisualization::ShouldPrintAsOneLiner(*m_valobj);
> 
>    bool is_instance_ptr = IsInstancePointer();
>    uint64_t instance_ptr_value = LLDB_INVALID_ADDRESS;
> 
>    if (is_instance_ptr) {
>      instance_ptr_value = m_valobj->GetValueAsUnsigned(0);
>      if (m_printed_instance_pointers->count(instance_ptr_value)) {
>    // we already printed this instance-is-pointer thing, so don't expand 
> it
>    m_stream->PutCString(" {...}\n");
> 
>    // we're done here - get out fast
>    return;
>      } else
>    m_printed_instance_pointers->emplace(
>    instance_ptr_value); // remember this guy for future reference
>    }
> 
>    // #1#
>    if (print_oneline) {
>      m_stream->PutChar(' ');
>      PrintChildrenOneLiner(false);
>      m_stream->EOL();
>    } else
>      PrintChildren(value_printed, summary_printed, curr_ptr_depth); }
> 
> ```
> 
> 
> Ciao
> 
>     Nat!
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 will match against 
“hexagon-unknown--elf”, so I need to make sure the Hexagon platform is in the 
plugin list before the Linux platform.

Ted

From: lldb-dev  On Behalf Of Greg Clayton via 
lldb-dev
Sent: Wednesday, February 27, 2019 4:15 PM
To: Zachary Turner 
Cc: ted.woodw...@codeaurora.org; LLDB 
Subject: [EXT] Re: [lldb-dev] When should ArchSpecs match?




On Dec 7, 2018, at 8:10 AM, Zachary Turner via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

“Unknown” is a perfectly fine value for the os though, and I’m not suggesting 
to change that.

My point is simply that Jason’s situation (baremetal) is one that is not even 
expressible by the Triple syntax. As long as there’s some enum value that 
describes the situation (of which unknown is a valid choice), the problem goes 
away.

We current use a "specified unknown" (where enum and string are unknown) to 
mean "none", which is what we use to say specify bare metal (no OS). I am happy 
to change that though. If we change this, then a few people's workflows might 
have to change where they used to say "armv7-apple-unknown" to 
"armv7-apple-none". Not a big deal since not many people are using LLDB for 
bare board debugging right now, but something we will need to document.

Greg



On Fri, Dec 7, 2018 at 8:06 AM 
mailto:ted.woodw...@codeaurora.org>> wrote:
We use 2 triples for Hexagon:
hexagon-unknown-elf (which becomes hexagon-unknown-unknown-elf internally), and 
hexagon-unknown-linux.

We follow the Linux standard and add in magic to the elf to identify it as a 
Linux binary. But in the hexagon-unknown-elf case we have no way to distinguish 
between standalone (no OS, running on our simulator) or QuRT (proprietary OS, 
could be running on hardware or simulator). In fact, the same shared library 
that has no OS calls (just standard library calls that go into the appropriate 
.so) could run under either one.

I think requiring a value for every OS would be a non-starter for us.

--
Ted Woodward
Qualcomm Innovation Center, Inc.
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 lldb-dev
Sent: Friday, December 7, 2018 4:38 AM
To: Pavel Labath mailto:pa...@labath.sk>>
Cc: LLDB mailto:lldb-dev@lists.llvm.org>>
Subject: Re: [lldb-dev] When should ArchSpecs match?

We can already say that with OSType::Unknown. That’s different than “i know 
that no OS exists”
On Fri, Dec 7, 2018 at 12:00 AM Pavel Labath 
mailto:pa...@labath.sk>> wrote:
On 07/12/2018 01:22, Jason Molenda via lldb-dev wrote:
> Oh sorry I missed that.  Yes, I think a value added to the OSType for NoOS or 
> something would work.  We need to standardize on a textual representation for 
> this in a triple string as well, like 'none'.  Then with arm64-- and 
> arm64-*-* as UnknownVendor + UnknownOS we can have these marked as 
> "compatible" with any other value in the case Adrian is looking at.
>
>

Sounds good to me.

As another data point, it is usually impossible to tell from looking at
an ELF file which os it is intended to run on. You can tell the
architecture because it's right in the elf header, but that's about it.
Some OSs get around this by adding a special section like
.this.is.an.android.binary, but not all of them. So in general, we need
to be able to say "I have no idea which OS is this binary intended for".

pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

> -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 there are tests that effectively require
> > interactivity. Some of the lldb-mi ones are an example.
> > A common use-case is that of sending SIGTERM in a loop to make sure
> > `lldb-mi` doesn't crash and handle the signal correctly.
> >
> > This functionality is really hard to replicate in lit_as is_.
> > Any ideas on how we could handle this case?
> 
> How hard is it to import a new version of pexpect which supports python3 and
> stuff?
> 
> I'm not sure how the situation is on darwin, but I'd expect (:P) that most 
> linux
> systems either already have it installed, or have an easy way to do so. So we
> may not even be able to get away with just using the system one and skipping
> tests when it's not present.
> 
> BTW, for lldb-mi I would actually argue that it should *not* use pexpect :D.
> Interactivity is one thing, and I'm very much in favour of keeping that 
> ability,
> but pexpect is not a prerequisite for that. For me, the main advantage of
> pexpect is that it emulates a real terminal. However, lldb-mi does not need
> that stuff. It doesn't have any command line editing capabilities or similar. 
> It's
> expecting to communicate with an IDE over a pipe, and that's it.
> 
> Given that, it should be fairly easy to rewrite the lldb-mi tests to work on 
> top
> of the standard python "subprocess" library. While we're doing that, we might
> actually fix some of the issues that have been bugging everyone in the lldb-mi
> tests. At least for me, the most annoying thing was that when lldb-mi fails to
> produce the expected output, the test does not fail immediately, but instead
> the implementation of self.expect("^whatever") waits until the timeout
> expires, optimistically hoping that it will find some output that match the
> pattern.
> 
> If we change this to something like self.expect_reply("^whatever"), and make
> the "expect_reply" function smart enough to know that lldb-mi's response
> should come as a single line, and if the first line doesn't match, it should 
> abort,
> this problem would be fixed. While we're at it, we could also tune the failure
> message so that it's more helpful than the current implementation. Plus, that
> would solve the issue of not being able to run lldb-mi tests on windows.

This would be OK, I think, as long as "expect_reply" has the option to do a 
partial match,
or a regex match. Some of the lldb-mi tests only look for certain parts of the 
reply.

Also, until Python2 is declared dead and not supported at all by lldb, we 
should be able
to run this under 2 or 3.

> Anyway, that's what I'd do. I was actually planning to look into that soon, 
> but
> then I roped myself into writing a yaml (de)serialization tool for minidumps, 
> so
> I have no idea when I will get back to that. I hope some of this is helpful
> nonetheless.
> 
> cheers,
> pavel
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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. 
Verify that x is the wrong value using "frame variable x" when you hit the 
second breakpoint.
Make sure this breakpoint is on a source line that does something, not in the 
middle of the function return.

If the value changes, disassemble the line and set a breakpoint on the call 
instruction for printf. See if the value changes when you hit that breakpoint.
If it does, look at the assembly and see if anything is changing the data at 
the address of x. You can get the address with "frame variable ".
If the call to printf is changing the value of x, you've probably got stack 
corruption going on.

---

Clang is supported on Linux:

>uname
Linux
>which clang
/usr/bin/clang

So you aren't forced to use gcc just because you're targeting Linux.

---

watchpoint set syntax is as follows:

(lldb) help watch set
 Commands for setting a watchpoint.

Syntax: watchpoint set  []


If you're setting it on a variable and you have good DWARF info, you don't need 
to specify a size. From my example:
> (lldb) w s v i
> Watchpoint created: Watchpoint 1: addr = 0x0410eec6 size = 2 state = 
> enabled type = w



-Original Message-
From: Jason Vas Dias  
Sent: Friday, February 15, 2019 10:33 AM
To: Ted Woodward 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] how to set a watchpoint on an "unsigned short" 
parameter ?

Good day Ted -

Thanks for responding - but I did try that one:

  (lldb) wa s v x
  error: Watchpoint creation failed (addr=0x, size=0, 
variable
expression='x').
  error: cannot set a watchpoint with watch_size of 0
  (lldb) wa s -s 2 v x
  invalid command 'watchpoint set -s'.
  (lldb) wa s v -s 2 x
  error: Watchpoint creation failed (addr=0x, size=0, 
variable
expression='x').
  error: cannot set a watchpoint with watch_size of 0

  I can't seem to get lldb to recognize the '-s' / '--size' options no matter
  where I put them .  And the documentation, such as it is,
  (on https://lldb.llvm.org/lldb-gdb.html), is very vague and incomplete.

  I guess my problems are  because I am  compiling with GCC , and trying
  to debug with LLDB .
  But since the program I am debugging is targetted mainly for the Linux 
platform,
  (I am just using MacOSX for testing) I wanted to compile with GCC .

  I guess it is not possible to debug GCC compiled programs with LLDB ?

  The problem I am trying to track down is stack corruption caused by
  fprintf() :

void f ( void *r, unsigned short x )
{  ...
   fprintf(stderr, "some string %lu %c\n",
r==(void*)0UL)? 255UL : A_MACRO(r),
x? '0' : '1'
  );
 // after this fprintf, the value of x changes from 12 to 8630 .
 // why ? It would be nice to be able to use LLDB to find out,
//  but this does not work.
}

 I've just had to comment out the fprintf , so the problem does not occur.

 Coming from a background of using GDB for the past 25 years, I find
 this lack of watchpoint support in LLDB very difficult to accept.

Thanks & Best Regards,
Jason






On 15/02/2019, Ted Woodward  wrote:
> "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/tedwood/lldb_test/watch' (hexagon) Process 1 stopped
> * thread #1, name = 'T1', stop reason = breakpoint 1.1
> frame #0: 0x50ec watch`f(i=2) at watch.c:5:4
>2
>3unsigned short f(unsigned short i)
>4{
> -> 5  i++;
>6  return i;
>7}
>8
> (lldb) w s v i
> Watchpoint created: Watchpoint 1: addr = 0x0410eec6 size = 2 state = 
> enabled type = w
> declare @ '/usr2/tedwood/lldb_test/watch.c:3'
> watchpoint spec = 'i'
> new value: 2
> (lldb) c
> Process 1 resuming
>
> Watchpoint 1 hit:
> old value: 2
> new value: 3
> Process 1 stopped
> * thread #1, name = 'T1', stop reason = watchpoint 1
> frame #0: 0x50f8 watch`f(i=3) at watch.c:6:10
>3unsigned short f(unsigned short i)
>4{
>5  i++;
> -> 6  return i;
>7}
>8
>9int main(int argc, char **argv)
>
>
>
> -Original Message-
> From: lldb-dev  On Behalf Of Jason 
> Vas Dias via lldb-dev
> Sent: Thursday, February 14, 2019 1:28 PM

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

[Ted Woodward via lldb-dev]

"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/tedwood/lldb_test/watch' (hexagon)
Process 1 stopped
* thread #1, name = 'T1', stop reason = breakpoint 1.1
frame #0: 0x50ec watch`f(i=2) at watch.c:5:4
   2   
   3unsigned short f(unsigned short i)
   4{
-> 5  i++;
   6  return i;
   7}
   8   
(lldb) w s v i
Watchpoint created: Watchpoint 1: addr = 0x0410eec6 size = 2 state = enabled 
type = w
declare @ '/usr2/tedwood/lldb_test/watch.c:3'
watchpoint spec = 'i'
new value: 2
(lldb) c
Process 1 resuming

Watchpoint 1 hit:
old value: 2
new value: 3
Process 1 stopped
* thread #1, name = 'T1', stop reason = watchpoint 1
frame #0: 0x50f8 watch`f(i=3) at watch.c:6:10
   3unsigned short f(unsigned short i)
   4{
   5  i++;
-> 6  return i;
   7}
   8   
   9int main(int argc, char **argv)



-Original Message-
From: lldb-dev  On Behalf Of Jason Vas Dias 
via lldb-dev
Sent: Thursday, February 14, 2019 1:28 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] how to set a watchpoint on an "unsigned short" parameter ?

Good day -

  I'd be most grateful if anyone could enlighten me as to how
  to set a watchpoint on an unsigned short parameter variable
  in lldb .

  I am trying to follow the instructions at :
https://lldb.llvm.org/lldb-gdb.html
  but they do not work to set watchpoints.

  There seems to be no other documentation for LLDB commands -
  or if anyone knows of any , please let me know.

  I have a function like :
void f ( unsigned short x )
{  }

  With the debugger stopped inside f, I have tried:

   (lldb)  p 
   (uint16_t *) $3 = 0x0001001122c0
   (lldb) wa s v -s 2 -w write 0x0001001122c0
   error: no variable named '0x0001001122c0' found in this frame
   (lldb) wa s v -s 2 -w write x
   error: Watchpoint creation failed (addr=0x, size=0, variable
   expression='x').
   error: cannot set a watchpoint with watch_size of 0
   (lldb) wa s e -s 2 -w write 0x0001001122c0
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write 0x0001001122c0
   (lldb) wa s e -s 2 -w write *0x0001001122c0
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write *0x0001001122c0
   (lldb) wa s e -s 2 -w write ((unsigned short*)0x0001001122c0)
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write ((unsigned short*)0x0001001122c0)
   (lldb) wa s v -s 2 -w write 
   error: 'x' doesn't have a valid address
   # ^- this error is really strange, particularly as I can do:
   (lldb) p 
   (uint16_t *) $5 = 0x0001001122c0

  It seems to me lldb's implementation of watch points is fundamentally broken -
  there is no way I've been able to get it to work .

  Unfortunately, I have to use MacOSX, so gdb is not available.

  Please, can anyone suggest how to successfully set a watchpoint on
  a parameter (stack) located variable value with lldb ?
  It does not seem to be possible.

  My next step, if no answers to this mail, would be to analyse the LLDB
  source code to see if I can figure out how watchpoints are meant to
  be set, seeing as there is no reference documentation for LLDB commands,
  either installed as manual pages or online.  This to me makes LLDB unsuitable
  for production use, but unforunately I have to use it (I need to debug under
  MacOSX 10,14.3 ).

   The help output for is of no use either:
   (lldb) help watch set
   "Syntax: watchpoint set  []
The following subcommands are supported:
  expression -- Set a watchpoint on an address by supplying an expression. 
Use the
  '-w' option to specify the type of watchpoint and the '-s'
option to specify the
  byte size to watch for.
"
The above statement is provably false:
 (lldb) wa s v -s 2 x
 error: Watchpoint creation failed (addr=0x, size=0,
   variable expression='x').
 error: cannot set a watchpoint with watch_size of 0
 # maybe the -s option goes after the 'set' ? no:
(lldb) wa s -s 2 v reader_id
invalid command 'watchpoint set -s'.

All attempts to
 "Use the '-w' option to specify the type of watchpoint and the '-s' option 
to
  specify the byte size to watch for.
 "
fail,  so there must be alot missing from the help description.

The help for the variable syntax is also vague, and provably false :
 "variable   -- Set a watchpoint on a variable. Use the '-w'
option to specify the type
 of watchpoint and the '-s' option to specify the byte size 
to watch for.
If no '-w' option is specified, it defaults to 

[lldb-dev] Odd intermittent test error

[Ted Woodward via lldb-dev]

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/TestSyntheticCapping.py' FAILED 


...

PASS: LLDB 
(/local/mnt/workspace/bots/hexbotmaster-sles11_sd_0/hexagon-clang-83/build_tools/Tools/bin/clang-7-v67)
 :: test_with_run_command_dwarf (TestSyntheticCapping.SyntheticCappingTestCase)

...

--
Ran 4 tests in 0.225s
RESULT: PASSED (1 passes, 0 failures, 0 errors, 3 skipped, 0 expected failures, 
0 unexpected successes)
terminating with uncaught exception of type std::__1::system_error: mutex lock 
failed: Invalid argument

...




Failing Tests (1):

lldb-Suite :: 
functionalities/data-formatter/synthcapping/TestSyntheticCapping.py

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Problem with address breakpoints

[Ted Woodward via lldb-dev]

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 main and
set a breakpoint:
(lldb) p main
(int (*)(int, char **)) $0 = 0x00400570
(lldb) b 0x400570
Breakpoint 1: address = 0x00400570

I run, it launches and runs to completion:
(lldb) r
Process 20293 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Factorial of 10 is 3628800
Process 20293 exited with status = 0 (0x)

Set a breakpoint by line, launch, and it stops:
(lldb) b 19
Breakpoint 2: where = factlin`main + 22 at factorial.c:32, address =
0x00400586
(lldb) r
Process 20352 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Process 20352 stopped
* thread #1, name = 'factlin', stop reason = breakpoint 2.1
frame #0: 0x00400586 factlin`main(argc=1,
argv=0x7fffe218) at factorial.c:32
   29 }
   30   */
   31  
-> 32 base = 10;
   33  
   34 printf("Factorial of %d is %d\n", base, factorial(base));
   35 return 0;

Set the breakpoint by address while the process is running and run again.
This time it stops at the new address breakpoint.
(lldb) b 0x400570
Breakpoint 3: where = factlin`main at factorial.c:13, address =
0x00400570
(lldb) r
There is a running process, kill it and restart?: [Y/n] 
Process 20352 exited with status = 9 (0x0009) 
Process 20366 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Process 20366 stopped
* thread #1, name = 'factlin', stop reason = breakpoint 3.1
frame #0: 0x00400570 factlin`main(argc=,
argv=) at factorial.c:13
   10   }
   11  
   12   int main(int argc, char **argv)
-> 13   {
   14 unsigned base;
   15  
   16   /*

Break list shows the first breakpoint as unresolved, and the third as
resolved.
(lldb) br l
Current breakpoints:
1: address = 0x00400570, locations = 1
  1.1: address = 0x00400570, unresolved, hit count = 0 

2: file = '/usr2/tedwood/lldb_test/factorial.c', line = 19, exact_match = 0,
locations = 1, resolved = 1, hit count = 1
  2.1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586, resolved, hit count = 1 

3: address = factlin[0x00400570], locations = 1, resolved = 1, hit
count = 1
  3.1: where = factlin`main at factorial.c:13, address = 0x00400570,
resolved, hit count = 1



Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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/shared/libraries/usr/lib/libc.so

 

Matching up trailing slashes is critical, as I learned the hard way!

 

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-boun...@lists.llvm.org] On Behalf Of Eugene
Birukov via lldb-dev
Sent: Friday, July 20, 2018 1:13 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] LLDB does not respect platform sysroot when loading core
on Linux

 

Hello,

 

I would appreciate advise how to fix this correctly.

 

I have a core dump from somebody's RHEL Linux and I am trying to open it on
my Ubuntu. I have all the shared libraries from the target sitting under my
local directory. So, GDB happily opens the core after I issue "set sysroot
/path/to/local/root", but LLDB release_60 fails to do it.

 

I follow instructions from Greg's Clayton mail
http://lists.llvm.org/pipermail/lldb-dev/2016-January/009236.html :

 

(lldb) platform select --sysroot /path/to/remote/shared/libraries
remote-linux

(lldb) 

 

Under debugger, I see that LLDB successfully created Platform object with
m_sdk_root set to my path and the Target uses it as its platform:

 

(gdb) p target_sp->m_platform_sp->m_sdk_sysroot

$42 = {

  m_string = 0x80e070 "/tmp/debugcore.3WyoW4/lib2"

}

 

But this value is not used when it comes to
DynamicLoaderPOSIXDYLD::LoadAllCurrentModules. 

(gdb) bt

#0  lldb_private::ModuleList::GetSharedModule (module_spec=...,
module_sp=std::shared_ptr (empty) 0x0,

module_search_paths_ptr=0x83ad60, old_module_sp_ptr=0x7fffbb50,
did_create_ptr=0x7fffbb07,

always_create=false) at
/home/eugene/llvm/tools/lldb/source/Core/ModuleList.cpp:710

#1  0x7fffedc2d130 in lldb_private::Platformoperator()(const lldb_private::ModuleSpec &)
const (__closure=0x8581b0, spec=...)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:234

#2  0x7fffedc34ff2 in std::_Function_handler >::_M_invoke(const std::_Any_data &, const
lldb_private::ModuleSpec &) (__functor=..., __args#0=...) at
/usr/include/c++/5/functional:1857

#3  0x7fffedc37978 in std::function::operator()(lldb_private::ModuleSpec
const&) const (this=0x7fffba80, __args#0=...) at
/usr/include/c++/5/functional:2267

#4  0x7fffedc3375a in
lldb_private::Platform::GetRemoteSharedModule(lldb_private::ModuleSpec
const&, lldb_private::Process*, std::shared_ptr&,
std::function
const&, bool*) (this=0x839330, module_spec=..., process=0x84d310,
module_sp=std::shared_ptr (empty) 0x0,

module_resolver=..., did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:1628

#5  0x7fffedc2d2cd in lldb_private::Platform::GetSharedModule
(this=0x839330, module_spec=...,

process=0x84d310, module_sp=std::shared_ptr (empty) 0x0,
module_search_paths_ptr=0x83ad60,

old_module_sp_ptr=0x7fffbb50, did_create_ptr=0x7fffbb07)

at /home/eugene/llvm/tools/lldb/source/Target/Platform.cpp:240

#6  0x7fffedc9957c in lldb_private::Target::GetSharedModule
(this=0x846960, module_spec=..., error_ptr=0x0)

at /home/eugene/llvm/tools/lldb/source/Target/Target.cpp:1952

#7  0x7fffef8e0d11 in lldb_private::DynamicLoader::LoadModuleAtAddress
(this=0x9a0a70, file=...,

link_map_addr=139700267943784, base_addr=139700263510016,
base_addr_is_offset=true)

at /home/eugene/llvm/tools/lldb/source/Core/DynamicLoader.cpp:171

#8  0x7fffedd8fb55 in DynamicLoaderPOSIXDYLD::LoadAllCurrentModules
(this=0x9a0a70)

at
/home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/Dynamic
LoaderPOSIXDYLD.cpp:537

#9  0x7fffedd8de52 in DynamicLoaderPOSIXDYLD::DidAttach (this=0x9a0a70)

at
/home/eugene/llvm/tools/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/Dynamic
LoaderPOSIXDYLD.cpp:171

#10 0x7fffedc476d9 in lldb_private::Process::LoadCore (this=0x84d310)

at /home/eugene/llvm/tools/lldb/source/Target/Process.cpp:2853

 

I simply do not see any reference to sysroot in the GetSharedModule() code.
What is there - it is only scanning module_search_paths_ptr looking for
file. This would not work because the scan ignores the directory part of the
module: it takes the next path from the list and appends the file name. What
I need instead - take m_sdk_sysroot from Platform and append the full module
- including directory - to it.

 

Unfortunately, GetSharedModule() is a static method and does not have any
clue what is current platform or current target. So, should I pass another
argument down there with sysroot or what? I have correct platform object at
frame 4.

 

Thanks,

Eugene

 

 

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

[Ted Woodward via lldb-dev]

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 build it with g++ 4.8.4
as well.

% clang++ get_id.pass.cpp -o get_id.pass.cpp.exe -g -O0 -std=c++11
% lldb get_id.pass.cpp.exe
(lldb) b main
(lldb) run
(lldb) image dump symfile

(lldb) image dump symfile
Segmentation fault

Test was run on Ubuntu 14.04. The crash happens in TypeList::Dump

void TypeList::Dump(Stream *s, bool show_context) {
  for (iterator pos = m_types.begin(), end = m_types.end(); pos != end;
++pos) {
pos->get()->Dump(s, show_context);
  }
}

The call to Dump can change the vector, which makes the iterator invalid and
causes the crash when it's incremented. The change seems to happen in
SymbolFileDWARF::GetTypeForDIE.

The vector has a size of 8. Entries are:
"id"
"id"
"std::__1::__thread_id"
"std::__1::__thread_id"
"__thread_id"
"__thread_id"
"__libcpp_thread_id"
"__libcpp_thread_id"

The crash occurs when the 5th entry, the first "__thread_id", is dumped.
After the crash, the vector has 18 entries. The first 6 are the same as
before the Dump call that crashes.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Cannot install from source

[Ted Woodward via lldb-dev]

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à via lldb-dev
Sent: Wednesday, July 18, 2018 11:29 AM
To: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Cannot install from source

 

Indeed that folder is not present. Python 2.7 is installed and it is the 
default version of the system, I'm not changing its setting in the build.

On 18/07/18 18:19, Ted Woodward wrote:

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 Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of nu 
quaquaraqua via lldb-dev
Sent: Wednesday, July 18, 2018 8:17 AM
To: lldb-dev@lists.llvm.org  
Subject: [lldb-dev] Cannot install from source

 

Dear folks,

 

I am trying to build & install LLVM, Clang and LLDB from source. Now the build 
completes fine, while the target `install' fails: 

 

-- Up-to-date: /opt/llvm/6.0.1/include/lldb/Host/Config.h

CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):

  file INSTALL cannot find "/opt/llvm/build/lib/python2.7".

Call Stack (most recent call first):

  tools/lldb/cmake_install.cmake:51 (include)

  tools/cmake_install.cmake:49 (include)

  cmake_install.cmake:65 (include)

 

 

make: *** [Makefile:140: install] Error 1

 

 

I am on branch `release 6.0', out of source build, all the defaults with the 
exception of the build type set to Release, custom prefix path, and target to 
build X86. The system is a Linux Fedora v28.

 

Suggestions on how to move on? :-)

Yours,

Quack

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Cannot install from source

[Ted Woodward via lldb-dev]

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 Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of nu 
quaquaraqua via lldb-dev
Sent: Wednesday, July 18, 2018 8:17 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Cannot install from source

 

Dear folks,

 

I am trying to build & install LLVM, Clang and LLDB from source. Now the build 
completes fine, while the target `install' fails: 

 

-- Up-to-date: /opt/llvm/6.0.1/include/lldb/Host/Config.h

CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):

  file INSTALL cannot find "/opt/llvm/build/lib/python2.7".

Call Stack (most recent call first):

  tools/lldb/cmake_install.cmake:51 (include)

  tools/cmake_install.cmake:49 (include)

  cmake_install.cmake:65 (include)

 

 

make: *** [Makefile:140: install] Error 1

 

 

I am on branch `release 6.0', out of source build, all the defaults with the 
exception of the build type set to Release, custom prefix path, and target to 
build X86. The system is a Linux Fedora v28.

 

Suggestions on how to move on? :-)

Yours,

Quack

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 status” after “file Test”?

 

Is the remote-built executable available on your Mac? lldb will need it to be 
able to get symbols and debug info.

 

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-boun...@lists.llvm.org] On Behalf Of NeckTwi 
via lldb-dev
Sent: Monday, July 09, 2018 1:27 PM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] error: process launch failed: Lost debug server connection

 

I have started lldb-server on remote linux in the directory where my executable 
need to be debugged reside.

>From my Mac I started lldb, 

(lldb) platform select remote-linux

  Platform: remote-linux

 Connected: no

(lldb) platform connect connect://pi.local:9091

  Platform: remote-linux

OS Version: 4.9.78 (4.9.78-v7+)

Kernel: #1084 SMP Thu Jan 25 18:05:49 GMT 2018

  Hostname: pi

 Connected: yes

WorkingDir: /Users/necktwi/Workspace/RemoteDebugTest/build

(lldb) file Test

Current executable set to ’Test' (arm).

(lldb) run

error: process launch failed: Lost debug server connection

 

Why the process launch failing? The executable `Test` takes parameters `-s 
normal`. How to feed them in? Did the process failed because of not feeding its 
arguments?

 

https://lldb.llvm.org/remote.html 

  explains how to debug a cross-built local executable on remote platform. But 
I am trying to debug the executable which was built on the remote.

 

Thank you.

 

… neckTwi



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 source, so you can set a breakpoint 
based on the text of an annotation. You could wrap this in a python script if 
you want to make it into a custom command.

Ted

--
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 Pavel
> Labath via lldb-dev
> Sent: Friday, June 08, 2018 5:13 AM
> To: bewoayia.kebian...@offis.de
> Cc: LLDB 
> Subject: Re: [lldb-dev] LLDB fails to load C++ Plugin (sharedlib) - error: 
> this file
> does not represent a loadable dylib
> 
> I would expect the issue is that dlopen fails to locate the dependent 
> libraries of
> your plugin. Can you lookup the actual dlopen call which opens your library 
> and
> see what is the exact error it fails with?
> On Fri, 8 Jun 2018 at 10:52, Bewoayia Kebianyor via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > Hello Everyone,
> >
> > I started looking into the LLDB with the intention of adding custom commands
> for my SW debugging purpose. For a better Understanding let me explain what
> I intend to do. I have an source file generated automatically from a Model 
> with
> certain anotations added as comments in the code. This code will would be
> compiled and in error cases debugged. When debugging I may have to set
> breakpoints at certain statements in the code based on the anotations incerted
> by the code generator. This is done by specifying the source file and the line
> number. I Use CLANG to get the line number and source file for the comments.
> >
> > I would like to have custom commands for this and internally map the to
> already existing commands  e.g. "breakpoint set -f -l". I found some examples
> for python, and for c++ I only found the example
> "lldb/examples/plugins/commands/fooplugin.cpp" for writing C++ plugin
> (dynLib) shipped with the LLDB source. In this example adding a new
> commands was straight forward and in the DoExecute function, I call the
> interpreter to handle a breakpoint command. I intend to use C++ rather than
> Python.
> >
> > This works fine for a simple shared lib (Simple modification of the Example
> provided in LLDB. In Do execute call interpreter to handle a breakpoint
> command). However if I add other C++ sources which does XML parsing,
> CLANG RecursiveASTVisitor etc to the Library, creating the shared library with
> eclipse is sucessful. I can link the created library to an application and it 
> works
> well. However when I load this in lldb with the command ==> plugin load
> "/home/bkebianyor/eclipse-
> workspace/Model_LLDB_Debugger/Debug/libModel_LLDB_Debugger.so", I get
> the error message: "error: this file does not represent a loadable dylib".
> >
> >
> > #Loading the shared lib that is linked just to the liblldb.so -
> > SUCESSFUL
> > (lldb)
> > (lldb) plugin load
> > /home/bkebianyor/eclipse-workspace/DynLib/Debug/libDynLib.so
> > (lldb)
> >
> > #Loading the shared lib that is linked just to the liblldb.so +
> > libxerces-c-3.2.so - FAILS
> >
> > (lldb) plugin load  "/home/bkebianyor/eclipse-
> workspace/Model_LLDB_Debugger/Debug/libModel_LLDB_Debugger.so"
> > error: this file does not represent a loadable dylib
> >
> > I have searched for this error on google, but could not find out how to 
> > resolve
> this error. Most answers pointed to a mismatch of the lldb version in the 
> shared
> lib to be loaded and that linked to lldb, but that is not my case. I am using 
> lldb-
> 5.0.2 and LLVM/CLANG 5.0.2 toolcahin on Linux 16.04.1-Ubuntu and Eclipse
> IDE. LLVM was built with SHARED_LIBS set to ON.
> >
> > Would be grateful for an answer.
> >
> >
> > Thanks and Regards,
> >
> > Bewoayia
> >
> > -
> > Dipl.- Ing. Bewoayia Kebianyor
> > Researcher - Hardware/Software Design Methodology Group
> >
> > OFFIS e.V. - Institut für Informatik
> > FuE Bereich Verkehr | R Division Transportation Escherweg 2 - 26121
> > Oldenburg - Germany
> > Phone/Fax.: +49 441 9722 237/-278
> > E-Mail: bewoayia.kebian...@offis.de
> > URL: http://www.offis.de
> >
> > Registergericht: Amtsgericht Oldenburg VR 1956
> > Vorstand: Prof. Dr.-Ing. Wolfgang H. Nebel (Vorsitzender), Prof. Dr.
> > techn. Susanne Boll-Westermann, Prof. Dr. Werner Damm, Prof. Dr.-Ing.
> > Axel Hahn, Prof. Dr.-Ing. Andreas Hein, Prof. Dr. Sebastian Lehnhoff
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> 

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

[Ted Woodward via lldb-dev]

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) through the SoC
- cache coherent physical access through the SoC
- uncached physical access through the SoC
- virtual access through a given core (PPC or StarCore)
- cache coherent physical access through a given core
- uncached physical access through a given core

I also provided a cache view which would allow the user to read/modify data and 
tag/status of the L1i, L1d, L2 and L3 caches.

Basically, let the user access memory (whether it was RAM, memory mapped 
registers, or something else) any way he or she wants. What the core sees, what 
the SoC sees, cacheable, uncached (so, in the backing store), or what's in the 
caches.

Once you have memory space support, you can make arbitrary spaces that show you 
whatever you want.

--
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 Duane
> Ellis via lldb-dev
> Sent: Friday, May 25, 2018 9:40 AM
> To: Zdenek Prikryl 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Advice on architectures with multiple address spaces
> 
> As an FYI - this is another way of looking at Address spaces.. I like the word
> “Route” to the memory space, i think it defines the problem better.
> 
> All Armv8 chips effectively have - multiple address available to the debugger
> 
> For instance, a JTAG debugger halts an ARMV8 cpu core, and the core halts in
> user space - the question is what are the various address spaces a developer
> might want to dump memory for:
> 
> A) The current user space view of memory - to print a user space variable.
> 
> B) The current Kernel (OS) view of memory - perhaps to print data structure in
> kernel space
> 
> C) At the hypervisor level which is the core’s view of physical memory - 
> perhaps
> the developer wants to examine a data structure or variable in the hypervisor.
> 
> D) The ARM dap - has 3 (sometime 4) memory bus interfaces. They are
> typically:
> 
> Dap Port 0 - is typically the main system bus, often the same as the CPU’s
> connection to the main system bus but not exactly
> 
> ie: CPU access to a multi-media bus, via a dedicated connection/address range,
> in contrast the  main system bus has a different connection/route to the
> multimedia memory
> 
> Dap Port 1 - commonly provides access to various Coresight items for most of
> the cores.
> 
> Dap Port 2 - Varies - it could be an embedded Jtag controller - say with an
> ARM9 or other JTAG only interface)
> 
> Dap Port 3 - Varies - But often there are a few CORTEX M series CPUs - and I
> believe each M3 on the target must have its own dedicated DAP interface.
> 
> Assume for a moment, each of these address spaces have a name, there is the
> default, then there needs to be various override methods
> 
> Being able to some how specify these different “access routes” is helpful when
> debugging hardware at the bare metal level.
> 
> In the above, I’m not talking about looking at a complex variable (that would 
> be
> really nice, ie: cast a memory address to a fancy type)
> 
> When debugging a SYSTEM - this becomes very important.  Minimally being
> able to have a “memory window” that can specify the route is helpful - for
> example
> 
>   Dump Memory at :  HyperVisor address 0x12345678
>   Dump Memory at:  Kernel address  0x45678901234
>   Dump Memory using the system bus interface
> 
> Across multiple cores - you have
> 
> 1) Some very common routes - ie: “In the current context” vrs “Kernel context”
> These should have commonly defined names.
> 
> 2) Some platforms may need to add their own “platform defined” items (ie:
> various armv8 routes would be semi-common)
> 
> 3) Some VERY specific routes or methods that are developer defined - For
> example when accessing memory via the DAP MEM_AP, there are special bits
> in the control register (controlling security and/or cache control). Maybe the
> developer needs to set those a special way when performing the memory
> access when using this “route”
> 
> The lauterbach jtag debugger can do the above now (it is an address prefix)
> The ARM debugger (If I remember correctly) can also do this somewhere in its
> script language.
> 
> But tools like GDB and LLDB can not
> 
> Because tools like GDB and LLDB have a scripting language (ie: Python) - being
> able to write a script in that scripting language and be able to specify the
> ROUTE is important.
> 
> For example, a script that writes to a bunch of hardware locations via the
> MEMAP (or possibly via different CPU) - to enable a feature so that you can 
> 

Re: [lldb-dev] Welcome Alexander!

[Ted Woodward via lldb-dev]

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 funky 
decisions made when it was first developed.

Ted

--
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 Jim
> Ingham via lldb-dev
> Sent: Tuesday, April 24, 2018 5:19 PM
> To: Greg Clayton 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Welcome Alexander!
> 
> 
> 
> > On Apr 24, 2018, at 3:08 PM, Greg Clayton  wrote:
> >
> >
> >
> >> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> >>
> >>
> >>
> >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton  wrote:
> >>>
> >>>
> >>>
>  On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
> 
> 
> 
> > On Apr 24, 2018, at 9:44 AM, Greg Clayton 
> wrote:
> >
> >
> >
> >> On Apr 24, 2018, at 9:37 AM, Jim Ingham 
> wrote:
> >>
> >>>
> >>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev  d...@lists.llvm.org> wrote:
> >>>
> >>> Welcome Alexander!
> >>
> >> Yes, welcome!
> >>
> >>>
> >>> The title might be more stated as "Reimplement lldb-mi to correctly
> use the SB API instead of using HandleCommand and regular expressions to
> parse the command results" as it is already using the SB API, just not using 
> it
> anywhere close to correctly!
> >>>
> >>> I look forward to seeing the changes.
> >>>
> >>> A few things I ran into when playing with lldb-mi:
> >>> - file-exec or exec-file packet might come _after_ some breakpoints
> are set. We should make sure we create a lldb::SBTarget right away and set the
> breakpoints on the empty target so that we don't miss these breakpoints if 
> this
> is still an issue. Then the when we receive the exec-file packet, we set the 
> file
> on the target
> >>
> >> Breakpoints set before any target is created are set on the dummy
> target.  Breakpoints on the dummy target are copied into any new targets.  So
> this should not be necessary.  If that wasn't working we should figure that 
> out,
> but it's not the responsibility of the MI to get this right.
> >
> > We are trying not to use the command line and the command line is
> what uses the dummy target automatically. When using the SB API you use a
> lldb::SBTarget to set the breakpoint on so you need a target. What do you
> suggest we use for the target? I would rather the lldb-mi code not rely on the
> currently selected target or the dummy target.
> 
>  lldb-MI models gdb's behavior, which is one debugger with one target.
> There is no command to add or switch to targets, etc.  So it doesn't seem
> unreasonable for MI to keep track of its one actual target and if that is 
> empty,
> use SBDebugger::GetDummyTarget.  The other option is to make a blank target
> up front and then add files to it when you see the -file-exec command. But 
> that
> seems more error-prone than using the mechanism lldb provides for doing
> things before you have a target.  Again, if we were modeling an API that could
> switch targets we might want to do something more clever.  But that isn't how
> the GDB-MI was set up to work.
> 
> >>>
> >>> lldb-mi code may or may not have a target when it needs one. If it doesn't
> have a target, use the SB API to get the dummy target and use that.
> >>>
> >>> Jim: is the dummy target good for anything other than adding breakpoints
> to? What all gets copied from a the dummy target to the new target when one
> gets created?
> >>
> >> At present it only does breakpoints and stop hooks (see
> Target::PrimeFromDummyTarget.)  I didn't do watchpoints since those are
> seldom things you want to set generically, but you could probably add that.
> Was there anything else you were thinking of?
> >>
> >
> > No, just mostly trying to let Alexander know what he should use the Dummy
> target for and also for my own knowledge. If there are MI clients that do 
> other
> things, we will need to know if we need to create an empty real target if they
> aren't breakpoints or stop hooks.
> 
> I can't think of any other things you add to a target like this.  The 
> settings get
> inherited, and once you've started adding modules, I think you should create a
> new target to hold them.  But for anything interesting that's missing, as 
> long as
> they are copiable it would be easy to add them.  Just call
> GetSelectedOrDummyTarget when you go to set them, and then put the copy in
> PrimeFromDummyTarget.
> 
> >
> > Greg
> >
> >> Jim
> 

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

[Ted Woodward via lldb-dev]

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 config in lldb is different 
from the cmake code that sets up the lit config in clang. This is causing the 
VS generator errors, and might be causing your problems with ninja.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Adrian 
McCarthy via lldb-dev
Sent: Friday, April 20, 2018 1:21 PM
To: LLDB 
Subject: [lldb-dev] problems running the LLDB lit tests on Windows

 

I'm trying to figure out what's happening with the LLDB lit tests on Windows.  
I'm not sure how to proceed with debugging this.

 

I execute this command:

 

  ninja check-lldb

 

And several things happen very rapidly:

 

1.  On the console, I get one warning that says:

 

D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\discovery.py:121: 
ResourceWarning: unclosed file <_io.BufferedReader name=3>

key = (ts, path_in_suite)

  

2.  Then I get several dozen messages of this form:

 

D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\TestRunner.py:727: 
ResourceWarning: unclosed file <_io.BufferedReader name=6>

res = _executeShCmd(cmd.rhs, shenv, results, timeoutHelper)

  

3.  I get more than 200 dialog boxes that are essentially assertion failures in 
the CRT implementation of `close`.  The line complained about in the dialog is:

  

_VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), 
EBADF, -1);

  

where `fh` is the value passed to `close`.  Indeed, `fh` typically has a value 
like 452 which is not in the range of 0 to `_nhandle` because `_nhandle` is 64.

 

Starting from 3, I tried to walk up the stack to see what's going on, but it's 
just the generic workings of the Python virtual machine.  The `close` call is 
happening because something in the .py code is calling `close`.  It's hard to 
see the Python code in the debugger.  It doesn't actually seem to be test code.

 

So I checked out the command line for one of those asserting processes to see 
if I could figure out which tests are exhibiting the problem.

 

"C:\python_35\python_d.exe" "-R" "-c" "from multiprocessing.spawn import 
spawn_main; spawn_main(pipe_handle=992, parent_pid=32640)" 
"--multiprocessing-fork"



The `pipe_handle` value does not correspond to the value being passed to the 
`close`.  The `parent_pid` always refers to the parent lit command.

 

There always seem to be 32 Python processes in this state.  If I kill one, 
another is immediately spawned to replace it (creating a new assertion failure 
dialog).  I'm guessing that if I continued, there would be one for each test, 
and that somewhere there's a limit of 32 processes at a time.

 

So this kind of sounds like a lit bug, but other lit tests (as in `ninja 
check-llvm`) run just fine.  So it has something to do with how we invoke lit 
for LLDB.  The command being executed, per the build.ninja file, is:

 

cd /D D:\src\llvm\build\mono\tools\lldb\lit && C:\python_35\python_d.exe 
D:/src/llvm/build/mono/./bin/llvm-lit.py -sv --param 
lldb_site_config=D:/src/llvm/build/mono/tools/lldb/lit/lit.site.cfg --param 
lldb_unit_site_config=D:/src/llvm/build/mono/tools/lldb/lit/Unit/lit.site.cfg 
D:/src/llvm/build/mono/tools/lldb/lit

 

The LLDB-specific things in the command are lit configs, with which I've been 
blissfully ignorant.  Should I head down that rabbit hole?  Could this be a 
problem with my environment?

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 doesn't have dsymutil, cmake
generation gives errors about missing dependency dsymutil.

CMake Error at tools/lldb/test/CMakeLists.txt:161 (add_dependencies):
   The dependency target "dsymutil" of target "lldb-dotest" does not exist.

Jonas, can you gate those changes with a check for Darwin, which is the
intention of the patch?

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 teaching the makefile to 
use cl syntax shouldn't be too hard. I've seen it done before; same makefile 
for windows and various unix derivatives, detect what OS you were running on 
and set CFLAGS/CXXFLAGS/LDFLAGS accordingly.

Ted

--
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 Pavel
> Labath via lldb-dev
> Sent: Thursday, April 19, 2018 12:45 PM
> To: Leonard Mosescu 
> Cc: aaron.lee.sm...@gmail.com; LLDB 
> Subject: Re: [lldb-dev] Proposal: Using LLD in tests
> 
> On Thu, 19 Apr 2018 at 18:19, Leonard Mosescu 
> wrote:
> 
> >>the PDB tests under lit/SymbolFile/PDB need a linker to produce
> >> the
> program database
> 
> 
> > With this proposal, would we preserve any coverage for MSVC produced
> debug information?
> 
> 
> Well.. the question there is what are you trying to test? Is it the fact your
> debugger works with a particular compiler+linker combination (note that those
> tests already compile with clang-cl), or that your pdb-parsing code is sane.
> (integration vs. regression test).
> 
> Historically we've only had the former kind of tests (dotest), and we've had 
> the
> ability (and used it) to run those tests against different kinds of 
> compilers. This
> is all nice, but it means that a specific test will be testing a different 
> thing for
> every person who runs it. That's why I would like to build up a suite of more
> regression-like tests (*). I would say that the tests under lit/*** should be
> regression tests and our goal should be to remove as many system
> dependencies as possible, and leave the job of testing integration with a
> specific toolchain to "dotest" tests (**).
> 
> Technically, the answer to your question is "no", because currently dotest 
> tests
> don't know how to work with cl+link. Making that work would be an interesting
> project (although a bit annoying as the Makefiles are full of gcc-isms).
> However, I don't think that should stop us here.
> 
> (*) Ideally I would like to leave even the compiler out of the equation for 
> these
> tests, and make it so that the tests always run on the exact same set of 
> bytes. I
> am hoping I will be able to write at least some tests using .s files. 
> However, I
> don't think I will do that for all of them, because these files can be
> long/verbose/tedious to write.
> 
> (**) However, even "dotest" tests should have a "default" mode which is as
> hermetic as possible.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 of them) for the 
address.

Ted

--
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 Greg
> Clayton via lldb-dev
> Sent: Thursday, April 19, 2018 11:45 AM
> To: Zdenek Prikryl 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Advice on architectures with multiple address spaces
You might ask
> the Hexagon folks if they have done anything in case they already support this
> is some shape or form.
> 
> Greg Clayton
> 



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

Responses inline

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: Greg Clayton [mailto:clayb...@gmail.com]
> Sent: Tuesday, April 03, 2018 5:19 PM
> 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 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 and debugserver/lldb-server.
> >
> > On a hardware target, our OS has a debug stub. We'd like to run the
> > lldb test suite talking to this stub on the simulator, instead of
> > talking to the RSP interface the simulator publishes. We have a module
> > that will forward ports to the OS under simulation, but to do this I
need to:
> > 1) open an http connection to port x
> > 2) parse some xml coming back that contains the actual port for the
> > stub I want to connect to
> > 3) connect to the new port
> 
> 
> Can't you forward ports in advance and then run lldb-server in platform
mode
> and tell it to use only those ports? Then lldb-server will do everything
it needs.
> There is a port offset option to lldb-server that can be used in case the
lldb-
> server that runs on the simulator returns say port , but it needs to
have
> 1 added to it...

Short answer - no.  It's a custom stub, not lldb-server, but that's not the
issue.
The issue is that the mechanism to get data into the simulation mimics what
we do on
hardware, where the DSP doesn't have access to the outside world, and
everything
goes through an Android app. The system publishes 1 port per process that
the stub
controls. These ports are picked randomly, and are set up when the http
connection
is made. The data that is read over that connection needs to be parsed to
find the
ports that the stub is publishing.

> > I have a python script that will do this, but I need to do it inside
> > LLDB
> > c++ code in GDBRemoteCommunication.cpp, so when I do a "run" it will
> > c++ jump
> > through the correct hoops and connect to the stub under simulation.
> >
> > Is there a good way to call a python script from LLDB c++ code and get
> > a result back? Or is there a better solution?
> >
> 
> The the main question is can you run lldb-server in the simulator and have
the
> test suite just work? What is stopping you from being able to do that if
the
> answer is no?

I've got the test suite working using the simulator's RSP interface, but the
next step
is to exercise the OS stub. And to get to it I have to jump through the
hoops I talked
about earlier.

> It sounds like a real hack if you have to run a python script in
> ProcessGDBRemote. It sounds like you need to just modify your hexagon
> simulator platform code to "do the right thing".

"Do the right thing" in this case involves opening an http connection,
parsing XML,
and telling LLDB to connect to the port I get from the XML. The launch is
done inside
Process::Launch, which is called from the platform, so I can't do any
processing
In the platform.

Worst case I could do something like 'system("python sim_stub_connect.py")'
to get the port
that's being published, if using LLDB's interpreter is not a good idea.

> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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
and debugserver/lldb-server.

On a hardware target, our OS has a debug stub. We'd like to run the lldb
test suite talking to this stub on the simulator, instead of talking to the
RSP interface the simulator publishes. We have a module that will forward
ports to the OS under simulation, but to do this I need to:
1) open an http connection to port x
2) parse some xml coming back that contains the actual port for the stub I
want to connect to
3) connect to the new port

I have a python script that will do this, but I need to do it inside LLDB
c++ code in GDBRemoteCommunication.cpp, so when I do a "run" it will jump
through the correct hoops and connect to the stub under simulation.

Is there a good way to call a python script from LLDB c++ code and get a
result back? Or is there a better solution?

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 with 
Android Studio’s lldb, and in Android Studio we opened a console window and 
ssh’d to Hexagon Linux, where we ran lldb (yes, Greg, lldb under Linux on the 
DSP!). We were able to debug the interaction between the CPU and DSP.

 

The reason I say you might not need non-stop mode is another DSP use case. On 
our proprietary DSP OS, the debug agent doesn’t stop all threads in a process 
when one thread stops. Even though lldb acts like all threads are stopped, only 
one stopped and the others are still running. As long as the stub doesn’t error 
out when lldb checks the other threads, lldb will behave correctly. If another 
thread hits a breakpoint while the current one is stopped, the stub waits until 
it gets a resume to send the stop-reply. So lldb thinks everything is stopped, 
but it’s not really.

 

--

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 Ramana via 
lldb-dev
Sent: Friday, March 30, 2018 12:29 PM
To: Frédéric Riss 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

 

> I’m not sure why Ramana is interested in it

Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html is 
what I am trying to implement in lldb which has been discussed in little more 
details here 
http://lists.llvm.org/pipermail/lldb-dev/2017-September/012815.html. 

 

On Thu, Mar 29, 2018 at 9:40 PM, Frédéric Riss  > wrote:





On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev  > wrote:

 

 





On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev  > wrote:

 

Hi,

It appears that the lldb-server, as of v5.0, did not implement the GDB RSPs 
non-stop mode 
(https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop).
 Am I wrong?

If the support is actually not there, what needs to be changed to enable the 
same in lldb-server?

 

As Pavel said, adding support into lldb-server will be easy. Adding support to 
LLDB will be harder. One downside of enabling this mode will be a performance 
loss in the GDB remote packet transfer. Why? IIRC this mode requires a read 
thread where one thread is always reading packets and putting them into a 
packet buffer. Threads that want to send a packet an get a reply must not send 
the packet then use a condition variable + mutex to wait for the response. This 
threading overhead really slows down the packet transfers. Currently we have a 
mutex on the GDB remote communication where each thread that needs to send a 
packet will take the mutex and then send the packet and wait for the response 
on the same thread. I know the performance differences are large on MacOS, not 
sure how they are on other systems. If you do end up enabling this, please run 
the "process plugin packet speed-test" command which is available only when 
debugging with ProcessGDBRemote. It will send an receive various packets of 
various sizes and report speed statistics back to you.



 

Also, in lldb at least I see some code relevant to non-stop mode, but is 
non-stop mode fully implemented in lldb or there is only partial support?

 

Everything in LLDB right now assumes a process centric debugging model where 
when one thread stops all threads are stopped. There will be quite a large 
amount of changes needed for a thread centric model. The biggest issue I know 
about is breakpoints. Any time you need to step over a breakpoint, you must 
stop all threads, disable the breakpoint, single step the thread and re-enable 
the breakpoint, then start all threads again. So even the thread centric model 
would need to start and stop all threads many times. 

 

If we work on this, that’s not the way we should approach breakpoints in 
non-stop mode (and it’s not how GDB does it). I’m not sure why Ramana is 
interested in it, but I think one of the main motivations to add it to GDB was 
systems where stopping all some threads for even a small amount of time would 
just break things. You want a way to step over breakpoints without disrupting 
the other threads.

 

Instead of removing the breakpoint, you can just teach the debugger to execute 
the code that has been patched in a different context. You can either move the 
code someplace else and execute it there or emulate it. Sometimes you’ll need 
to patch it if it is PC-relative. IIRC, GDB calls this displaced stepping. It’s 
relatively 

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

[Ted Woodward via lldb-dev]

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, but I found that setting the lldb-mi log to 
be
stdout helps a lot. In lldbmi_testcase.py, in spawnLldbMi, add this line:

self.child.logfile = sys.stdout

--
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 Vedant
> Kumar via lldb-dev
> Sent: Tuesday, March 13, 2018 7:48 PM
> To: Davide Italiano 
> Cc: LLDB 
> Subject: Re: [lldb-dev] increase timeout for tests?
> 
> As a first step, I think there's consensus on increasing the test timeout to 
> ~3x
> the length of the slowest test we know of. That test appears to be
> TestDataFormatterObjC, which takes 388 seconds on Davide's machine. So I
> propose 20 minutes as the timeout value.
> 
> Separately, regarding x-failed pexpect()-backed tests, I propose deleting them
> if they've been x-failed for over a year. That seems like a long enough time 
> to
> wait for someone to step up and fix them given that they're a real
> testing/maintenance burden. For any group of to-be-deleted tests, like the 22
> lldb-mi tests x-failed in all configurations, I'd file a PR about potentially
> bringing the tests back. Thoughts?
> 
> thanks,
> vedant
> 
> > On Mar 13, 2018, at 11:52 AM, Davide Italiano 
> wrote:
> >
> > On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham 
> wrote:
> >> It sounds like we timing out based on the whole test class, not the 
> >> individual
> tests?  If you're worried about test failures not hanging up the test suite 
> the you
> really want to do the latter.
> >>
> >> These are all tests that contain 5 or more independent tests.  That's
> probably why they are taking so long to run.
> >>
> >> I don't object to having fairly long backstop timeouts, though I agree with
> Pavel that we should choose something reasonable based on the slowest
> running tests just so some single error doesn't cause test runs to just never
> complete, making analysis harder.
> >>
> >
> > Vedant (cc:ed) is going to take a look at this as he's babysitting the
> > bots for the week. I'll defer the call to him.
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] tests xfailed globally with radar references

[Ted Woodward via lldb-dev]

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 variable is out of scope. Which can happen a lot if the variable being
watched is a local on the stack. I manually ran the testcase on Linux, and
it failed when it hit the watchpoint out of scope:
Process 18652 stopped
* thread #1, name = 'a.out', stop reason = watchpoint 1
frame #0: 0x7722d0d2 libc.so.6`__run_exit_handlers(status=0,
listp=0x775b36c8, run_list_atexit=true) at exit.c:35

A google search found this message, posted by Ed Maste to llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116471.html .

I echo Ed's request - could someone at Apple look at these radars, and open
llvm bugs for the ones that aren't Darwin-only?


Ed's message:

I was recently looking at an unexpected pass test result on FreeBSD[1]
which is decorated with expectedFailureAll referencing
rdar://problem/24599697. I'm looking for more details on this specific
radar bug report in order to determine if the test is not exercising
the original bug on FreeBSD, or if it's really an Apple-only issue.

As it's rather unfortunate to have a bug report reference for which no
further public details are available I looked at other radar
references in the test suite, and found 118 of them. Many of these are
in comments, in macosx-specific cases (e.g.
@expectedFailureAll(oslist=["macosx"], bugnumber="rdar://28805064")),
or in tests decorated with skipUnlessDarwin, and I've ignored those.

There are 10 tests with expected failure decorators, and one skipped,
that apply beyond macosx and reference a radar (and do not
additionally reference an LLVM PR). Can someone at Apple check these
radar references and submit LLVM PRs, reference existing PRs, add a
reasonable description in the test source, etc. as appropriate?

functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScop
e.py
unittest2.expectedFailure("rdar://problem/18685649")

functionalities/asan/TestReportData.py
@expectedFailureAll(archs=['i386'], bugnumber="rdar://28658860")

api/multiple-debuggers/TestMultipleDebuggers.py
@expectedFailureAll(bugnumber="rdar://30564102")

lang/objc/bitfield_ivars/TestBitfieldIvars.py
decorators.expectedFailureAll(bugnumber="rdar://problem/17990991")])

lang/c/shared_lib/TestSharedLib.py
@unittest2.expectedFailure("rdar://problem/10704639")

lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py
@unittest2.expectedFailure("rdar://problem/10381325")

lang/cpp/stl/TestSTL.py
@expectedFailureAll(bugnumber="rdar://problem/10400981")

lang/cpp/dynamic-value/TestCppValueCast.py
@unittest2.expectedFailure("rdar://problem/10808472 SBValue::Cast test
case is failing (virtual inheritance)")

lang/cpp/printf/TestPrintf.py
decorators.expectedFailureAll(bugnumber="rdar://problem/24599697")])

lang/cpp/function-template-parameter-pack/TestFunctionTemplateParameterPack.
py
decorators.expectedFailureAll(bugnumber="rdar://problem/32096064")])

lang/cpp/unique-types/TestUniqueTypes.py
self.skipTest("rdar://problem/9173060 lldb hangs while running
unique-types for clang version < 3")

[1]
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20170807/036634.htm
l

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Command history line editing

[Ted Woodward via lldb-dev]

There is - editline.

 

http://thrysoee.dk/editline/

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: William Schmidt [mailto:t.william.schm...@gmail.com] 
Sent: Wednesday, March 07, 2018 1:34 PM
To: paul.robin...@sony.com
Cc: ted.woodw...@codeaurora.org; jan.kratoch...@redhat.com; 
lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Command history line editing

 

readline has been around for donkeys' years. I was hacking it in MKSToolkit 
back in the nineties. That implementation had a bug that hosed the debugger's 
command line and a shell work-around to resolve it. Presumably, there must be a 
clean-room version of readline somewhere that does not use GPL? bash owns the 
command line so applications should mimic its behavior, or at least offer a 
user-selectable option. Say, either emacs or vi editing modes, as bash itself 
does.

 

Will








 

On Wed, Mar 7, 2018 at 11:53 AM, <paul.robin...@sony.com 
<mailto:paul.robin...@sony.com> > wrote:

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
> <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 editing
>
> It's not just Apple that avoids GPL. Many LLVM users cannot use GPL.
> Adding GPL code to LLDB is a non-starter.

License questions need to be cleared with the LLVM Foundation.
But my non-lawyer understanding is no GPL.
--paulr

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Command history line editing

[Ted Woodward via lldb-dev]

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: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jan
> Kratochvil via lldb-dev
> Sent: Wednesday, March 07, 2018 3:20 AM
> To: William Schmidt 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Command history line editing
> 
> On Sun, 04 Mar 2018 21:03:26 +0100, William Schmidt via lldb-dev wrote:
> > lldb deserves an editing mode functionally equivalent to what bash offers.
> > And since bash is open-source, it should just be a matter of grabbing
> > the bash source that implements command line editing and going from there.
> 
> It is because lldb uses libedit while bash (and gdb) use readline.
> 
> I guess it has licensing reasons as readline is GPL (not LGPL) and Apple 
> seems to
> avoid GPL the family of licenses.  IANAL but I think an alternative linking 
> with
> readline while keeping the libedit compatibility still in place would not 
> taint
> LLDB by the GPL license.  And then OSes (such as Linux or for OSX is it
> Homebrew?) already using GPL software could link LLDB with readline.
> 
> 
> Jan
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 shows up occasionally on our buildbot runs, on different tests. I've
never seen it when running locally.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 need some general way to skip the build for
systems that can't build a given testcase. I have many tests skipped when
running without an OS, because we don't support c++11 in that mode.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

> -Original Message-
> From: apra...@apple.com [mailto:apra...@apple.com]
> Sent: Friday, February 23, 2018 2:47 PM
> To: Ted Woodward 
> Cc: Pavel Labath 
> Subject: Re: problem with TestLoadUnload.py
> 
> 
> 
> > On Feb 23, 2018, at 12:08 PM, Ted Woodward
>  wrote:
> >
> > Hi Adrian,
> >
> > In r324368 you changed TestLoadUnload.py to do a build in the setUp
> > function. This seems to be called before the actual testcases are
> > checked, so a skipped testcase would still call setUp and do the
> > build. If the build fails (say, on systems that don't have libgen.h),
> > the test errors out before it can be skipped.
> >
> > Would you mind moving the build into each testcase?
> 
> +Pavel
> 
> I'm afraid that would cause quite a performance degradation in the case
where
> the test is not skipped wince we then need to build the test once for each
test
> function. On the other hand since Pavel's change to run each test function
in
> parallel we are presumably building the test once per test function
anyway, so
> this should not be any more expensive.
> 
> That said, I wonder if the right solution for your problem wouldn't be to
not run
> setUp if the test depending on it is skipped.
> 
> (Do you mind if I add lldb-dev to the CC list?)
> 
> -- adrian
> 
> > Thanks,
> >
> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
> >


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] display register fields?

[Ted Woodward via lldb-dev]

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 Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 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 lldb-dev
Sent: Wednesday, January 17, 2018 4:31 PM
To: Adrian Prantl 
Cc: LLDB 
Subject: Re: [lldb-dev] Questions about the LLDB testsuite and improving its 
reliability

 

I don't think new test authors really need to add CMake any more so than they 
currently need to understand Make.  Which is to say, not very much.  Most 
Makefiles are currently 1-2 lines of code that simply does nothing other than 
include the common Makefile.

 

On the other hand, CMake defines a lot of constructs designed to support 
portable builds, so actually writing and maintaining that common CMake build 
file would be much easier.  The existing Makefile-based system already doesn't 
require you to understand the specific compiler invocations you want.  Here's 3 
random Makefiles, which is hopefully representative given that I pulled them 
completely at random.

 

breakpoint-commands/Makefile:

LEVEL = ../../../make

CXX_SOURCES := nested.cpp

include $(LEVEL)/Makefile.rules

 

functionalities/inferior-assert:

LEVEL = ../../make

C_SOURCES := main.c

include $(LEVEL)/Makefile.rules

 

 

types:

LEVEL = ../make

# Example:

#

# CXX_SOURCES := int.cpp

include $(LEVEL)/Makefile.rules

 

None of this is particularly interesting.  There are a very few tests that need 
to do something weird.  I opened 10 other random Makefiles and still didn't 
find any.  I don't believe it would be hard to support those cases.

 

So now instead of "understand Make" it becomes "understand CMake".  Whic is 
already a requirement of building LLVM.

 

If our test suite was lit-based where you actually had to write compiler 
invocations into the test files, I would feel differently, but that isn't what 
we have today.  We have something that is almost a direct mapping to using 
CMake.

 

On Wed, Jan 17, 2018 at 2:22 PM Adrian Prantl  > wrote:



> On Jan 17, 2018, at 1:45 PM, Vedant Kumar   > wrote:
>
> I would prefer having all of our test dependencies tracked by CMake for all 
> the reasons Zach brought up, but I think we should defer that undertaking 
> until after the bots are more stable. We have some immediate problems caused 
> by stale in-tree test artifacts. As a first milestone, it'd be great to not 
> have to run `git clean -fdx` anymore.

I'm pretty sure I do not want to go all the way to CMake right now, but I am 
curious about your motivation: Why do you think that using CMake to build the 
tests in the testsuite is a good idea? In my opinion this adds a layer of 
complexity to the tests that makes it harder to understand what exactly is 
happening and test authors now need to understand CMake *and* the compiler 
invocations they want to execute in their tests. Do you also share Zachary's 
point of view that the tests should be build artifacts that should be kept 
after an incremental build?

-- adrian

>
>
>> On Jan 17, 2018, at 1:13 PM, Davide Italiano via lldb-dev 
>>  > wrote:
>>
>> On Wed, Jan 17, 2018 at 1:02 PM, Davide Italiano >  > wrote:
>>> On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev
>>>  > wrote:
 Hi lldb-dev!

 I've been investigating some spurious LLDB test suite failures on 
 http://green.lab.llvm.org/green/ that had to do with build artifacts from 
 previous runs lying around in the test directories and this prompted me to 
 ask a couple of general noob questions about the LLDB testsuite.

 My understanding is that all execution tests are compiled using using 
 `make` in-tree. I.e.: the test driver (dotest.py) effectively executes 
 something equivalent to `cd $srcdir/packages/.../mytest && make`. And it 
 does this in a serial fashion for all configurations (dwarf, dSYM, dwo, 
 ...) and relies on the `clean` target to be implemented correctly.

 I don't understand all the design decisions that went into the LLDB 
 testsuite, but my naive intuition tells me that this is sub-optimal 
 (because of the serialization of the configurations) and dangerous 
 (because it relies on make clean being implemented correctly). It seems to 
 me that a better approach would be to create a separate build directory 
 for each test variant 

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

[Ted Woodward via lldb-dev]

> -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 case of
> type names inequality in DWARF and mangled symbols
> 
> 
> Modifying llvm-dsymutil to handle ELF so we can use "llvm-dsymutil --update
> foo.elf" is the quickest way that doesn't involve modifying anything but llvm-
> dsymutil. It will generate the accelerator tables manually and add/modify the
> existing accelerator tables and write out the new elf file that is all fixed 
> up. I
> would suggest going this route at first to see what performance improvements
> we will see with linux so that can drive how quickly we need to adopt this.

I like this. The question is - has everything we need in llvm-dsymutil been 
upstreamed by Apple?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 /usr/bin/lldb-3.8 -> 
../lib/llvm-3.8/bin/lldb*
0 lrwxrwxrwx 1 root root 30 Jul 18 11:06 /usr/bin/lldb-3.8.0-3.8 -> 
../lib/llvm-3.8/bin/lldb-3.8.0*
0 lrwxrwxrwx 1 root root 24 Aug 23 17:50 /usr/bin/lldb-server -> 
/usr/bin/lldb-server-3.8*
0 lrwxrwxrwx 1 root root 31 Jul 18 11:06 /usr/bin/lldb-server-3.8 -> 
../lib/llvm-3.8/bin/lldb-server*

--
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 Pavel
> Labath via lldb-dev
> Sent: Monday, November 27, 2017 5:32 AM
> To: Jeremiah 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu
> 
> I think that's a question for your distro's (or ubuntu's) lldb package 
> maintainer. I
> think they probably have some custom patches there (if they don't then they
> probably need them). If I'm not mistaken vanilla lldb does not even support
> multiple lldb instalations side-by-side (i.e., it will always search for 
> "lldb-
> server", with no suffix).
> 
> As a workaround, you may be able to get this working by setting the
> LLDB_DEBUGSERVER_PATH environment variable to point to the right
> executable.
> 
> On 26 November 2017 at 06:04, Jeremiah via lldb-dev  d...@lists.llvm.org> wrote:
> > On my Pop!_OS machine (which is based on Ubuntu 17.10), using any
> > version of LLDB above 3.8 gives me the error "process launch failed:
> > unable to locate lldb-server-x.x.x" but when version 3.8 is installed,
> > it works just fine.
> >
> > There are various posts across the web about the same problem on
> > multipler versions of Ubuntu. The most common solution presented is to
> > use update-alternatives, but that did not solve the problem for me. I
> > also checked my bin directories and the binaries for lldb-server are
> > there for any version I install.
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] SB Headers not in install?

[Ted Woodward via lldb-dev]

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

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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-boun...@lists.llvm.org] On Behalf Of Don Hinton 
via lldb-dev
Sent: Tuesday, November 07, 2017 12:28 PM
To: Jim Ingham 
Cc: LLDB 
Subject: Re: [lldb-dev] Bot failure with new "in tree compiler" changes 
(r316728) in llvm.org bot

 

I hit the same problem last week.  I ended up blowing away my build directory, 
and the problem went away.  

 

Probably a cache issue, but I was unable to reproduce...

 

On Tue, Nov 7, 2017 at 10:21 AM, Jim Ingham via lldb-dev 
 > wrote:

The lldb_cmake GreenDragon bot is now failing, e.g.:

http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e

This looks related to Pavel's change:

> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines
>
> Default to using in-tree clang for building test executables
>
> Summary:
> Using the in-tree clang should be the default test configuration as that
> is the one compiler that we can be sure everyone has (better
> reproducibility of test results). Also, it should hopefully reduce the
> impact of pr35040.
>
> This also reduces the number of settings which control the compiler
> used. LLDB_TEST_C_COMPILER is used for C files and
> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
> the in-tree clang.
>
> Reviewers: zturner
>
> Subscribers: mgorny, davide, lldb-commits
>
> Differential Revision: https://reviews.llvm.org/D39215
>

The error is:

CMake Error at tools/lldb/CMakeLists.txt:78 (message):

  LLDB test compilers not specified.  Tests will not run


Does the bot need to be reconfigured for these changes?

Jim

___
lldb-dev mailing list
lldb-dev@lists.llvm.org  
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Davide
> Italiano via lldb-dev
> Sent: Friday, October 27, 2017 2:46 PM
> To: Pavel Labath 
> Cc: LLDB 
> Subject: Re: [lldb-dev] check-lldb will start using in-tree clang by default
> 
> So, I wiped out my directory for the build and then I created it again using
> cmake -GNinja ../
> 
> I found out what the bug/problem is, BTW (was going to reply to this e-mail 
> but
> you've beaten me to the punch).
> You switched LLDB to build with an in-tree clang, but ninja check-lldb doesn't
> really require clang to be built.
> As such, once I cleaned up my checkout, I ended up typing just `ninja 
> check-lldb`
> and that failed because clang wasn't built.
> I claim that `ninja check-lldb` should list clang as dependency when we're
> running the tests with the in-tree clang.
> WDYT?
> 
> Thanks!
> 
> --
> Davide
> 
> 
> 
> On Fri, Oct 27, 2017 at 12:41 PM, Pavel Labath  wrote:
> > Did you clean your cmake cache before runinng this? Does
> > '/home/davide/work/build-lldb/bin/clang' correctly refer to a clang
> > binary you just built?
> >
> > On 27 October 2017 at 12:39, Davide Italiano 
> wrote:
> >> Yes, it seems `configuration.compiler` is None, so this explodes:
> >>
> >> [...]
> >> if not is_exe(configuration.compiler):
> >>
> >> [...]
> >>
> >> On Fri, Oct 27, 2017 at 12:37 PM, Davide Italiano 
> wrote:
> >>> I think that this change (or some change nearby) broke `check-lldb` on
> Fedora.
> >>>
> >>> I'm investigating, but in the meanwhile, here's the log.
> >>>
> >>> $ ninja check-lldb
> >>> [2/2] Testing LLDB (parallel execution, with a separate subprocess
> >>> per test) Traceback (most recent call last):
> >>>   File "/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py", line
> >>> 7, in 
> >>> lldbsuite.test.run_suite()
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py",
> >>> line 1099, in run_suite
> >>> parseOptionsAndInitTestdirs()
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py", line 282, in parseOptionsAndInitTestdirs
> >>> if not is_exe(configuration.compiler):
> >>>   File
> >>> "/home/davide/work/llvm-lldb/tools/lldb/packages/Python/lldbsuite/te
> >>> st/dotest.py",
> >>> line 54, in is_exe
> >>> return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
> >>>   File "/usr/lib64/python2.7/genericpath.py", line 37, in isfile
> >>> st = os.stat(path)
> >>> TypeError: coercing to Unicode: need string or buffer, NoneType
> >>> found
> >>> FAILED: cd /home/davide/work/build-lldb/tools/lldb/test &&
> >>> /usr/bin/python2.7
> >>> /home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q
> >>> --arch=x86_64 --executable /home/davide/work/build-lldb/bin/lldb -s
> >>> /home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u
> >>> CFLAGS -C /home/davide/work/build-lldb/bin/clang --env
> >>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
> >>> ninja: build stopped: subcommand failed.
> >>>
> >>> On Thu, Oct 26, 2017 at 7:18 PM, Pavel Labath via lldb-dev
> >>>  wrote:
>  I am going to check in a change (D39215) which causes the
>  check-lldb target to use the just-built clang for compiling the
>  test inferiors (instead of the system compiler, which was the old
>  default). The main reason for this is to provide better
>  reproducibility of test results between different
>  machines/developers, by removing one of the main sources of
>  nondeterminism. This behavior can be overridden by setting the
> LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER cmake variables.
> 
>  For the change to take effect you will need to clean your build
>  folder (or at least, remove the affected variables from your
> CMakeCache.txt).
>  After this you may observe a change in the test results from the
>  check-lldb run.
> 
>  Note that this change only affect cmake code -- if you run your
>  tests by running dotest.py directly, nothing will change for you.
> 
>  regards,
>  pavel
>  ___
>  lldb-dev mailing list
>  lldb-dev@lists.llvm.org
>  http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 extension [-Werror,-Wgnu-anonymous-struct]
  struct {
  ^
/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 types declared in an anonymous union are an extension
[-Werror,-Wnested-anon-types]


The patch is to handle new MacOS 10.13 internal layouts. Could someone at
Apple please clean this up?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

 

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 Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of meister 
via lldb-dev
Sent: Tuesday, August 29, 2017 1:41 PM
To: clayb...@gmail.com
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Linking the lldb C++API/library with other projects

 

Greg,

 

We are developing a compiler for Common Lisp that uses LLVM as the backend and 
interoperates with C++ - it has its own REPL and built in compiler.   

Our compiler generates llvm-ir that we link directly with llvm-ir generated 
from the C++ code using LTO.

I’ve exposed much of the LLVM C++ API and Clang ASTMatcher C++ API for 
automatic analysis and refactoring of our C++ code.

 

The Python API’s are not that useful to us.   

Although - maybe launching lldb as a separate process to get the backtrace with 
a python script may be a reasonable thing to do - if that’s all that I want to 
do.

I’d also like to explore accessing lexical variables and setting breakpoints 
and watchpoints using the C++ API.

The C++ API’s - they are much more straightforward to work with for us.

 

I am already using ‘backtrace’ - but I don’t get function arguments with that 
sadly.

 

Best,

 

.Chris.

 

 

 

 

On Aug 29, 2017, at 2:30 PM, Greg Clayton  > wrote:

 

 

On Aug 29, 2017, at 11:17 AM, meister  > wrote:

 

Dear Greg,

Thank you very much for your detailed and thoughtful response.

A couple of followup questions based on what you said:

(1)  You say: "since LLDB can't be used to backtrace itself…"
Do I (a) need to fork another process and call the LLDB API’s to get backtraces 
for the original process or (b) can I simply create another thread and call 
LLDB API’s to interogate other threads using the SBThread API?  Or can I do 
both of these?

 

You can do the first, not the second. LLDB attaches to processes via ptrace 
which means it will suspend all threads in the process it is attaching to, so 
you can't do this to yourself. Forking another process will do the trick. You 
can also do all of this from Python! The entire LLDB API is exposed to python 
and python can be used on the command line from a python script, or from within 
LLDB itself by using the "script" command which drops you into an embedded 
python interpreter.  On Mac, if you know Xcode is installed, you can just run a 
python script to do what you need. Let me know if this sounds interesting. On 
linux, you could use the installed lldb to do the backtraces using a python 
script as well.






(2) When you say "so if you are looking to backtrace things in your current 
process you should probably use other APIs.”
By "other APIs” do you mean other SB class API’s like SBThread? or do you 
mean other API’s entirely? If the latter could you give an example?

 

Other APIs not in LLDB if you must stay in process:

 

$ man backtrace

 

If you launch another process, it will be able to backtrace your current 
process and you can use LLDB's APIs.

 


(3) If I call LLDB from my code like this - how would you recommend 
distributing this?

(a) When building from source should I have the build system pull lldb from a 
the llvm github repo?

 

You might think about locking onto they latest public release of lldb. This 
might be more stable than just grabbing top of tree.





(b) Can I ship the lldb framework on OS X and lldblib.so (LInux) with my binary 
release?

 

Yes. You might think about using python and just using the installed LLDB? 





(c) On OS X - can I use the builtin lldb library? I haven’t checked if header 
files are available.

 

Header files are not available, but our API is stable. You could theoretically 
link against the top of tree LLDB.framework and tell it to use the system 
version (in /Applications/Xcode.app/Contents/SharedFrameworks, or somewhere for 
linux)





(d) On Linux - can I use package manager installed versions of lldb? 

 

Yes. If you go this route, I would suggest using a python script. Then you 
don't even need to link against lldb! 






For some of these I realize that I'll have to do some legwork to figure out 
what is available from package managers etc.

(4) Since I have to debug from a separate process does the following sound 
reasonable.
(i) My program detects an error and enters into its debugger.
(ii) It forks a debugging process and that interacts with the user who uses it 
to debug the main process.
(iii) The debugger process shuts down and the main process continues.

I’d be doing this from within a Common Lisp programming environment called 
SLIME in Emacs - I have no idea right now if it’s possible to have the 

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

[Ted Woodward via lldb-dev]

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
var_update_test(void)
{
struct complex_type complx_array[2];

complx_array[0].i = 4;
complx_array[0].inner.l = 4;
complx_array[0].complex_ptr = _array[1];
complx_array[1].i = 5;
complx_array[1].inner.l = 5;
complx_array[1].complex_ptr = _array[0];
 


the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into an
infinite loop.

  const MIuint nChildren = vrwValue.GetNumChildren();
  for (MIuint i = 0; i < nChildren; ++i) {
lldb::SBValue member = vrwValue.GetChildAtIndex(i);
if (!member.IsValid())
  continue;

if (member.GetValueDidChange()) {
  vrwbChanged = true;
  return MIstatus::success;
} else if (ExamineSBValueForChange(member, vrwbChanged) && vrwbChanged)
  // Handle composite types (i.e. struct or arrays)
  return MIstatus::success;
  }

I've got a patch that disables checking a pointer's children. I'll put it up
on phabricator today.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 debugserver launch, and get:

> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port

That log message comes right after the pipe read, which succeeds because 
error.Success() is true:

// Read port from pipe with 10 second timeout.
error = socket_pipe.ReadWithTimeout(
port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
if (error.Success() && (port != nullptr)) {
  assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
  uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
  if (*port == 0 || *port == child_port) {
*port = child_port;
if (log)
  log->Printf("GDBRemoteCommunication::%s() "
  "debugserver listens %u port",
  __FUNCTION__, *port);

As an aside, I don't like that assert - if we get garbage back from the pipe, 
we should error out, not take down lldb.

Another aside, the definition of port_cstr is odd:
char port_cstr[PATH_MAX] = {0};
port_cstr[0] = '\0';
The size is way to big - max port number is 65535, so we don't need PATH_MAX 
bytes. And 2 assignments to make it a null string?


Ramana, can you stick in a log message to print port_cstr? I suspect it's 
actually getting 0 back from lldb-server, which would tell us the error is in 
the server code, not the client code.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: Ramana [mailto:ramana.venka...@gmail.com]
> Sent: Thursday, August 24, 2017 4:00 AM
> To: Ted Woodward 
> Cc: Greg Clayton ; Hans Wennborg
> ; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
> 
> Greg, Ted
> 
> Thanks for your comments.
> 
> On Thu, Aug 24, 2017 at 12:01 AM, Ted Woodward
>  wrote:
> >
> > 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. StartDebugServerProcess
> launches the gdbserver with a named pipe, and reads the actual port from the
> pipe.
> 
> Yes, the port list is empty unless --(min/max)-gdbserver-port is specified and
> the gdbserver reads port number from the named pipe which in the failing case
> is zero.
> 
> > I suggest turning on more logging - specifically, "gdb-remote process". 
> > That's
> the channel used in StartDebugServerProcess.
> >
> 
> In fact I have given the relevant log line of "gdb-remote process" in the bug
> details reporting port zero. Anyhow, the full log of "gdb-remote process" for
> both lldb v4.0.1 and v5.0.0 is given at the bottom of my reply.
> 
> I thought https://reviews.llvm.org/rL295947 (Ensure lldb-server waits for 
> child
> debug servers to start up when passing them) got something to do with this bug
> but both reversing
> 
> if (pass_comm_fd == -1) {   at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1086
> 
> to original
> 
>if (pass_comm_fd == -1 && ((port != nullptr && *port == 0) || port ==
> nullptr)) {
> 
> and
> 
> increasing the time out to 30 sec from 10 sec in
> socket_pipe.ReadWithTimeout()at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1255
> 
> did not solve the issue.
> 
> By the way, the remote debugging of x86 (linux) from x86 (linux) with lldb
> v5.0.0 (but works with v4.0.1) also fails with assertion
> 
> assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');  at
> source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1258
> 
> due to the reason that socket_pipe.ReadWithTimeout() could not successfully
> read the port number from the named pipe.
> 
> Based on the above, though I am not sure, the other patch I could think of
> having an effect on this bug is
> https://reviews.llvm.org/rL300579 (Update LLDB Host to support IPv6 over TCP)
> which changed the socket implementation.
> 
> 
> lldb-server log for "gdb-remote process" with lldb v4.0.1 (passing case)
> 
> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0,
> port=0)
> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote stub
> exe '/mnt/var/binaries/arm_release/bin/lldb-server'
> launch info for gdb-remote stub:
> Executable: lldb-server
> Triple: *-*-*
> Arguments:
> argv[0]="/mnt/var/binaries/arm_release/bin/lldb-server"
> argv[1]="gdbserver"
> 

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

[Ted Woodward via lldb-dev]

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. StartDebugServerProcess 
launches the gdbserver with a named pipe, and reads the actual port from the 
pipe.

I suggest turning on more logging - specifically, "gdb-remote process". That's 
the channel used in StartDebugServerProcess.

--
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 Greg
> Clayton via lldb-dev
> Sent: Wednesday, August 23, 2017 12:45 PM
> To: Hans Wennborg 
> Cc: Ramana ; LLDB Dev  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
> 
> Port zero should never be returned as a valid port. We do bind to port zero 
> just
> so we don't try and pick a port at random just to find it is being used. When 
> we
> bind to port 9, we must find the actual port we bound to and return that. 
> Seems
> something has gone wrong with the code that discovers the port that was
> actually bound and is not reporting that back correctly.
> 
> 
> Should be straight forward to do by debugging the function
> GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer(...) in
> GDBRemoteCommunicationServerPlatform.cpp and see what is going on and
> why it is returning 0 as the port.
> 
> Greg
> 
> > On Aug 23, 2017, at 9:44 AM, Hans Wennborg via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > This was marked as an lldb 5.0.0 release blocker since it's a
> > regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183
> >
> > lldb-dev: Is there any interest in fixing this bug?
> >
> > On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev
> >  wrote:
> >> Hi,
> >>
> >> I am trying to remote debug ARM (linux) target from x86 (linux) host
> >> and I am getting the following error while trying to launch a process.
> >> The local debugging on ARM works.
> >>
> >> error: connect remote failed (invalid host:port specification:
> >> '10.10.2.3')
> >> error: process launch failed: invalid host:port specification: '10.10.2.3'
> >>
> >> It appears the above error is because the gdb-remote is returning the
> >> communication port as zero.
> >>
> >> <  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
> >> <  19> read packet: $pid:298;port:0;#bf
> >>
> >> What are the possible reasons for the above behavior from gdb-remote
> >> and how I could resolve this?
> >>
> >> If it helps, below is the full log.
> >>
> >> (lldb) log enable lldb comm
> >> (lldb) log enable gdb-remote packets
> >> (lldb) platform select remote-linux
> >>  Platform: remote-linux
> >> Connected: no
> >> (lldb) platform connect connect://10.10.2.3:500
> >> 0x915bd78 Communication::Communication (name = gdb-remote.client)
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
> >> Socket::TcpConnect (host/port = 10.10.2.3:500) TCPSocket::Connect
> >> (host/port = 10.10.2.3:500)
> >> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
> >> us, connection = 0x0915F578
> >> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
> >> flags = 0) => 19 (error = (null))
> >> history[1] tid=0x7cbf <   1> send packet: +
> >> <  19> send packet: $QStartNoAckMode#b0 this = 0x0915BD78, dst =
> >> 0xBFCB51AC, dst_len = 8192, timeout = 600 us, connection =
> >> 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
> >> flags = 0) => 7 (error = (null))
> >> <   1> read packet: +
> >> <   6> read packet: $OK#9a
> >> 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13,
> >> flags = 0) => 13 (error = (null)) <  13> send packet: $qHostInfo#9b
> >> this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout =
> >> 100 us, connection = 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len =
> >> 316, flags = 0) => 316 (error = 

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

[Ted Woodward via lldb-dev]

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 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 Greg
Clayton via lldb-dev
Sent: Tuesday, August 22, 2017 6:20 PM
To: Vadim Chugunov 
Cc: LLDB 
Subject: Re: [lldb-dev] Forcing lldb to refresh process state

 

You need to send some sort of continue through the GDB remote interface. The
only way to get a $T packet back is in response to a "?" packet or to a
"vCont" or other continue or step packet.

 

On Aug 22, 2017, at 2:30 PM, Vadim Chugunov  > wrote:

 

It does send '$T05...' in response, but it looks like lldb does not analyze
responses to manually sent packets.

 

On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton  > wrote:

If you do a reverse step it actually should send a process resumed and a
process stopped event.

> On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev  > wrote:
>
> I'm trying to reverse-step.  So I think I'd need to refresh all thread
states?
>
>> On Aug 18, 2017, at 4:50 PM, Jim Ingham  > wrote:
>>
>> No, there hasn't been a need for this.
>>
>> What commands are you planning to send?  Or equivalently, how much state
are you expecting to change?
>>
>> Jim
>>
>>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev
 > wrote:
>>>
>>> Hi,
>>> Is there any way to force lldb to refresh it's internal record of
debuggee process state (as if it had just received a stop event)?  I want to
send a custom command to remote gdb process stub (via `process plugin packet
send`).  This works, but if the command alters debuggee state, lldb won't
know about it.
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org  
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org  
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

 

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 Bugzilla at http://bugs.llvm.org .

Ted

--
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 Hafiz
> Abid Qadeer via lldb-dev
> Sent: Monday, July 31, 2017 5:04 AM
> To: Eli Zaretskii ; Zachary Turner ; Jan
> Kratochvil ; Eli Zaretskii via lldb-dev  d...@lists.llvm.org>
> Cc: yllumin...@gmail.com
> Subject: Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
> 
> 
> >>> Last time I tried, it wasn't "reasonable" enough to start debugging
> >> a
> >>> program under Emacs.  See this discussion for details:
> >>>
> >>> http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html
> >>>
> >>> The failed commands it shows are the initial ones issued by Emacs
> >>> when a debugging session starts.  Without support of these commands
> >> in
> >>> lldb-mi there's no hope for any
> >>> practical debugging using lldb.
> >>> If llvm developers could implement those minimal commands, maybe
> the
> >>> rest would be easier.
> 
> I will try to add those command when my time allows. If there are others that
> are needed to make Emacs work then please let me know or better open a
> bug.
> 
> Thanks,
> Abid
> 
> --
> Hafiz Abid Qadeer
> Mentor Embedded/CodeSourcery
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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

 

From: Demi Obenour [mailto:demioben...@gmail.com] 
Sent: Friday, July 21, 2017 8:54 PM
To: Ted Woodward ; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Trying to use socketpair for lldb-server fails

 

Sadly, that gives me nothing in the log file.  Also, 
ConnectionFileDescriptor::Connect already seems to handle this case.

 

Running strace on all child processes gives a “Operation not permitted” error 
from setsid().  That seems like the culprit, which is strange.

 

Would you mind providing the value you used for LLDB_SERVER_LOG_CHANNELS?

 

Demi

 

On Fri, Jul 21, 2017 at 2:55 PM Ted Woodward  > wrote:

The first thing I'd do is use the lldb logging mechanism. lldb-server closes
its own stdout and stderr, because nobody is interested in output from the
server, just from the target. Except when you're debugging the server, so
there is an easy way to turn on logging.

Set the following environment variables:
LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will
be written to
LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn
logging on for. The format is "channel category:channel category...". If you
want more than 1 category for a channel, I think "channel cat1 cat2..."
works. This is not spelled out very clearly, unfortunately.


Quickly glancing at the code, it looks like you need to implement a
socketpair connection, and handling of the fd:// connection URL, starting in
ConnectionFileDescriptor::Connect. The log for this would be "lldb
connection".

Ted

--
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 Demi
> Obenour via lldb-dev
> Sent: Wednesday, July 19, 2017 7:44 PM
> To: lldb-dev@lists.llvm.org  
> Subject: [lldb-dev] Trying to use socketpair for lldb-server fails
>
> To avoid a local privilage escalation, I am trying to patch LLDB not to
use a TCP
> socket for local communication.
>
> The attached patch failed.  Would anyone be able to provide suggestions
for
> how to debug the problem?
>
> Sincerely,
>
> Demi

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

I’ve seen crashes on Linux when building with 2.7.6 and using the 2.7.3 
.so/library directory, so I’m not willing to say building on Windows with 3.6.1 
and using the 3.5.2 dll/library directory will work. Python has never been very 
forgiving when using a different setup than what you built with.

 

My point with that statement is you’ve got to make sure the runtime environment 
matches the build environment, something harder to do on Windows where there is 
no default runtime environment.

 

--

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: Friday, June 30, 2017 3:05 PM
To: Ted Woodward <ted.woodw...@codeaurora.org>; Jamie Madill 
<nul...@gmail.com>; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Python 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 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 (which 
contains dlls/sos) than what was used when building lldb. 

This is no longer true right?  That was one of the major drivers behind moving 
to Python 3.5.  All that matters is 

 

a) The build configuration matches (if LLDB was built against Python debug, you 
must have debug libraries available)

b) The architecture matches (if it's an x64 build of LLDB, you need x64 Python 
libraries)

c) The version is 3.5 or higher.

 

Aside from that it shouldn't matter

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 (which 
contains dlls/sos) than what was used when building lldb. MacOS and various 
Linux distros ship with a fixed version of python, so lldb can be built with 
that version. Windows doesn’t have a default python, so you need to make sure 
that your user has the same version of python that lldb was built with.

 

For the Hexagon tools, we ship the python dll/so and the library directory that 
we built with. We use 3.5.1 on Windows, and 2.7.8 on Linux. On Linux, we set 
RPATH to ../lib, so lldb/liblldb.so can find libpython.so. On both, we set a 
cmake variable LLDB_DEFAULT_PYTHONHOME, and use it when initializing python to 
point lldb to the path where our python library is installed. This code isn’t 
upstreamed, but I can upstream it if the community would like it.

 

Another issue on Windows is the python installation integrity check in 
cmake/modules/LLDBConfig.cmake. It checks to see if python is installed 
correctly like 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 1 PARENT_SCOPE)

return()

  endif()

 

 

If you don’t have the debug version of python installed (as is the case on our 
builders), this check will fail, and python will be turned off. Internally, I 
break this check up into debug and release checks, based on the value of 
CMAKE_BUILD_TYPE. I also don’t check for the release dll, because our builders 
don’t have that.  I can also upstream this if the community is interested.

 

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-boun...@lists.llvm.org] On Behalf Of Jamie 
Madill via lldb-dev
Sent: Thursday, June 29, 2017 10:30 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Python scripting in Windows LLDB

 

A ping for this regression - Ted Woodward seems to have had a patch for fixing 
broken Windows scripting support but the 5.0.0 snapshot release didn't have the 
fix. Is it possible to land that patch for the next snapshot?

 

This is currently breaking LLDB Visual Studio Code integration on Windows (for 
context, see https://github.com/vadimcn/vscode-lldb/issues/37 .)

 

Thanks!

Jamie

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 
should always be optional.

--
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 Pavel
> Labath via lldb-dev
> Sent: Wednesday, June 21, 2017 11:41 AM
> To: Ravitheja Addepally 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Support for Error Strings in remote protocol
> 
> +1 one from me. I like the idea a lot. Specific details below.
> 
> On 21 June 2017 at 16:31, Ravitheja Addepally via lldb-dev  d...@lists.llvm.org> wrote:
> > Hello all,
> >Currently the remote protocol in LLDB does not allow sending
> > Error Strings in response to remote packets, it only allows for "ENN"
> > format where N is a hex integer. In our current ongoing work, we would
> > like to have support for Sending Error Strings from lldb-server. I
> > would like to invite any opinions or suggestions in this matter ?
> >
> > A very simple proposal would be to just attach an error string maybe
> > as a Name:Value Pair ? like so ->
> >
> > EXX;"Error String"
> >  or
> > EXX;M"Error String"
> 
> I guess the decision here depends on how forward-compatible we want to
> be. If we don't anticipate adding further fields here, then the format can 
> just
> be EXX;message and no quoting is needed. If we want to add more fields in
> the future (I don't really see what could they be though), then we should
> stick to the standard semi-colon delimited list  format. So, something like:
> EXX;message:
> But then we need to decide how to encode . I guess the most
> "standard" approach would be to hex-encode it, although it will make them
> hard to read manually.
> 
> >
> > I guess removing EXX would make it incompatible with gdb-server. Also
> > adding new packets to query errors might not be desired ?
> I think we should keep the numeric codes. Sometimes it may be useful to
> programmatically switch on them, and that's hard to do with a string only. For
> compatibility's sake, I'd only send the error messages if the client 
> explicitly
> enables it via some packet.
> 
> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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, 2, 3, 4};
  int foo = 0;
  int *bar = 
  int i = 0;

  for (i = 0; i < 4; i++)
*bar += vec[i];

  return foo;
}

Commands:
-break-insert -t -f test.c:10
-break-insert -t -f test.c:13
-exec-run
-var-create --thread 1 --frame 0 - * bar
-var-list-children var0
-var-evaluate-expression var0.*bar
-exec-continue
-var-update 1 var0
-var-evaluate-expression var0.*bar


Output:
(gdb)
-var-create --thread 1 --frame 0 - * bar
^done,name="var0",numchild="1",value="0x7fffed30",type="int
*",thread-id="1",has_more="0"
(gdb)
-var-list-children var0
^done,numchild="1",children=[child={name="var0.*bar",exp="*bar",numchild="0"
,type="int",thread-id="1",has_more="0"}],has_more="0"
(gdb)
-var-evaluate-expression var0.*bar
^done,value="0"

***Value is 0

(gdb)
-exec-continue
^running
(gdb)
=thread-exited,id="1",group-id="i1"
(gdb)
*running,thread-id="all"
(gdb)
=thread-created,id="1",group-id="i1"
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={level="0",addr
="0x00400530",func="main",args=[],file="test.c",fullname="/local/scr
atch/ted/tip/newfull/test.c",line="13"},thread-id="1",stopped-threads="all"
(gdb)
-var-update 1 var0
^done,changelist=[]

***No changes

(gdb)
-var-evaluate-expression var0.*bar
^done,value="10"

***Value is 10, even though we reported no changes.

The child shows an update:
(gdb)
-var-update 1 var0.*bar
^done,changelist=[{name="var0.*bar",value="10",in_scope="true",type_changed=
"false",has_more="0"}]


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Documentation LLDB-MI

[Ted Woodward via lldb-dev]

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) for 
-file-exec-and-symbols, I don’t see a way to read a core file with mi commands, 
but you can give an lldb command that will be passed through, something like 
“target create foo.elf -c foo.core”

 

You build lldb-mi the same way you build lldb, just use the lldb-mi target. For 
example, “make lldb-mi”.

 

--

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 Laghzaoui 
Mohammed via lldb-dev
Sent: Friday, May 26, 2017 5:43 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] Documentation LLDB-MI

 

Hi Lists,

I have to implement a graphical interface to open the Dump of Macos with LLDB.

I know how to do this using the command line, but this and less productive, I 
found that LLDB-MI little make me an interface to do this need but I did not 
find an example of LLDB-MI in C ++ and How to build LLDB-MI.

To detail our need:

1 - opening of a core dump.

2 -__ reading the value of a memory address.

3 -__ list threads and frames.

4 -__ get assembler of each frame.

  

Thank you in advance for your help

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 system in /local/scratch/work/debuglibs , you can say
target modules search-paths add /usr/lib /local/scratch/work/debuglibs
and when lldb goes to load (for example) /usr/lib/libc.so, it will try to load 
/local/scratch/work/debuglibs/libc.so from the host machine before trying to 
load through the memory interface.

I found this very helpful when trying to debug dynamic executables on Linux 
running on a Hexagon board, running lldb on x86 Linux or Windows.

Ted

--
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 Jim
> Ingham via lldb-dev
> Sent: Monday, May 22, 2017 5:02 PM
> To: Chunseok Lee 
> Cc: lldb-dev 
> Subject: Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"
> 
> In general, if lldb can find host-side copies of binaries that match the ones 
> it
> finds on the device, it will do all symbol reading against the host copies.  
> In
> the case of an OS X host debugging iOS, lldb uses Spotlight and a few other
> tricks to find the host-side binaries.  You can also use "add-symbol-file" to
> manually point lldb at the host-side symbol files.  If you are reading symbols
> from host-side files, then symbol loading doesn't slow down debugging
> startup that much.
> 
> Presumably, your symbol files are only on the device, so you are reading
> them from memory.  "settings set target.memory-module-load-level" is
> almost what you want, but it applies to ALL shared libraries read from
> memory.  If you can copy the symbol file that contains the
> __jit_debug_register_code to the host you are debugging from, and use
> add-symbol-file to tell lldb about it, then that one should NOT have to be
> read from memory anymore.  Then you could turn "memory-module-load-
> level" to partial or even mininal, and that should get you starting faster.
> 
> The other option would be to extend the setting, so you can say:
> 
> set set target.memory-module-load-level [[lib-name level] [lib-name level]
> ...]
> 
> If there's just one argument, that's equivalent to "all ".
> 
> Jim
> 
> > On May 22, 2017, at 2:35 PM, Chunseok Lee 
> wrote:
> >
> >
> >
> > Thank you for your help.
> > It would be really helpful to me.
> >
> > The reason behind the question is exactly what you mentioned. I am
> > wokring on debugging in devices and it seems that shared library loading(I
> do not know lldb loads symbols lazyly) runs very slowly since my testing
> program depends on so many shared libs.  since I am debuggging with gdbjit
> feature, I do not need shared library loading except one shared lib(which
> contains __jit_debug_register_code symbol) Thus, I want to turn off shred
> lib loading except one shared lib. Is it possible?
> >
> > Thank you.
> >
> > BR,
> > Chunseok Lee
> >
> >
> >
> > 2017. 5. 23. 오전 3:24 Jim Ingham  작성:
> >
> >> We designed lldb to be as lazy as possible in loading symbol information
> from the shared libraries as they get loaded.  If this is causing you 
> problems,
> the first thing to do is to figure out why lldb is pulling in more information
> than you need.  For instance, it looks like on Linux the gdb JIT loading
> breakpoint is getting set with a global search which is pulling in all the 
> symbols
> from all the initially loaded shared libraries.  It would be better to fix 
> things so
> that only explicit user actions (which can be scoped to shared libraries to 
> limit
> the search) pull in symbols so we don't have to fiddle around with turning off
> and on the loading of shared libraries.  Back when we were supporting gdb
> for MacOS I did a lot of work to try to get this right (there are times you 
> really
> need the shared library info - e.g. when something shows up in a backtrace)
> so you have to judiciously re-introduce symbols, or the user experience is
> noticeably degraded.
> >>
> >> It also depends on how far you want to go turning this off.  There's "don't
> look at shared libraries at all" which is what the auto-solib-add variable 
> does
> IIRC.  We also had a fairly extensive mechanism to specify "load-levels" for
> various libraries, which  was more user-friendly but much more work to
> support.  Anyway, it would be easy to just turn this shared library
> notifications - just don't set the dyld load notification breakpoint.  That 
> would
> be the easy part.  But as I said above, you're also going to have to make sure
> you turn it back on for users when some action they request requires it.
> >>

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

[Ted Woodward via lldb-dev]

My dev machine has both debug and release python exe/lib/dll installed; The VS 
solution made by cmake works fine building debug and release versions of lldb. 
Our bots only have release exe/lib, and create a VS solution with cmake and 
build with msbuild.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Monday, May 22, 2017 3:47 AM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: Zachary Turner <ztur...@google.com>; Vadim Chugunov
> <vadi...@gmail.com>; Hans Wennborg <h...@chromium.org>; LLDB  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] Python scripting in Windows LLDB
> 
> This may cause some issues with the multi-configuration generators.
> 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 19 May 2017 at 21:42, Ted Woodward via lldb-dev  d...@lists.llvm.org> wrote:
> > 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 1 PARENT_SCOPE)
> >
> > return()
> >
> >   endif()
> >
> >
> >
> > Internally I’ve changed it to:
> >
> >
> >
> >   if (CMAKE_BUILD_TYPE STREQUAL "Debug")
> >
> > if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND
> > PYTHON_DEBUG_DLL))
> >
> >   message("Python installation is corrupt. Python support will be
> > disabled for this build.")
> >
> >   set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
> >
> >   return()
> >
> > endif()
> >
> >   else()
> >
> > if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))
> >
> >   message("Python installation is corrupt. Python support will be
> > disabled for this build.")
> >
> >   set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
> >
> >   return()
> >
> > endif()
> >
> >   endif()
> >
> >
> >
> > That works with our buildbots building release.
> >
> >
> >
> > Note the release check doesn’t check for the DLL – our installations
> > don’t have the release DLL, so I didn’t put that in.
> >
> >
> >
> > I can push this change upstream if you’d like, Zach.
> >
> >
> >
> > --
> >
> > 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 lldb-dev
> > Sent: Friday, May 19, 2017 3:18 PM
> > To: Vadim Chugunov <vadi...@gmail.com>; Hans Wennborg
> > <h...@chromium.org>; LLDB <lldb-dev@lists.llvm.org>
> > Subject: Re: [lldb-dev] Python scripting in Windows LLDB
> >
> >
> >
> > Hmm, I believe it's only supposed to do that if you're doing a debug build.
> > It should only require the Python libraries that match your current build.
> > Is it not doing this?
> >
> >
> >
> > On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev
> > <lldb-dev@lists.llvm.org> wrote:
> >
> > Update: looks like Python detection in CMake now requires debug
> > binaries to be there as well (e.g. python35_d.dll), otherwise Python
> > support gets disabled.  I am wondering if Python the build machine was
> > installed without the debug stuff.
> >
> >
> >
> > On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov <vadi...@gmail.com>
> wrote:
> >
> > Hi!
> >
> >
> >
> > I've just noticed that LLDB from the most recent LLVM Windows snapshot
> > build has Python scripting disabled.
> >
> > Was this done on purpose and for what reason if so?
> >
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 1 PARENT_SCOPE)

return()

  endif()

 

Internally I’ve changed it to:

 

  if (CMAKE_BUILD_TYPE STREQUAL "Debug")

if (NOT (PYTHON_DEBUG_EXE AND PYTHON_DEBUG_LIB AND PYTHON_DEBUG_DLL))

  message("Python installation is corrupt. Python support will be disabled 
for this build.")

  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

  return()

endif()

  else()

if (NOT (PYTHON_RELEASE_EXE AND PYTHON_RELEASE_LIB))

  message("Python installation is corrupt. Python support will be disabled 
for this build.")

  set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)

  return()

endif()

  endif()

 

That works with our buildbots building release.

 

Note the release check doesn’t check for the DLL – our installations don’t have 
the release DLL, so I didn’t put that in.

 

I can push this change upstream if you’d like, Zach.

 

--

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 lldb-dev
Sent: Friday, May 19, 2017 3:18 PM
To: Vadim Chugunov ; Hans Wennborg ; LLDB 

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

 

Hmm, I believe it's only supposed to do that if you're doing a debug build.  It 
should only require the Python libraries that match your current build.  Is it 
not doing this?

 

On Fri, May 19, 2017 at 1:15 PM Vadim Chugunov via lldb-dev 
 > wrote:

Update: looks like Python detection in CMake now requires debug binaries to be 
there as well (e.g. python35_d.dll), otherwise Python support gets disabled.  I 
am wondering if Python the build machine was installed without the debug stuff.

 

On Fri, May 19, 2017 at 10:52 AM, Vadim Chugunov  > wrote:

Hi!

 

I've just noticed that LLDB from the most recent LLVM Windows snapshot build 
has Python scripting disabled. 

Was this done on purpose and for what reason if so?

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org  
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 Forum, a Linux 
Foundation Collaborative Project

 

From: Russell Greene [mailto:russellgree...@gmail.com] 
Sent: Monday, April 03, 2017 11:24 AM
To: Ted Woodward ; LLDB 
Subject: Re: [lldb-dev] Using LLDB API on windows

 

That makes sense, and I'm sure it works great when using MSVC as a compiler, 
but I think LLDB recognizes mingw as a unix compiler and tries to do 
GDBRemoteCommunication::StartDebugserverProcess when it should be doing 
PlatformWindows::DebugProcess. 

 

Not sure though. All I know is when I try to do a SBTarget::Launch on windows 
under mingw (msys2) it says cannot find lldb-server...

 

-Russell

 

On Mon, Apr 3, 2017 at 9:32 AM Ted Woodward  > wrote:

Hi Russell,

 

I assume you mean for SBTarget::Launch or LaunchSimple to launch a Windows 
application.

 

The short answer is, this already works.

 

SBTarget::Launch calls Target::Launch, which calls DebugProcess in the relevant 
platform. For cases where we use lldb-server, the platform make a call that 
eventually gets to  GDBRemoteCommunication::StartDebugserverProcess to start up 
lldb-server. On Windows, PlatformWindows::DebugProcess calls Process::Launch, 
which (on Windows) will do the correct thing to start up and connect to a 
Windows process.

 

See PlatformWindows::DebugProcess in 
source\Plugins\Platform\Windows\PlatformWindows.cpp and 
ProcessLauncherWIndows::LaunchProcess in 
source\Host\windows\ProcessLauncherWindows.cpp .

 

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-boun...@lists.llvm.org 
 ] On Behalf Of Russell Greene via 
lldb-dev
Sent: Sunday, April 02, 2017 4:38 PM
To: lldb-dev@lists.llvm.org  
Subject: [lldb-dev] Using LLDB API on windows

 

Hey so I am developing a project using LLDB as a debugger and am looking to 
make it cross-platform. 

 

As I see it, the LLDB API boots up an instance of lldb-server, but lldb-server 
isn't available on windows. Is there a way to use the LLDB C++ API on windows? 

 

On the status page   I see the lldb 
commandline tool is OK for windows, which uses the LLDB API, how is this 
achieved?

 

-Russell

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] std::vector formatter question

[Ted Woodward via lldb-dev]

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 vector.c:10
   7vector v;
   8v.push_back(2);
   9v.push_back(1);
-> 10   cout << v[0] << " " << v[1] << endl;
   11   return 0;
   12   }
 (lldb) fr v v
(std::vector) v = size=0 {}

When I run on x86 linux built with gcc, I get:
(lldb) fr v v
(std::vector) v = size=2 {
  [0] = 2
  [1] = 1
}


My guess is Dinkumware's vector type is just a little bit different from
libstdc++/libcxx, so the standard formatters don't do the right thing. Where
are the vector formatters defined, and how does LLDB determine which
one to use?


--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 upfront the image of threads within
>> debuggee]
>>  - Resume Thread 2 (PT_RESUME)
>>  - Suspend Thread 3 (PT_SUSPEND)
>>  - Set single-step Thread 2 (PT_SETSTEP)
>>  - Set single-step Thread 4 (PT_SETSTEP)
>>  - Clear single-step Thread 5 (PT_CLEARSTEP)
>>  - Resume & emit signal SIGIO (PT_CONTINUE)
>>
>> In other words: setting properties on threads and pushing the
>> PT_CONTINUE button at the end.

> None of this is really NetBSD-specific, except the whole-process signal at 
> the end (which I am going to ignore for now). I mean, the implementation of 
> it is different, but there is no reason why someone would not want to perform 
> the same set of actions on Linux for instance. I think most of the work here 
> should be done on the client. Then, when the user issues the final 
> "continue", the client sends something like $vCont;s:2;s:4;c:5. Then it's up 
> to the server to figure out how execute these actions. On NetBSD it would 
> execute the operations you mention above, while on linux it would do 
> something like ptrace(PTRACE_SINGLESTEP, 2); ptrace(PTRACE_SINGLESTEP, 4); 
> ptrace(PTRACE_CONTINUE, 5); (linux lldb-server already supports this 
> actually, although you may have a hard time convincing the client to send a 
> packet like that).

The big problem with this sequence is non-stop mode. To continue thread 5 while 
threads 2 and 4 are stepping, and thread 3 is stopped is not legal using 
all-stop mode. lldb only supports non-stop mode in the gdb-remote 
communications layer; the guts of the debugger do not support it, and could get 
very confused when threads 2 and 4 stop, but thread 5 is still running.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

I think the remote stub only sends extra stop replies in response to a vStopped 
packet. Here is a stop for 2 threads hitting a common breakpoint:

<  51> send packet: $vCont;c:10b6;c:10f8;c:00b3;c:00b2;c:00b1;c:00b0#e0
<   1> read packet: +
<   6> read packet: $OK#9a
<   1> send packet: +
<  58> read packet: %Stop:T052a:c8f4f5e0;1e:90de101b;1d:48dd101b;thread:af;#1d
<   1> send packet: +
<  12> send packet: $vStopped#55
<   1> read packet: +
<  53> read packet: $T052a:c8f4f5e0;1e:309c101b;1d:e89a101b;thread:b0;#d8
<   1> send packet: +
<  12> send packet: $vStopped#55
<   1> read packet: +
<   6> read packet: $OK#9a

So we won't get any spurious stops in the middle of processing.

"Experimental feature, not tested" is noted - I'll mention that in my meeting 
today.

--
Qualcomm Innovation Center, Inc.
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, February 03, 2017 1:22 PM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: Greg Clayton <gclay...@apple.com>; LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> 
> 
> > On Feb 3, 2017, at 10:51 AM, Ted Woodward
> <ted.woodw...@codeaurora.org> wrote:
> >
> > I'm working on plumbing the existing non-stop mode switch (target.non-
> stop-mode) to lldb-mi, to give Eclipse access to non-stop mode.
> >
> > The remote OS is very thread-heavy, and the remote stub doesn't limit the
> debugger to the current process - because there isn't one, from the stub's
> point of view. Just a collection of threads. In all-stop mode, if a 2nd thread
> hits a breakpoint, it will send back a 2nd stop reply, which confuses lldb
> (rightly so). In non-stop mode, it handles things correctly. So we'll just 
> have
> to live with the possible missed breakpoint issue.
> 
> We tried to keep the possibility of a non-stop mode in mind when designing
> lldb, but I know there are places in lldb at present that assume that if you 
> get
> a "stop" event you won't get another stop event till lldb issues a run.  We 
> try
> not to fall over completely if we get events we don't expect, but we're more
> likely to just discard them than do the right thing.  There also don't appear 
> to
> be any tests running programs in non-stop mode and exercising their
> behavior, so any extent to which it works will be accidental and unstable.
> 
> Seems like this is an experimental feature at best, and should be marked as
> such.
> 
> Jim
> 
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > 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, February 03, 2017 10:58 AM
> >> To: Greg Clayton <gclay...@apple.com>
> >> Cc: Ted Woodward <ted.woodw...@codeaurora.org>; LLDB  >> d...@lists.llvm.org>
> >> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
> >>
> >>
> >>> On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev  >> d...@lists.llvm.org> wrote:
> >>>
> >>> Non-stop mode is a huge change to the core of LLDB isn’t it. I think
> >>> you
> >> might think this is easier than it actually is to enable in LLDB?
> >>>
> >>> Is non-stop mode where you can leave some threads running while
> >>> others
> >> are stopped? The biggest issue with this is to do it right we need to
> >> be able to emulate instructions so that if 3 threads hit breakpoints,
> >> we would need to emulate the instruction that used to be at the
> >> breakpoint in LLDB since we can’t remove the breakpoint (unless you
> >> stop the other threads which defeats the purpose of non-stop mode)
> >> without the other 2 threads possibly missing the breakpoint while you
> >> disable breakpoint, single step, enable breakpoint.
> >>
> >> 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 about missing breakpoints is
> a second order problem.
> >>
> >> Anyway, even as it is it has some utility - presumably you're using
> >> it because you have some threads in