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

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

[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

[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

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)

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

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

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

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

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

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

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

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

> 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] 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] 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] dosep.py is not running any tests on MacOSX...

> On Aug 11, 2015, at 2:19 PM, Zachary Turner via lldb-dev > wrote: > > Whew, I had checked in something yesterday that I was worried might have > broken something, so I was frantically doing a rebuild to see if it was me. > > Side question: This isn't the first time I've seen you call it "de

Re: [lldb-dev] [RFC] Simplifying logging code

The previous discussion (with patch) was here: http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20150427/018839.html Jim > On Aug 12, 2015, at 6:11 AM, Vince Harron via lldb-dev > wrote: > > We could solve booth the efficiency concerns and the conciseness with a > macro. (Gasp!)

Re: [lldb-dev] Test suite rebuilding test executables many times

It is fairly common practice (at least it is for me) when figuring out why a test failed, or adding to a test case, or when looking for a good example file to poke at, etc, to go to some relevant test directory, do a "make" then poke around a bunch. I don't generally remember to clean when I'm

Re: [lldb-dev] Test suite rebuilding test executables many times

That seems fair. It would be great to have some higher level mechanism to generate runs of the tests that only differ by how the target programs are built. For instance, if some day we ever get serious about optimized code debugging (suppresses giggle) it would be good to run the test suite on

Re: [lldb-dev] How does attach work on non-Windows?

On OS X and most Unixes, you call ptrace(pid, PT_ATTACH) or some procfs call to initiate the attach, and then wait on the pid until it comes back with a SIGSTOP signal when the attach is completed. How the wait is done differs from system to system, but this is the general model. I have not he

Re: [lldb-dev] How does attach work on non-Windows?

There is a way on OS X. There is a sysctl that will give you information on the current process state, and one of the bits you get back says whether the process is being traced. sysctl's are a generic UNIX thing, but I don't know if the bit OS X uses is shared with other Unix's. Jim > On Aug

Re: [lldb-dev] How does attach work on non-Windows?

There's even a Tech Note for how to do this: https://developer.apple.com/library/ios/qa/qa1361/_index.html I think you should be able to see that w/o a developer account, but if you can't, here's the code: #include #include #include #include #include static bool AmIBeingDebugged(void)

Re: [lldb-dev] Portable tests that create threads

> On Sep 2, 2015, at 1:06 PM, Greg Clayton via lldb-dev > wrote: > > One idea is add the ability to discover which of any of the current threads > are or are not user created. This might help us. > > On MacOSX, the main thread would always be considered user created, and any > other thread,

Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges

Certainly a bug. This bit: if (inlined_die) { Block &function_block = sc.function->GetBlock (true); sc.block = function_block.FindBlockByID (inlined_die.GetID()); if (sc.block == NULL) sc.block = function_block.FindBlockByID (in

Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges

Ah, okay. For a while the llvm-dsymutil folks were trying to make the output of dsymutil & llvm-dsymutil identical so that they could be sure llvm-dsymutil was doing the right thing, so I'm a little surprised the two differ in this regard. But if it works with .o files & llvm-dsymutil I think

Re: [lldb-dev] Testing through api vs. commands

I have held from the beginning that the only tests that should be written using HandleCommand are those that explicitly test command behavior, and if it is possible to write a test using the SB API you should always do it that way for the very reasons you cite. Not everybody agreed with me at f

Re: [lldb-dev] Testing through api vs. commands

> On Sep 11, 2015, at 11:47 AM, Zachary Turner wrote: > > We'll probably rewrite tests that we find are failing specifically as a > result of issues like this, but I agree it's not worth re-writing everything > else except on an as-needed basis. > > To make the distinction explicit and enforc

Re: [lldb-dev] Testing through api vs. commands

> On Sep 11, 2015, at 11:47 AM, Zachary Turner wrote: > > We'll probably rewrite tests that we find are failing specifically as a > result of issues like this, but I agree it's not worth re-writing everything > else except on an as-needed basis. > > To make the distinction explicit and enforc

Re: [lldb-dev] Testing through api vs. commands

> On Sep 11, 2015, at 12:49 PM, Zachary Turner wrote: > > Sounds good. I think perhaps one reason a lot of tests are written using the > commands is because not all functionality available through commands is > available through the SB API. Adrian is working on creating some tests for > cor

Re: [lldb-dev] Testing through api vs. commands

> On Sep 15, 2015, at 4:23 PM, d...@burble.org wrote: > > I do still think we need some tests that verify commands run, but I think > those tests should focus not on doing complicated interactions with the > debugger, and instead just verifying that things parse correctly and the >

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

Did you try waiting for an event on the listener you've passed to AttachToProcess? The last event after everything is done should be the notification to the public listener (i.e. your test_listener) that the process you attached to has stopped, and nobody is fetching that. Jim > On Sep 16, 20

Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

That is intended behavior. MischiefManaged is called when an stop propagates to that plan, and it needs to decide whether it is done or not. That’s not what happens when somebody decides to discard the plan. WillPop will get called if you need to do some cleanup when the plan gets popped. Wa

Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

> On Sep 23, 2015, at 6:39 PM, d...@burble.org wrote: > > On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote: >> We currently coalesce breakpoints to avoid the user stopping multiple times >> on the same source line. This might have been done to avoid stepping issues >> we might have

Re: [lldb-dev] Testing through api vs. commands

> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev > wrote: > > > > On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote: > > > > On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev > > wrote: > > > > Jim, Greg, > > > > Can I get some feedback on this? I would like to start e

Re: [lldb-dev] Testing through api vs. commands

> On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote: > >> >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev >> wrote: >> >> >> >> On Wed, Oct 7, 2015 at 10:17 AM Greg Clayton wrote: >> >> >>> On Oct 7, 2015, at 10:05 AM, Zachary Turner via lldb-dev >>> wrote: >>> >>> Jim, Greg,

Re: [lldb-dev] Testing through api vs. commands

> On Oct 7, 2015, at 11:40 AM, Zachary Turner wrote: > > > > On Wed, Oct 7, 2015 at 11:26 AM Jim Ingham wrote: > > > On Oct 7, 2015, at 11:16 AM, Jim Ingham wrote: > > > >> > >> On Oct 7, 2015, at 10:37 AM, Zachary Turner via lldb-dev > >> wrote: > >> > >> > >> > >> On Wed, Oct 7, 2015 at

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

Does it only happen for InferiorCallMmap, or does an expression evaluation that crashes in general set a bad signal on resume? I don't see this behavior in either case on OS X, so it may be something in the Linux support. Be interesting to figure out why it behaves this way on Linux, so whatev

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

> On Oct 7, 2015, at 4:06 PM, Eugene Birukov wrote: > > Even on Linux call to InferiorCallMmap does not fail consistently. In many > cases it survives. I just happened to have 100% repro on this specific > breakpoint in my specific problem. I.e. the burden of investigation is on me, > since I

Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

> On Oct 7, 2015, at 4:39 PM, d...@burble.org wrote: > > On Mon, Oct 05, 2015 at 03:01:28PM -0700, Jim Ingham wrote: >> >> Given that, the best lldb can do is use heuristics, and the best heuristic I >> had was Block == basic block??? > > Can you at least check for branches then? (Yes, that

Re: [lldb-dev] Process stops when two breakpoint are hit simulatenously, even though neither of them wants to stop

> On Oct 8, 2015, at 1:03 AM, Keno Fischer via lldb-dev > wrote: > > Hi folks, > > I'm using the C++ API to create a breakpoint with callback. In the callback I > do some stuff and then always return false, to have the process continue. > This works great, except when a breakpoint hit is coi

Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

> On Oct 7, 2015, at 5:07 PM, Jim Ingham wrote: > > Another way to do this - which I thought about originally but rejected as too > much delicate machinery for the desired effect - is to add the notion of > "clusters" of locations to the breakpoint. Instead of eliding all the > segments with

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

it there. I recommend to try the master > > branch, I think this should work for you now (and do let me know if > > the problem persists). > > > > pl > > > > On 8 October 2015 at 00:20, Jim Ingham via lldb-dev > > wrote: > > > > > >> On

Re: [lldb-dev] Accessing DWARF information from C++

> On Oct 13, 2015, at 9:03 AM, Stefan Kratochwil via lldb-dev > wrote: > > Hi, > > well, I found the llvm-dwarfdump tool in the tools directory *facepalm*... > I'll use that as a reference. > > That leaves the question about the two separate DWARF implementations. Ideally it would be good to

Re: [lldb-dev] Refactoring dotest as a Python package

It seems like everybody is okay with the idea of this, so I don't see the need for a review of the details of this stage. If you think there's anything tricky call it out in words, otherwise I say just commit it. Jim > On Oct 27, 2015, at 4:30 PM, Zachary Turner via lldb-dev > wrote: > > I

<    1   2   3   4   5