Re: [lldb-dev] Accessing attached process environment variables with SBAPI

The SBEnvironment classes and the setting for the environment are currently used just for launching processes. lldb doesn’t keep track of the “live” state of the environment in a process - which can change as the program runs. It would certainly be useful to have a “printenv” function in lldb

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

> 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 then. I'll fire up my sed scripts. > > On 20/01/2022 01:38, Greg Clayton wrote: >> On Jan 19, 2022, at 6:40 AM, Pavel Labath wr

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] Source-level stepping with emulated instructions

“should stop here” machinery to do what you want. Jim > On Jan 18, 2022, at 10:28 AM, Jim Ingham via lldb-dev > wrote: > > > >> On Jan 16, 2022, at 11:23 PM, Pavel Labath wrote: >> >> Hi Kjell, >> >> if you say these instructions are similar to

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

> On Jan 16, 2022, at 11:23 PM, Pavel Labath wrote: > > Hi Kjell, > > if you say these instructions are similar to function calls, then it sounds > to me like the best option would be to get lldb to treat them like function > calls. I think (Jim can correct me if I'm wrong) this consists of

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

You are really going to make a lldb_private::CompilerType, since that’s what backs the Type & ultimately the SBTypes. There’s a self-contained example where we make a CompilerType to represent the pairs in the synthetic child provider for NSDictionaries in the function GetLLDBNSPairType in NSD

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

nd, or integrated into the existing process/thread continue > commands. (thread continue --signal SIGFOO => "continue with SIGFOO"; thread > continue --siginfo $47 => continue with siginfo in $47 ???) > > pl > > On 12/01/2022 01:07, Jim Ingham via lldb-dev wrote

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

This sentence makes no sense, it was a remnant of a previous draft, which included the option to do: (lldb) platform write —field name —value expression —field other_name —value other_expression But that would require people to quote their expressions to get them past the command parser, which

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

I would not do this with the expression parser. First off, the expression parser doesn’t know how to do anything JIT code that will run directly in the target. So if: (lldb) expr $signinfo.some_field = 10 doesn’t resolve to some $siginfo structure in real memory with a real type such that cla

Re: [lldb-dev] connecting lldb to a qemu system-mode session.

You want the gdb-remote command. lldb has an apropos command, so for instance: (lldb) apropos remote The following commands may relate to 'remote': gdb-remote -- Connect to a process via remote GDB server. If no host is specifed, localhost is assumed.

Re: [lldb-dev] [llvm-dev] 13.0.0-rc1 has been tagged

Once again we see the elegance of C++ never failing to impress... I wonder if it wouldn't be simpler to make a copy constructor that just makes a new mutex. The ThreadPlanStack is a vector of ThreadPlan shared pointers, so it is cheap to copy, and the stack just uses the mutex internally, so ma

Re: [lldb-dev] [llvm-dev] 13.0.0-rc1 has been tagged

That is certainly an odd chain of includes to end up complaining about ThreadPlanStacks... ABIMacOSX.cpp does see the definition of ThreadPlanStacks but not along that path... Something got fairly confused. There IS an implicitly deleted copy constructor for ThreadPlanStacks, but it doesn't g

Re: [lldb-dev] Should MyType's synthetic provider be instantiated for MyType* and MyType** ?

> On Jul 19, 2021, at 6:24 PM, Vadim Chugunov wrote: > > > > On Mon, Jul 19, 2021 at 6:02 PM Jim Ingham wrote: > You can control whether you want data-formatters on "class Foo" to also match > "class Foo *" and "class Foo &" using the --skip-pointers and > --skip-references options respect

Re: [lldb-dev] Should MyType's synthetic provider be instantiated for MyType* and MyType** ?

You can control whether you want data-formatters on "class Foo" to also match "class Foo *" and "class Foo &" using the --skip-pointers and --skip-references options respectively. So this part is clearly is by design. As for what the formatter gets passed, your formatter has chosen to see values

Re: [lldb-dev] eStateInvalid handling in ProcessGDBRemote::AsyncThread...

Can't type acronyms. SBPAWFR should be SCPAWFR, dunno why I got one letter too eager... Jim > On Apr 28, 2021, at 7:20 PM, Jim Ingham via lldb-dev > wrote: > > I have a question about the handling of SendContinuePacketAndWaitForResponse > when an attempt to interrupt t

[lldb-dev] eStateInvalid handling in ProcessGDBRemote::AsyncThread...

I have a question about the handling of SendContinuePacketAndWaitForResponse when an attempt to interrupt the process times out. One oddity I noticed is in the handling of the eStateInvalid return from SendContinuePacketAndWaitForResponse (in ProcessGDBRemote::AsyncThread). When there's an asy

Re: [lldb-dev] What is the difference between an Arch and a Triple

The fix is in: https://reviews.llvm.org/D95164 but without any doc verbiage. Jim > On Jan 21, 2021, at 12:04 PM, Jim Ingham via lldb-dev > wrote: > > We have two API's: > > SBDebugger.CreateTargetWithFileAndTargetTriple > SBDebugger.CreateTargetWithFileAndArch &

[lldb-dev] What is the difference between an Arch and a Triple

We have two API's: SBDebugger.CreateTargetWithFileAndTargetTriple SBDebugger.CreateTargetWithFileAndArch Both take a path and a string. Currently, their implementations are almost identical, the major difference being that the first one ignores the error from target creation, but I don't think

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

> On Oct 7, 2020, at 5:29 PM, Greg Clayton wrote: > > > >> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> >> >>> On Oct 7, 2020, at 12:11 PM, Pavel Labath >> <mailto

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

> 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 >> <mailto:pa...@labath.sk>> wrote: >>> >>> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote: &g

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

> On Oct 7, 2020, at 11:44 AM, Pavel Labath wrote: > > On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote: >> There isn’t a built-in summary formatter for two dimensional arrays of >> chars, but the type is matching the regex for the one-dimensional >> StringSumm

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

There isn’t a built-in summary formatter for two dimensional arrays of chars, but the type is matching the regex for the one-dimensional StringSummaryFormat, but that doesn’t actually know how to format two dimensional arrays of chars. The type regex for StringSummaryFormat: char [[0-9]+] We

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

> On Jul 23, 2020, at 5:15 AM, Pavel Labath wrote: > > On 22/07/2020 01:31, Jim Ingham wrote: >> >> >>> On Jul 21, 2020, at 9:27 AM, Pavel Labath >> > wrote: >>> I do see the attractiveness of constructing of a full compiler type. The >>> reason I am hesitant to go tha

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

> On Jul 23, 2020, at 1:51 AM, Pavel Labath wrote: > > On 22/07/2020 19:50, Jim Ingham wrote: >>> On Jul 22, 2020, at 12:34 AM, Pavel Labath wrote: >>> >>> The "--" is slightly unfortunate, but it's at least consistent with our >>> other commands taking raw input. We could avoid that by makin

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

, though I do find the idea of beefing up the "b" command > more appealing. > > On 22/07/2020 00:03, Jim Ingham via lldb-dev wrote: >> >> >>> On Jul 21, 2020, at 2:54 PM, Greg Clayton >> <mailto:clayb...@gmail.com>> wrote: >>> >&

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

> On Jul 22, 2020, at 9:57 AM, Dave Lee wrote: > > On Tuesday, July 21, 2020, Jim Ingham via lldb-dev <mailto:lldb-dev@lists.llvm.org>> wrote: > I think adding: > > bs (break source) -> break set -y > ba (break address) -> break set -a > bn (break nam

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] Break setting aliases...

> On Jul 21, 2020, at 2:54 PM, Greg Clayton wrote: > > > >> 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 u

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

o make things a little better w/o signing up for making “_regex_break” work better which I don’t have any intention of doing personally... Jim > > > On Tue, Jul 21, 2020 at 10:22 AM Jim Ingham via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > When we were first de

[lldb-dev] Break setting aliases...

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 possible as we evolved, and I also wanted to make sure we weren’t taking up all the

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

; On Jul 20, 2020, at 2:25 PM, Jim Ingham via lldb-dev > 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 up

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

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 up a complete type in the ScratchASTContext, and then use the underlying TypeSystem to do the layout comp

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

o check "target_event_mask" > against "target_mask" and "process_event_mask" against "process_mask". Most particularly, lldb doesn’t currently allow multiple listeners for the SBProcess StateChanged event. If you aren’t the creator of a process, don’t l

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

Did you try getting the broadcaster class from SBTarget (SBTarget::GetBroadcasterClassName) and then in your Listener call StartListeningForEventClass? When you listen to an Event Class you get signed up for events for each new object of that class as it gets created. Jim > On Jun 23, 2020,

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

On iOS, every time a device that is provisioned for debugging is plugged in, the device management stack checks to see if it knows the OS on the device and if not copies the libraries from the system to the host and puts them in a location that lldb can find. That shouldn’t be a big job if the

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

> On Apr 30, 2020, at 12:43 PM, Vangelis Tsiatsianas via lldb-dev > wrote: > > Thank you for the answer, Greg. > > I personally managed to work around the problem, although it confused me a > bit at first and took a while to figure out the cause. May I suggest the > addition of a note in th

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

A breakpoint doesn’t necessarily have a file & line number. Remember that breakpoints in lldb really are “search kernels” - called “Resolvers" and one breakpoint’s resolver can match any number of locations in code. As an extreme instance “break set -r .*” will match many many functions… So t

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

Definitely a bug. ValueObjectSynthetic overrides both GetChildMemberWithName and GetIndexOfChildWithName so that if you have a synthetic value, it will look in the synthetic children to match the name, not in the underlying value's type. Not sure why this isn’t working. Jim > On Apr 7, 202

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

Re: [lldb-dev] LLDB problem with TAB

It sounds like you aren’t getting completion anywhere, both in the python interpreter and in the regular lldb command line interpreter, is that right? If so, then it’s most likely you didn’t get link with libedit, which is what provides the tab completion, command line editing and the like. Yo

Re: [lldb-dev] I wanna work on the open project "Add support for batch-testing to the LLDB testsuite."

Glad to hear from you. I am: jing...@apple.com Jim > On Mar 3, 2020, at 10:11 AM, SREENIVASA SUMADITHYA - IIITK via lldb-dev > wrote: > > I wanna work on the open project "Add support for batch-testing to the LLDB > testsuite." for google summer of code > Can I get more details on that? >

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

:10 AM, Jim Ingham via lldb-dev > wrote: > > BTW, I think the better way to handle this in lldb is not to move the PC past > the trap when you stop, but that when CONTINUING past a trap that we don't > recognize, we always make sure we start past the trap. That way it w

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

BTW, I think the better way to handle this in lldb is not to move the PC past the trap when you stop, but that when CONTINUING past a trap that we don't recognize, we always make sure we start past the trap. That way it won't look weird when people compare crash logs coming from hitting a trap

Re: [lldb-dev] Continuing from dbgtrap on different targets

As you have seen, different machine architectures do different things after hitting a trap. On x86_64, the trap instruction is executed, and then you stop, so the PC is left after the stop. On arm64, when execution halts the pc is still pointing at the trap instruction. I don't think lldb sho

Re: [lldb-dev] Force format for frame variable using type summary is not working as expected.

The way lldb works, char[] has a type summary that does two things, 1) presents the contents as a C-string, and 2) suppresses the actual printing of the elements. If it hadn't done (2) then you would have seen the elements formatted as a vector of char's with the format you specified. OTOH (2)

[lldb-dev] Reporting the results of "thread select"

We were seeing an ASAN failure in a simple Lit test somebody here was writing. The failure was that the "thread backtrace" command was accessing freed memory dereferencing a VariableSP it got from the VariableList of a Block. Turns out that the VariableList class has no locking, and backtrace

[lldb-dev] https://reviews.llvm.org/D71440

I rewrote the test case source file for TestExprDoesntBlock.py so that it uses std::thread rather than pthreads. So that test case should at least compile on Windows, and so I prospectively removed the Windows xfail from the test. But I don’t actually know how well suspending & resuming thread

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

> On Dec 10, 2019, at 3:11 AM, Pavel Labath via lldb-dev > wrote: > > On 09/12/2019 18:27, Jonas Devlieghere wrote: >> On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath wrote: >>> >>> I think this would be a very interesting project, and would allow us to >>> flesh out the details of the script in

Re: [lldb-dev] Setting environment via SBLaunchInfo

> On Dec 2, 2019, at 4:08 PM, Vadim Chugunov wrote: > > > But I don't think passing lldb's environment variables automatically when > > running a remote process is a sensible thing to do - certainly not as the > > default anyway. If the host and target are different OS'es and maybe > > diff

Re: [lldb-dev] Setting environment via SBLaunchInfo

There's a setting (target.inherit-env) that controls whether "process launch" passes its environment variables along with any newly set to the process in question. Sounds like there should also be an lldb.eLaunchFlagInheritEnv that triggers the same behavior from the SB API. But I don't think

Re: [lldb-dev] Setting breakpoint on file and function name doesn't work as expected.

> On Nov 8, 2019, at 1:53 AM, Konrad Kleine wrote: > > Jim, > > thank you for the explanation. I'm trying to see the situation more from an > end user's perspective. When --file or -f have two different meanings > depending on how they are combined, that's bad IMHO. I don't think that it is

Re: [lldb-dev] Setting breakpoint on file and function name doesn't work as expected.

Note first, "break set -f foo.c -l 10" and "break set -f foo.c -n bar" are two very different breakpoints. In the first case, we are looking for a specific file & line combination in the line table or inlined functions info. In the latter case we are searching for a function names bar, and the

Re: [lldb-dev] https://reviews.llvm.org/D69273

Sorry, my brain is not working this morning, I answered your question in the review comments… Jim > On Nov 4, 2019, at 7:28 AM, Pavel Labath wrote: > > On 31/10/2019 20:51, Jim Ingham via lldb-dev wrote: >> It looks like this change is causing problems with swift. I was talki

[lldb-dev] https://reviews.llvm.org/D69273

It looks like this change is causing problems with swift. I was talking a little bit with Davide about this and it seems like it wasn't obvious how this was designed to work. So here's what this was intended to do (apologies if this is at too basic a level and the issue was something deeper I

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

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

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

Except of course without the comment markers... > On Oct 30, 2019, at 11:36 AM, Jim Ingham wrote: > > 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(

[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

Re: [lldb-dev] Custom arguments completion for commands created by LLDB plugins

> On Oct 7, 2019, at 3:35 AM, Raphael “Teemperor” Isemann via lldb-dev > wrote: > > To my knowledge there is no way to have completions for custom commands. If > you just want completions for nested commands (e.g., having a “custom add” > and “custom remove” commands and want completions for

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

> On Oct 1, 2019, at 11:54 AM, Vadim Chugunov via lldb-dev > wrote: > > > Unless my memory is failing me, I don't think we ever explicitly > > rejected Rust's language plugin. We removed a few other language > > plugins (Go, Java) that were not maintained and were becoming an > > increasing bu

Re: [lldb-dev] How to debug a child process ?

> On Sep 30, 2019, at 5:05 PM, Peter Rowat via lldb-dev > wrote: > > I have a process P1 that forks a child process P2. Both have graphic > displays, P2 is an animation depending on data from P1. > P2 suddenly disappears at a time that is never the same as any previous run. > > I use lldb to

Re: [lldb-dev] Stepping in a breakpoint callback with Python

So the problem you are having is getting the scripted step started in "trace" with the SBThread::StepUsingScriptedStep? Did you try passing False for "resume_immediately" and then returning False from "trace". The explanation for: # XXX: Doesn't seem to matter with 'thread step-scripted

Re: [lldb-dev] Stepping in a breakpoint callback with Python

Nikita, There was a lot of other stuff in that scripted_step.py beyond the plan class itself. I didn't follow what that did altogether. But if I removed all that stuff, and changed your plan slightly to not rely on the global TARGET and START_ADDRESS (I attached my simplified version below),

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

Right. If you watch the lazy binding that happens the first time a symbol is called - at least on macOS - the loader does a lot of work, and calls various standard library functions and helper functions in its own library that aren't in any real sense trampolines. Actually, objc_msgSend can do

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

he ways to decide a frame should be elided. But that should just be one pattern we look for, not the way we implement the feature. Jim > On Sep 25, 2019, at 5:51 AM, paul.robin...@sony.com wrote: > > > >> -Original Message- >> From: lldb-dev [mailto:lldb-dev-boun

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

> On Sep 24, 2019, at 11:36 AM, Nat! via lldb-dev > wrote: > > > > On 24.09.19 19:28, Jim Ingham wrote: >> We've had many requests to elide some classes of entries in backtraces - >> like to mirror the Xcode display I mentioned previously. Most of these >> requests don't depend on the fun

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

We've had many requests to elide some classes of entries in backtraces - like to mirror the Xcode display I mentioned previously. Most of these requests don't depend on the functions being marked artificial. So if we're going to do this, something more general than just "marked artificial" ->

Re: [lldb-dev] Stepping in a breakpoint callback with Python

> On Sep 21, 2019, at 11:11 AM, Nikita Karetnikov wrote: > > Jim, > > > My model for this sort of tracing activity is that you are writing a fancy > > kind > > of “step” operation. You would write a fancy step & record plan that would > > proceed along however you wanted and log at each stop

Re: [lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

At some point it would be good to add trampoline support at the Python level. You can produce scripted thread plans now - and the trampoline mechanism just returns a thread plan to step through the trampoline... It would be neat to be able to support other systems without having to build them

Re: [lldb-dev] Stepping in a breakpoint callback with Python

lldb doesn’t currently support breakpoint callbacks that try to control running the target in the callback. I’m not sure how easy it would be to support that reliably, but anyway, that doesn’t work at present. My model for this sort of tracing activity is that you are writing a fancy kind of “

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

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 l

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

You would need to implement an ObjectFile and SymbolFile plugin for your .wasm files for lldb to make a Target for them. Jim > On Aug 26, 2019, at 6:27 PM, Terry Guo via lldb-dev > wrote: > > Hi Raphael, > > Thanks for your recommendation. How about the very first step which > enables LLDB

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

The GUI is built into lldb, it is not a separate entity. Jim > On Aug 26, 2019, at 12:39 PM, René J.V. Bertin via lldb-dev > wrote: > > On Monday August 26 2019 11:18:28 Raphael “Teemperor” Isemann via lldb-dev > wrote: > >>> On 25. Aug 2019, at 02:02, Greg Clayton via lldb-dev >>> wrote:

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

From what I can tell the main thing this is missing is a Console window. I imagine hosting a full console window inside a ncurses sub window would be a pain if there isn't a pre-built widget for that. But maybe it would be easier to open another terminal window and connect the debuggers I/O ch

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

> On Aug 20, 2019, at 3:30 AM, Tamas Berghammer via lldb-dev > wrote: > > It is great that you are looking at supporting these fast breakpoints > but I am concerned about the instruction moving code along the same > lines Pavel mentioned. Copying instructions from 1 location to another > is fa

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

> On Aug 15, 2019, at 11:55 AM, Pavel Labath wrote: > > On 15/08/2019 20:15, Jim Ingham wrote: >> Thanks for your great comments. A few replies... >>> On Aug 15, 2019, at 10:10 AM, Pavel Labath via lldb-dev >>> wrote: >>> I am wondering whether we really need to involve the memory allocation

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

Thanks for your great comments. A few replies... > On Aug 15, 2019, at 10:10 AM, Pavel Labath via lldb-dev > wrote: > > Hello Ismail, and wellcome to LLDB. You have a very interesting (and not > entirely trivial) project, and I wish you the best of luck in your work. I > think this will be a

Re: [lldb-dev] Who sets the 10-minute timeouts?

I don't know where the windows bot output is... Which tests are timing out? Maybe you ought to skip those tests on Windows for now to reduce the noise? Jim > On Aug 14, 2019, at 4:14 PM, Adrian McCarthy wrote: > > > > On Wed, Aug 14, 2019 at 2:47 PM Jim Ingham wrote: > > > > On Aug

Re: [lldb-dev] Who sets the 10-minute timeouts?

> On Aug 14, 2019, at 1:41 PM, Adrian Prantl via lldb-dev > wrote: > > > >> On Aug 14, 2019, at 11:26 AM, Adrian McCarthy via lldb-dev >> wrote: >> >> A recent change is causing several LLDB tests on Windows to fail and several >> more to time out, which I intend to look into. >> >> It

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

IIUC an llvm::Expected is only supposed to abort if you leave its scope with an un-consumed error. LLDB_LOG_ERROR is supposed to consume the error - the code looks like it is doing that. So if you are still seeing an abort when there's an error, then it sounds like something is wrong with LLDB

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

Is this in the on-line docs somewhere? Jim > On Aug 8, 2019, at 12:49 PM, Jonas Devlieghere via lldb-dev > wrote: > > 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. >

Re: [lldb-dev] STABS

Amplifying Fred's comments: Most of the code in ParseSymtab is parsing the nlist records in the binary. Only a tiny subset of those nlist records are "stabs". Most are just the format by which MachO expresses its symbol table. So all that needs to be there. Over the past couple of years, th

Re: [lldb-dev] Evaluate expression for template class

> On Jul 24, 2019, at 7:23 AM, Scott Funkenhauser > wrote: > > I've tried with LLVM 4, 7 and 8. They all fail to evaluate 'sizeof(foo)'. > The fundamental problem is that DWARF doesn't represent templates per se. It only represents template instantiations. So there's nothing in the debug

Re: [lldb-dev] Evaluate expression for template class

Interesting... What lldb & clang were you using? With current TOT clang & lldb I see: (lldb) run Process 83732 launched: '/tmp/template2' (x86_64) Process 83732 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x00010fad template2`main at

Re: [lldb-dev] Evaluate expression for template class

lldb can't currently create new template instantiations. It can only access ones that were generated in the binary you were debugging. The debug information doesn't have any code, so we can't create new instantiations from there. Having the debugger try to include headers into the expression

Re: [lldb-dev] queue-name parameter

I already filed both of these issues with Apple. If you want to file them too, feel free. I'll dup them to the ones I filed but that way you will get notification when they get fixed. These are also general lldb issues, so it would be good to file something with http://bugs.llvm.org. Jim >

Re: [lldb-dev] queue-name parameter

Fernando, I don't see quite what you do. For me, -Q never sets the queue. Rather, the current Xcode version of lldb seems to have a bug where it doesn't reject illegal options, so the -Q argument is silently discarded. That would cause the breakpoint to "work" but it won't only stop on one qu

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

The main problem with trying to run a debug session multithreaded is coordinating execution control. Thread A gets a variable list and iterates over it to get child values. Thread B issues a "step" command. The API's thread A calls will either fail (because the target is running) or maybe fet

Re: [lldb-dev] issue with StackFrame::GetSymbolContext

A "raw image" is one that loads all the code at some address and doesn't have a dynamic loading mechanism. So it really just means "a binary that doesn't use a dynamic loader." I'm not sure why it was called "Strata"... But the Strata is used to disambiguate cases where the object file format

Re: [lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps

lldb realizes types from DWARF lazily. So for instance, if an expression refers to a pointer to type Foo, we won't necessarily realize the full type of Foo from DWARF to parse that expression. Then if you write a second expression that accesses a member of an object of type Foo, we will realiz

Re: [lldb-dev] issue with StackFrame::GetSymbolContext

It looks like you don't have a DynamicLoader plugin that tells lldb where your binaries ended up in memory when the process ran. The [ADDRESS] means we are reading instructions from memory not from the on-disk binary. Jim > On Jul 9, 2019, at 2:14 AM, Romaric Jodin via lldb-dev > wrote: >

Re: [lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps

Are any sources for symbols getting added to the process as you go along, like new shared library loads? You are asking for a non-existent name, so every new source of debug info is a new place to look. It's also possible that we are completing some types during the course of the expression ev

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

> On Jul 2, 2019, at 11:52 AM, Vangelis Tsiatsianas > wrote: > > I would like to leave it as a suggestion for the future, just in case the > need for such a mechanism arises in other places within LLDB or for plugins. File an enhancement request with bugs.llvm.org, otherwise it will get lost

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

There isn't a general mechanism for external clients to watch settings changes. But IMO, it would be appropriate for the setter for the target.process.thread.trace-thread set function to go do this work. Having an explicit relationship between setting the setting and changing state in the thr

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

We use http://reviews.llvm.org Click on the Favorites:Differential side bar item, and then on Create Diff in the URH Corner of the window. If you make your diff with: svn diff --diff-cmd=diff -x -U99 or the git equivalent, then they are much easier to review. Once you have the diff, sele

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

Stop hooks only trigger when control is about to be returned to the user. And in its normal mode, lldb doesn't step instruction all the time anyway... So I don't think they would do what Vangelis wants. He would have to drive the debugger with only the step-instruction command, which I think

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

By default, the SB API's run in "asynchronous" mode, where calls that cause the target to run (launch, continue, etc) return when the target has started running, and then you have to wait on the listener that you registered with the process when you launched it to get notified of state changes.

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

> On May 16, 2019, at 2:24 AM, Pavel Labath wrote: > > On 16/05/2019 01:10, Jim Ingham via lldb-dev wrote: >> When you add to them you are often adding some larger feature which would >> have required a rebuild anyway, and they go long times with no change... I &g

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

t;> included into an array of translation units >>> b) Having each file contain the forward declarations it needs from the >>> project and no more also will help both compile time and understanding >>> what's used in any particular header. >>> >>> As

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

elp both compile time and understanding >> what's used in any particular header. >> >> As a related exercise: >> >> https://twitter.com/echristo/status/1116609586004316160 >> >> basically has removing a couple of transitive dependencies saving in >

  1   2   3   4   5   >