Re: [lldb-dev] Semantics of SBValue::CreateChildAtOffset

> On Oct 22, 2021, at 6:12 AM, Pavel Labath via lldb-dev > wrote: > > Hello Jim, everyone, > > I recently got a question/bug report about python pretty printers (synthetic > child providers) that I couldn't answer. > > The actual script is of course more complicated, but the essence boils d

Re: [lldb-dev] Why can't I break on an address resulting in unresolved?

You can set breakpoints at addresses prior to running a process. ASLR will shift shared libraries around each time you run, so it really isn't safe to set these. If you do disable ASLR, and are able to debug, just reverse your statement and do the "process launch" first: process launch --stop-a

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

> On Oct 28, 2021, at 6:33 AM, Pavel Labath via lldb-dev > wrote: > > Hello everyone, > > I'd like to propose a new plugin for better lldb+qemu integration. > > As you're probably aware qemu has an integrated gdb stub. Lldb is able > to communicate with it, but currently this process is some

Re: [lldb-dev] No script in lldb of build

I have had to add the following to my cmake command line: -DPython3_EXECUTABLE=/usr/bin/python3 > On Dec 5, 2021, at 12:02 PM, Pi Pony via lldb-dev > wrote: > > Hello, > > I build lldb for macOS and tried to get into script but I get this error > message: there is no embedded script in

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

I am fine with a new plug-in to handle this, but I want to verify a few things first: Can this core dump file format basically allow debugging of multiple targets? For example could you for example want to examine the kernel itself as is, but also provide a view into any of the user space proce

Re: [lldb-dev] Source-level stepping with emulated instructions

We just need to specify that the addresses for these emulated instruction address ranges have symbols and the type of these symbols are set to "eSymbolTypeTrampoline". We run into a similar case when you are stepping through the PLT entries for external functions. If your main binary has a "pri

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

The other idea would be to allow the Platform subclasses to be able to fill in some fixed variable names when asked. So if the user typed either: (lldb) frame variable $platform.siginfo (lldb) expression $platform.siginfo We would have the name lookup mechanism check with the current platform i

Re: [lldb-dev] problems using EvaluateExpression in lldb, when it creates new object

> On Jan 14, 2022, at 10:13 AM, fhjiwerfghr fhiewrgfheir via lldb-dev > wrote: > > I'm sorry in advance, if it's not a correct mailing list, there doesn't seem > to be lldb-usage mailing list. > > I'm writing a pretty-printer python script, which - to cut to the chase, > pretty prints mem

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

> On Jan 20, 2022, at 4:40 PM, Omair Javaid 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/lld

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

Understood, we need to be able to log if "any" bits are set. > On Jan 20, 2022, at 2:18 PM, Jim Ingham wrote: > > > >> On Jan 20, 2022, at 11:26 AM, Pavel Labath wrote: >> >> On 20/01/2022 00:30, Greg Clayton wrote: >>> I also vote to remove and simplify. >> >> Sounds like it's settled the

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

> On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: > > Hi all, > > In case you haven't noticed, I'd like to draw your attention to the in-flight > patches (https://reviews.llvm.org/D117382, https://reviews.llvm.org/D117490) > whose goal clean up/improve/streamline the logging infrastructure.

Re: [lldb-dev] Multiple platforms with the same name

> On Jan 19, 2022, at 4:28 AM, Pavel Labath wrote: > > On 19/01/2022 00:38, Greg Clayton wrote: >> Platforms can contain connection specific setting and data. You might want >> to create two different "remote-linux" platforms and connect each one to a >> different remote linux machine. Each t

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

I also vote to remove and simplify. > On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: > > Hi all, > > In case you haven't noticed, I'd like to draw your attention to the in-flight > patches (https://reviews.llvm.org/D117382, https://reviews.llvm.org/D117490) > whose goal clean up/improve/str

Re: [lldb-dev] Multiple platforms with the same name

Platforms can contain connection specific setting and data. You might want to create two different "remote-linux" platforms and connect each one to a different remote linux machine. Each target which uses this platform would each be able to fetch files, resolve symbol files, get OS version/build

[lldb-dev] Can't build on Mac after https://reviews.llvm.org/D113650

Some recent python changes have stopped by cmake configure from working on fresh checkout on macOS. Details in the comments of the diff in https://reviews.llvm.org/D113650 as to how I am configuring cmake. If anyone has any example of how to properly set the python stuff to work around the issu

Re: [lldb-dev] RISC-V (bare-board) debugging?

> On Jun 19, 2021, at 2:59 AM, Thomas Goodfellow via lldb-dev > wrote: > > I saw the impending patch https://reviews.llvm.org/D62732 > , which suggests that the current LLDB > doesn't support RISC-V targets at all? If that's correct, then do I > understand c

Re: [lldb-dev] Reporting bugs which only affect (semi-proprietary) downstream consumers.

> On Jun 22, 2021, at 10:10 AM, Adam HARRIES via lldb-dev > wrote: > > Hi all, > > I've recently taken over maintenance of my company's llvm+lldb branch, where > we have added support for our in-house architecture (in llvm) as well as > support for debugging through both hardware and our s

Re: [lldb-dev] small Editline wrapper cleanup req for feedback

As long as the solution matches "EditLine *" (C struct type from edit line library) to back to the C++ instance of "Editline" (lower case ell in "line" from LLDB). It should be easy to do with a template. I am fine with any new solution that makes it easier to add new commands. I would rather h

Re: [lldb-dev] [RFC] Improving protocol-level compatibility between LLDB and GDB

> On Apr 19, 2021, at 12:59 AM, Michał Górny via lldb-dev > wrote: > > Hi, everyone. > > I'm considering running some effort to improve protocol-level > compatibility between LLDB and GDB. I'd like to hear if there's > interest in such patches being accepted into LLDB. Yes! > > My goal wo

Re: [lldb-dev] Hiding local variables not defined yet

> On Apr 12, 2021, at 4:44 PM, Emre Kultursay wrote: > > Looking at Android Studio implementation a little deeper, it actually does > the filtering the way I described in my first email, by comparing line > numbers. It does not use the location expressions. Interesting if they are doing mor

Re: [lldb-dev] Hiding local variables not defined yet

> On Apr 9, 2021, at 11:39 AM, Emre Kultursay via lldb-dev > wrote: > > When debugging C/C++ (statically scoped languages), does LLDB recognize (or > does it have a setting for it) that a local variable is not defined yet at > the current program address (i.e., DW_AT_decl_line is less than t

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

How about adding the stand alone binary info as new key value pairs to the response to the qHostInfo or qProcessInfo packets? With JTAG you will want to know information about what you are connecting to, so it kind of makes sense here. The responses to a simple a.out mac binary already have cput

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

> On Mar 22, 2021, at 11:01 PM, Jason Molenda wrote: > > 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 b

Re: [lldb-dev] lldb versus visual studio

> On Mar 20, 2021, at 8:57 AM, Franz Fehringer via lldb-dev > 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

Re: [lldb-dev] Is DBGSearchPaths supported for configuring dSYM lookups?

> On Feb 18, 2021, at 6:55 AM, Ivan Hernandez wrote: > > Thank you for the very detailed explanation Greg! Happy to help! I wrote the original DebugSymbols.framework when I worked at Apple many many years ago, so I am quite familiar with what it does. > Good to know about why DBGSpotlightPat

Re: [lldb-dev] Is DBGSearchPaths supported for configuring dSYM lookups?

DBGSpotlightPaths is to limit spotlight searches to _only_ those directories, but they must be valid locations that spotlight would normally index. If you want to see if spotlight indexes a directory that contains a dSYM file, then you can us "mdls": $ mdls a.out.dSYM _kMDItemDisplayNameWithExt

Re: [lldb-dev] Help fixing deadlock in DWARF symbol preloading

A simpler solution is to remove the lock in Module::GetDescription(...) all of the data that is used to dump the module description is set correctly (the file, the arch and the object name for BSD archives)) very early on when a module is created before anyone should be making symbol or debug in

Re: [lldb-dev] lldb/test/API/commands/help/TestHelp.py not running just-built lldb

Might be an easy fix to have our test suite unset the "LD_LIBRARY_PATH" env var if it is set? > On Jan 19, 2021, at 5:38 PM, David Blaikie via lldb-dev > wrote: > > Jonas helped me out here (Thanks!) > > Seems I was setting LD_LIBRARY_PATH for, so far as I recall, good reasons (I > have some

Re: [lldb-dev] Remote connection expansion?

> On Nov 11, 2020, at 11:11 AM, Mike Mestnik > wrote: > > On Mon, Nov 9, 2020 at 5:37 PM Greg Clayton wrote: >> >> >> >>> On Nov 4, 2020, at 1:28 PM, Mike Mestnik via lldb-dev >>> wrote: >>> >>> I'm looking for support running lldb over ssh. I can forward the >>> originating connection

Re: [lldb-dev] Remote connection expansion?

> On Nov 4, 2020, at 1:28 PM, Mike Mestnik via lldb-dev > wrote: > > I'm looking for support running lldb over ssh. I can forward the > originating connection, but the run command is attempting to use > random ports on localhost to attain another connection. This fails as > the localhost's a

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

upstream as much as possible as soon as possible to avoid differences and merging issues for you guys. I would really like to see LLDB have support for segmented address spaces. Many comments I made were just my thinking out loud and trying to ease the changes in with as little disruption as p

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

So the good news is the DWARF seems to be valid. I think LLDB is having problems with this ELF file because it is an object file (e_type == ET_REL) or because it has no program headers. There were some changes made to LLDB where we would put any section headers that were contained in program h

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

As long as the location TestFunction.cpp:1 has a valid line in the PDB line tables, this breakpoint should be hit if there is debug info and the internal PDB parser is parsing things correctly. If you have debug info in your binary, _and_ if LLDB is able to locate your PDB file, then you should

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

> On Oct 19, 2020, at 2:56 PM, 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 u

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

> On Oct 8, 2020, at 10:29 PM, Jason Molenda wrote: > > > >> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote: >> >> >> >>> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote: >>> >>> >>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote: Good bug find! It seems

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote: > > Good bug find! > > It seems to me that DWARFCallFrameInfo should push the initial CIE register > setup instructions as being the state at offset 0 in the function (in fact > I'd say it's a bug if it's not). If that were done, then gettin

[lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

Hello LLDB devs, This is a deep dive into an issue I found in the LLDB handling of DWARF call frame information, so no need to read further if this doesn't interest you! I am in the process of adding some support to LLVM for parsing the opcode state machines for CIE and FDE objects that produce

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev > wrote: > > > >> On Oct 7, 2020, at 12:11 PM, Pavel Labath wrote: >> >> On 07/10/2020 21:01, Jim Ingham wrote: On Oct 7, 2020, at 11:44 AM, Pavel Labath >>> > wrote: On 07/10/2020 20:42, Jim Ing

Re: [lldb-dev] Deadlock loading DWARF symbols

Yes this is bad, and GetDescription() is used as a convenience to print out the module path (which might be a .o file within a .a file) and optionally architecture of the module. It probably shouldn't be taking the module lock as the only member variables that that GetDescription accesses are:

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

> On Oct 2, 2020, at 3:51 AM, Pavel Labath wrote: > > On 01/10/2020 22:32, Walter wrote: >> After a chat with Greg, we agreed on this set of commands >> >> >> trace load /path/to/json process trace start/stop process trace save >> /path/to/json thread trace start/stop thread trace dump [instr

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

I had accepted the patch https://reviews.llvm.org/D86670 , but then marked as "Request Changes" while we discuss the commands in this RFC after new comments came in. > On Oct 1, 2020, at 1:42 PM, Greg Clayton wrote: > > We spoke a bit after Panel's comments wh

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

We spoke a bit after Panel's comments which made sense and we propose the commands Walter sent below. Let us know what everyone thinks of this organization of the command structure! > On Oct 1, 2020, at 1:32 PM, Walter wrote: > > After a chat with Greg, we agreed on this set of commands > >

Re: [lldb-dev] LLDB got SIGCHLD on hitting the breakpoint

LLDB 5 is really old and shouldn't be used for linux debugging as linux support had many issues back then. I would suggest downloading and building the latest and greatest LLDB from llvm.org or using the clang 10 release version of LLDB, or the new clang 11 release version tha

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

> On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev > wrote: > > Thank you for writing this Walter. I think this document will be a > useful reference both now and in the future. > > The part that's not clear to me is what is the story with multi-process > traces. The file format enables

Re: [lldb-dev] Weird results running lldb under Valgrind

Glad we know why at least! Thanks for bringing this to our attention. Greg > On Sep 30, 2020, at 2:53 AM, Dmitry Antipov wrote: > > On 9/29/20 11:40 PM, Greg Clayton wrote: > >> How could LLDB even function then? We are using the standard std::mutex + >> std::condition workflow here. Not sure

Re: [lldb-dev] Weird results running lldb under Valgrind

How could LLDB even function then? We are using the standard std::mutex + std::condition workflow here. Not sure how LLDB could even function if it locking was nor working as expected. Doing a quick web search, this seems to be due to a mismatched libc++ and libstdc++: https://github.com/googl

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

I would suggest using python here. You can make a new LLDB command in a python file and then "command script import /path/to/my/file.py". This python script would install a new command and you can then just run that command. Happy to help you get this script working off the mailing lists if you

Re: [lldb-dev] Weird results running lldb under Valgrind

This must be a valgrind issue, there would be major problems if the OS isn't able to lock mutex objects correctly ("mutex is locked simultaneously by two threads"). It is getting confused by a recursive mutex? LLDB uses recursive mutexes. > On Sep 24, 2020, at 1:55 AM, Dmitry Antipov via lldb-

Re: [lldb-dev] ValueObjectChild and SetData

Thanks for the info. Comments inlined below! > On Aug 6, 2020, at 1:56 PM, Gabor Greif wrote: > > On 8/6/20, Greg Clayton mailto:clayb...@gmail.com>> > wrote: >> >> >>> On Aug 5, 2020, at 1:50 PM, Gabor Greif via lldb-dev >>> wrote: >>> >>> Hi LLDB devs, >>> >>> short question. Since the m

Re: [lldb-dev] ValueObjectChild and SetData

> On Aug 5, 2020, at 1:50 PM, Gabor Greif via lldb-dev > wrote: > > Hi LLDB devs, > > short question. Since the method > > bool ValueObjectChild::SetData(DataExtractor &data, Status &error) > > doesn't exist, what is the preferred way to update the contents of > scalar bitfields? > > Is t

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

> On Jul 30, 2020, at 8:07 PM, Rui Hong via lldb-dev > wrote: > > 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 r

Re: [lldb-dev] [RFC] Listing files in remote directory

> On Jul 24, 2020, at 9:55 AM, GongYu Deng via lldb-dev > wrote: > > Hello everyone, > > To implement a remote disk file completion like > CommandCompletions:DiskFilesOrDirectories for commands like "platform > get-size”, I was trying to find out how local disk files are resolved. It > see

Re: [lldb-dev] Remote debug arm bare metal target with lldb - load executable to target

Sounds like you got close. What does your target look like when you type: (lldb) target list I forgot to mention one thing that we do for ELF files: We make sections named PT_LOAD[N] where in N starts at zero. We do this because this is essentially how dynamic loaders actually load the binar

Re: [lldb-dev] Remote debug arm bare metal target with lldb - load executable to target

The --load option should work if all of the program headers have the right addresses. LLDB should try to load all PT_LOAD program headers into memory at the address that they are loaded at. Is this a baseboard situation where you have an ELF file that has program headers with all of the correct

Re: [lldb-dev] Break setting aliases...

BTW: to see what things expand to after reach regex alias, just set this setting first: (lldb) settings set interpreter.expand-regex-aliases true Each time you type "b main" it will show you the expansion: (lldb) b main breakpoint set --name 'main' ... (lldb) b main.cpp:12 breakpoint set --file

Re: [lldb-dev] Break setting aliases...

> On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev > wrote: > > When we were first devising commands for lldb, we tried to be really > parsimonious with the one & two letter unique command strings that lldb ships > with by default. I was trying to leave us as much flexibility as possib

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

> On Jul 21, 2020, at 9:27 AM, Pavel Labath wrote: > > On 20/07/2020 23:25, Jim Ingham wrote: >> It seems like you are having to work hard in the ValueObject system because >> you don’t want to use single AST Type for the ValueObject’s type. Seems >> like it be much simpler if you could cons

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

Thanks for the write up! I agree that the existing APIs are useful for exploring the types as they appear (and are completed within) in the module they came from. Now we are asking more complex questions from them. As with all software, things started out simple and have gotten quite a bit more

Re: [lldb-dev] LLDB SBAPI questions

> On Jul 14, 2020, at 3:13 PM, Vadim Chugunov via lldb-dev > wrote: > > Hi, > I've a couple of questions: > > 1. Is there a way to get numeric values of C++ template parameters?SBType > has a method for discovering argument kind and type, but I couldn't find > anything for values. You

Re: [lldb-dev] LLDB Plugin: Listen for SBEvents when SBTarget is created from Xcode

Here is example code showing what Jim was talking about: auto listener = debugger.GetListener(); const uint32_t target_event_mask = lldb::SBTarget::eBroadcastBitModulesLoaded | lldb::SBTarget::eBroadcastBitModulesUnloaded | ...; const uint32_t process_event_mask = lldb::SBProcess::eBroadcastBitSt

Re: [lldb-dev] LLDB single-stepping problem on remote debugging

I believe, as you suspected, that because LLDB doesn't know anything about your registers, that stuff is falling down. The first thing you need to do is make sure LLDB knows about your registers. LLDB will send some packets to detect registers from the GDB server and you must respond. So as soon

Re: [lldb-dev] Unable to use Vi mode in LLDB console on Linux

> On May 17, 2020, at 10:11 AM, Alvin Ye wrote: > > On Sat, May 16, 2020 at 3:44 PM Greg Clayton > wrote: >> >> There are some posts about issues with using the "bind -v". It seems it will >> delete all other key bindings and LLDB does a bunch of bindings for custo

Re: [lldb-dev] Unable to use Vi mode in LLDB console on Linux

There are some posts about issues with using the "bind -v". It seems it will delete all other key bindings and LLDB does a bunch of bindings for custom things which you won't want to use. > On May 16, 2020, at 10:34 AM, Alvin Ye via lldb-dev > wrote: > > Hello, > > I'm using LLDB installed

Re: [lldb-dev] Pre-merge lldb testing

> On May 15, 2020, at 7:04 PM, Eric Christopher via lldb-dev > wrote: > > Hi All, > > We've been testing[1] a number of patches upstream by default via some > pre-merge checks in phabricator. I was thinking of turning them on for lldb > as well. Mostly it well just help people know whether

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

One reason to not only load your libraries is backtraces will be truncated for any stack frames that go through the system libraries. These tend to be in the stack traces a lot as we deal with Android all the time at Facebook... Greg > On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev >

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

Adding Antonio Afonso since he did some work on speeding things up at Facebook for Android. Emre: what version of LLDB are you using? Top of tree? One from a package distro? > On May 13, 2020, at 3:00 PM, Greg Clayton wrote: > > So one idea is to improve the PlatformAndroid to use "adb" to

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

So one idea is to improve the PlatformAndroid to use "adb" to copy all system libraries over and pre-cache all system libraries instead of letting it happen one by one. Android is also very inefficient in loading shared libraries. It will load them one by one and each one involves 2 stops since

Re: [lldb-dev] Question regarding argument types of "BreakpointHitCallback"

> On Apr 30, 2020, at 8:50 AM, Vangelis Tsiatsianas via lldb-dev > wrote: > > Hello, > > I would like to ask a question regarding "BreakpointHitCallback", which is > declared as such: > > bool (*BreakpointHitCallback)(void *baton, > StoppointCallbackContext *co

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

> On Apr 29, 2020, at 9:28 PM, Rui Hong wrote: > > Hi LLDB devs, > > 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! > > I've been working on other lldb problems and resume so

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

> On Apr 16, 2020, at 2:30 AM, Rui Hong via lldb-dev > wrote: > > 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 comm

Re: [lldb-dev] Getting the file and line location of a break point via lldb python api

As Jim said, we have many different kinds of breakpoints and breakpoints can have N SBBreakpointLocations and that number can change as your process runs and more shared libraries are loaded. If you set a source file and line breakpoint to begin with, then iterating over the locations is the be

[lldb-dev] SBValues that are synthetic has API issues when trying to get the child by name:

3int main(int argc, const char **argv) { 4 std::atomic ai; 5 ai = argc; -> 6 ai = argc + 1; 7 return 0; 8} (lldb) fr var ai (std::atomic) ai = { Value = 1 } (lldb) frame var --raw ai (std::__1::atomic) ai = { std::__1::__atomic_base = { std::__1:

Re: [lldb-dev] Default script language

I'd be fine with your #ifdef approach. Anyone else? > 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 > eScriptLanguageD

Re: [lldb-dev] Default script language

For scripting to working it must support classes and Swig must support creating bindings for the entire public API. Don't think shell scripting can do that. Greg > On Apr 1, 2020, at 3:24 PM, Marcus Johnson via lldb-dev > wrote: > > Why default to none if python and lua aren't available inste

Re: [lldb-dev] lldb-instr not working

Are there instructions for this somewhere? If not, can we get some on the site? > On Mar 23, 2020, at 1:31 PM, Jonas Devlieghere via lldb-dev > wrote: > > Hi Walter, > > lldb-instr needs compile_commands.json file to figure out the exact compiler > invocation for every file. Can you verify th

Re: [lldb-dev] LLDB problem with TAB

> On Mar 17, 2020, at 2:39 AM, Rui Hong via lldb-dev > wrote: > > Hi LLDB devs, > > First I want to thank you all for the very helpful advice on my former > question! It's a really nice community. > > I have a small problem now about LLDB tab completion and I haven't found any > solutions

Re: [lldb-dev] Question about LLDB SBEvent C++ API

> On Mar 14, 2020, at 4:13 PM, Rui Liu via lldb-dev > wrote: > > Hi LLDB devs, > > The SBEvent API has GetType() method on it, which returns a uint32_t, however > I didn't find any documentation on how to interpret this uint32_t... Is there > a enum for it somewhere? > > There is a GetDesc

Re: [lldb-dev] LLDB C++ API causes SIGSEGV

You will want to call SBDebugger::Initialize() first before doing anything. Since LLDB is a shared library, we don't want to do a bunch of work when the LLDB shared library is loaded in case LLDB might not always be used right away or at all within a process. So your code can be: int main() {

Re: [lldb-dev] How to load symfile when using debugger.CreateTarget?

You shouldn't have to specify it if spotlight can see your .dSYM file if you are on a mac. But it would be nice to have an API way to do this. The only way right now is to call the SBTarget::AddModule(...) function, but that won't correctly set the executable file and/or arch for the target corr

Re: [lldb-dev] Rust support in LLDB, again

> On Oct 20, 2019, at 5:30 PM, Vadim Chugunov wrote: > > On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton > wrote: > Yeah this is a tough tradeoff as this is what GDB does or at least did the > last time I was working on it. In most debuggers, they make up their own >

Re: [lldb-dev] Rust support in LLDB, again

> On Oct 17, 2019, at 11:42 PM, Vadim Chugunov wrote: > > Hi Greg, > > So if Rust doesn't use clang in its compiler > - create a new TypeSystem for Rust that would convert DWARF into Rust AST > types that are native to your Rust compiler that uses as much of the Rust > compiler sources as po

Re: [lldb-dev] Rust support in LLDB, again

> On Sep 28, 2019, at 4:00 PM, Vadim Chugunov via lldb-dev > wrote: > > Hi, > Last year there was an effort led by Tom Tromey to add Rust language support > into LLDB. He had implemented a fairly complete language plugin, however it > was not accepted into mainline because of supportability

Re: [lldb-dev] printf works under lldb but not otherwise

The only thing I can think if is stdin/out/err are not setup correctly when launched out of the debugger. How does your program get launched? From a terminal on the command line? printf will call fprintf() under the covers with stdout as the file handle. Maybe "stdout" can be checked for NULL w

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

> On Sep 12, 2019, at 7:33 PM, Adrian Prantl wrote: > > > >> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein > > wrote: >> >> >> >> On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl > > wrote: >> >> >> > On Sep 12, 2019, at 2:24 PM, Rocky Ber

Re: [lldb-dev] Any plan to support to debug Webassembly file?

> On Sep 9, 2019, at 7:07 AM, Terry Guo via lldb-dev > wrote: > > Hi Jim, > > Thanks for your help. I implemented a WASM file plugin under folder > Plugins/ObjectFile/WASM. Now the LLDB can make a target for .wasm file. My > .wasm file is built with clang and -g option. It does contain dwar

Re: [lldb-dev] GDB JIT interface on LLDB for Windows

> On Sep 5, 2019, at 2:07 PM, Yury Delendik via lldb-dev > wrote: > > I'm trying to locate more information about the subject. I'm working > on enabling debugging for wasmtime [1]. The wasmtime is a runtime for > WebAssembly code -- a JIT, for purpose of this discussion. Currently, > I'm succe

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

Yikes. This is how it is coded currently as we do a search by removing any decl context and then making sure all resulting strings match by starting with "A::AMethod", strip off the basename so we get "AMethod", search for all matches, and then we currently make sure the result contains "A::AMet

Re: [lldb-dev] Anybody using the GUI?

and > provide our users with something they can rely on? > > Thanks, > Jonas > > On Wed, Apr 11, 2018 at 11:47 AM Greg Clayton via lldb-dev > wrote: >> >> And yes many people I know are using this including myself. >> >>> On Apr 11, 2018, a

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

Another possibility is to have the IDE insert NOP opcodes for you when you write a breakpoint with a condition and compile NOPs into your program. So the flow is: - set a breakpoint in IDE - modify breakpoint to add a condition - compile and debug, the IDE inserts NOP instructions at the right p

Re: [lldb-dev] Threading model for Python API

> On Aug 5, 2019, at 9:20 AM, Christian Biesinger wrote: > > OK thanks! (If I try to get, for example, the local variables while > the process is running, will that fail or "succeed" in a weird way?) You will get an empty list. But if you get the list of variables on thread 1, then thread 2 c

Re: [lldb-dev] Threading model for Python API

The API is thread safe, but you can run into interesting issues if you don't thread things right. You don't want one thread stepping and another thread resuming. It will work, but you probably will have a tough time figuring out why certain functions return certain values. Also, you don't want o

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

Maybe https://reviews.llvm.org/D65163 will fix this issue? > On Jul 23, 2019, at 11:57 AM, Ted Woodward wrote: > > 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

Re: [lldb-dev] "error: summary string parsing error" on Fedora 30

> On Jul 22, 2019, at 1:53 PM, Bob Eastbrook wrote: > > On Mon, Jul 22, 2019 at 1:19 PM Greg Clayton wrote: > >>> Apparently the versions which ship with Ubuntu 19.04 and Fedora 30 differ >>> with respect to this flag. >> >> So are you saying "-glldb" is wrong on Fedora but "-fno-limit-debu

Re: [lldb-dev] Cannot use system debugserver for testing

I believe you can run a shell command as root: $ sudo /usr/sbin/DevToolsSecurity --enable Then you should be able to debug after that, even on ssh connections. Greg > On Jul 22, 2019, at 12:31 PM, Frédéric Riss via lldb-dev > wrote: > > > >> On Jul 22, 2019, at 10:14 AM, Gábor Márton >

Re: [lldb-dev] "error: summary string parsing error" on Fedora 30

> On Jul 22, 2019, at 1:15 PM, Bob Eastbrook wrote: > > On Fri, Jul 19, 2019 at 4:08 PM Greg Clayton wrote: > >> Sounds like the compiler omitted the type info for std::string. Try "-glldb" >> in your compiler flags. This tunes debug info for LLDB. A lot of compilers >> will try to omit typ

Re: [lldb-dev] "error: summary string parsing error" on Fedora 30

Sounds like the compiler omitted the type info for std::string. Try "-glldb" in your compiler flags. This tunes debug info for LLDB. A lot of compilers will try to omit types from debug info if the type doesn't originate in the current executable. std::string would be one of those classes. If th

Re: [lldb-dev] Using LLDB C++ API for automated debugging sessions

> On Jul 18, 2019, at 4:00 AM, Jayvee Neumann wrote: > > Thank you for your help. > > What is the reason for using SBLaunchInfo over calling tgt.Launch with the > launch configuration as a set of parameters? The code is much clearer on what arguments mean what. In your current launch call,

Re: [lldb-dev] Type Validation and Dexter

> On Jul 15, 2019, at 5:56 AM, Tom Weaver via lldb-dev > wrote: > > Dear LLDB dev community > > I'm currently working on an open source project called DExTer. DExTer is used > to help validate and check the debugging experience a user might have when > debugging a program. The LLVM communit

Re: [lldb-dev] Needs help contributing to lldb-vscode.

Fine to refactor any way that makes it easier for people to re-use or add new VS Code DAP plug-ins! I agree with all comments so far. Greg > On Mar 13, 2019, at 12:50 AM, Pavel Labath via lldb-dev > wrote: > > On 12/03/2019 20:34, Leonard Mosescu via lldb-dev wrote: >> Greg, what do you think

Re: [lldb-dev] Symbol Server for LLDB

This is currently handled in each Platform subclass. The only platform that has the ability to locate symbol automatically are the Darwin platforms and those use DebugSymbols.framework to locate the symbols. That being said, I have been thinking about doing this in a generic way that would work

  1   2   3   4   5   6   7   >