Re: [lldb-dev] review for crash patch to gdb remote

The usual thing to do in this case is to look in the CODE_OWNERS file and see who is responsible for the area you're changing, and subscribing them to the change request. Jim > On Aug 16, 2017, at 1:49 PM, Christopher Book via lldb-dev > wrote: > > Hi, > > I posted a patch last week for a

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

No, there hasn't been a need for this. What commands are you planning to send? Or equivalently, how much state are you expecting to change? Jim > On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev > wrote: > > Hi, > Is there any way to force lldb to refresh it's internal record of d

Re: [lldb-dev] Difficulty in using target.source-map to map source files

> On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev > wrote: > > Hi All, > > Below is a sample example, where target.source-map seems to have a > limitation. The limitation seems to be because > 1. lldb does not have an equivalent command like directory in gdb The gdb "dir" comma

Re: [lldb-dev] Difficulty in using target.source-map to map source files

> On Aug 24, 2017, at 10:06 AM, karnajit wangkhem wrote: > > Hi Jim, > > Thanks for the valuable reply. Please find my comments inline. > > Regards, > Karan > > On Wed, Aug 23, 2017 at 12:32 AM, Jim Ingham wrote: > > > On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev > > wrote

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

If that’s the expectation, you have to obey it... Xcode is pretty careful to only act on the elements that were visible in a view, which made the locals view much less heavy-weight. But that took some work on their end. More to the point, this doesn’t seem to be code that should be in the MI

Re: [lldb-dev] Difficulty in using target.source-map to map source files

That will be great! Last time we were more aggressive about normalizing paths we caused a decent performance regression by normalizing all the paths every time we did a file-name compare for setting breakpoints. If you look at FileSpec::Equal we added some "is it worth doing this work" prepara

Re: [lldb-dev] Display of reference parameters

Since the address is mostly only interesting "when it goes bad" which should be infrequent, we want to have the value be the easiest thing to pick out. It's a little harder to tell in isolation, what you're really going to see is something like: A: (int) y = 33 (int) z = 33 (int &) x =

Re: [lldb-dev] Symbolic information in disassembler output

I don't think anybody thought of it as useless. It's one of the things Jason has been trying to find time to do for a while now. InstructionLLVMC is the main concrete Instruction subclass in llvm now, and relies on MCInst for most of the heavy lifting. So we should work with MCInst to figure

Re: [lldb-dev] [Lldb-commits] PTYPE replacement in LLDB

The original plan was to add a "type eval" to go alongside "type lookup". "type eval" would take an expression, evaluate it, and then print the resulting type. gdb's type takes either a type name or an expression, but there's no way to disambiguate if you have a type that has the same name as

[lldb-dev] lldb-5.0 on linux not finding lldb-server-5.0.0

Somebody on stack overflow is reporting: https://stackoverflow.com/questions/46164427/lldb-is-not-starting-an-application that they got the 5.0 tools on an Ubuntu system, and lldb is saying: error: process launch failed: unable to locate lldb-server-5.0.0 when he tries to run a process. The re

Re: [lldb-dev] Prologue instructions having line information

This is only tangential, but it is a known bug that when we stop on a line that starts an inlined block we don't pretend we're in the outer function first, so the user can "step-in" to the inlined function. This is particularly notable when you have several nested levels of inlining starting at

Re: [lldb-dev] Prologue instructions having line information

es for looking at optimized code. You’d need an > extension to the dwarf information of some kind. > > Chris > > > >> On Sep 14, 2017, at 11:29 AM, Jim Ingham via lldb-dev >> wrote: >> >> This is only tangential, but it is a known bug that when we s

[lldb-dev] I had to back out r313904, it causes lldb to assert on startup if you have a .lldbinit file

This actually asserts on any use "command source" is the one command that re-enters the command interpreter. It should be as simple as getting command source to rest the state flag before it goes to do the sourcing. I'll check that out tomorrow if nobody gets to it first. command source is on

Re: [lldb-dev] I had to back out r313904, it causes lldb to assert on startup if you have a .lldbinit file

ut to giving the user control of the session. So my feeling is "both". Jim > > > On Wed, Sep 27, 2017 at 6:46 PM, Jim Ingham via lldb-dev > wrote: > This actually asserts on any use "command source" is the one command that > re-enters the command interp

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

Just pass an invalid FileSpec for the source file spec, like: lldb.target.BreakpointCreateBySourceRegex("printf", lldb.SBFileSpec()) and it acts the same way as the --all-files option. That was pretty non-obvious, I'll update the docs. Actually, the thing you CAN'T do is get the command line b

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

Yeah, that would be easy to implement from the command line, maybe add a --file-is-regex flag or something. From the SB API it would be better to have something like: SBFileList SBTarget.GetFileListMatchingRegex("regex") Please file an enhancement request for these of hack'em in if you're so

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

r to almost everyone, no sb api options would need to be > added. > > > > On Mon, Oct 23, 2017 at 6:25 PM Jim Ingham via lldb-dev > wrote: > Yeah, that would be easy to implement from the command line, maybe add a > --file-is-regex flag or something. > > From the SB A

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

> On Oct 25, 2017, at 10:44 AM, Jim Ingham via lldb-dev > wrote: > > I have only one reservation to this plan, which is that at present I only > have one breakpoint command that shares a common set of command options. So > if we start overloading the meaning of -f, mea

Re: [lldb-dev] What's the best way to use "--all-files" option from python?

n to the -f option. >> >> On Tue, Oct 24, 2017 at 7:18 PM Don Hinton wrote: >> Do you mean just pass a pattern to the -f option or FileSpec? >> >> On Tue, Oct 24, 2017 at 6:50 PM, Zachary Turner wrote: >> It might be worth brainstorming if there’s ways to

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

The lldb_cmake GreenDragon bot is now failing, e.g.: http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e This looks related to Pavel's change: > r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines > > Defa

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

he build folder should let the new and correct default kick > in. If you run the check-lldb target then it will now use the in-tree > clang instead of the system compiler for using tests. > > sorry about the trouble, > pl > > > > On 7 November 2017 at 18:21, Jim Ingha

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

he problem went away. > > Probably a cache issue, but I was unable to reproduce... > > On Tue, Nov 7, 2017 at 10:21 AM, Jim Ingham via lldb-dev > wrote: >> The lldb_cmake GreenDragon bot is now failing, e.g.: >> >> http://lab.llvm.org:8080/green/view/LLDB/job/lldb

Re: [lldb-dev] Debugee Unable to Open Window Due to "No available video device"

Xcode (on OS X) uses the lldb API to launch processes of all sorts including ones that have widows, and has windows open, so this is not a general lldb problem. lldb doesn’t do all that much magic to launch processes, it just calls posix_spawnp (on OS X) or fork & exec on Linux. I would be s

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

Xcode and general development on macOS has moved from using headers in the base OS (/System/Library/Frameworks…) for building programs to using SDK’s to contain all the header files. The installed tools will know how to find the correct SDK. On a clean install of 10.13 there are no headers a

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

The build should be finding the version in the SDK within Xcode. I do have the CommandLineTools directory on my system, but it doesn’t have an SDK directory in it. I wonder if that is causing the problem? One thing to check, do: $ xcrun -find clang Does that find clang in the DeveloperTool

Re: [lldb-dev] negative in stop reason

Negative breakpoint ID’s are used for breakpoints lldb sets for internal purposes. You can see the internal breakpoints with the “break list -i” command. “continue” doesn’t usually need to set internal breakpoints, however. And we don’t usually tell you about internal breakpoint hits, especiall

Re: [lldb-dev] negative in stop reason

The breakpoint hit count is not increasing, which makes it look like we aren’t managing to do the job of stepping past the breakpoint. That requires restoring the breakpoint instruction, setting the processor to single-step, running just the thread that hit the breakpoint, then reinserting the

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

Hey, Greg, If you have a moment, could you add what isn't already there of this useful info to http://lldb.llvm.org/remote.html? The correct answer to this question should be "read http://lldb.llvm.org/remote.html"; but that doesn't seem as immediately useful as your description. Jim > On N

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

Thanks! Jim > On Nov 28, 2017, at 11:16 AM, Greg Clayton wrote: > > I will update the remote.html web page with any info that is missing! I was > about to go write the web page... Didn't realize we had one. > >> On Nov 28, 2017, at 11:08 AM, Jim Ingham wrote: >> >> Hey, Greg, >> >> If you

Re: [lldb-dev] Stopping "stop reason = exec"

There isn't a setting to auto-continue from exec. Definitely should be. If somebody wants to try their hand at it, just add a setting in parallel to stop-on-sharedlibrary-events and then add a ShouldStop to the StopInfoExec (StopInfo.cpp) that checks this setting. The StopInfoSignal does som

Re: [lldb-dev] Stopping "stop reason = exec"

Yup, apparently debugserver tells us the stop is for exec directly so we don't treat it as a breakpoint hit. That sorta makes sense, you don't want to trigger a breakpoint hit every time you find a thread at the pc of a breakpoint (might be a thread that hit a breakpoint, then didn't get to run

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

First off, just a technical point. lldb doesn't use RTTI to find dynamic types, and in fact works for projects like lldb & clang that turn off RTTI. It just uses the fact that the vtable symbol for an object demangles to: vtable for CLASSNAME That's not terribly important, but I just wanted t

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

This is actually using the same mechanism that Greg was describing, but through a separate route. With the crashinfo mechanism in place, if a test crashes the crash log will show whatever test was being run at the time of the crash. This was pretty useful when we were running the testsuite i

Re: [lldb-dev] Debugging std::string is weird...?

The address sanitizer does quite a number of code transformations, and if any of these transformations moves a variable to a different location, the debug information has to be fixed as well. There were a bugs in this part of the sanitizer in its original version, many of which have been fixed.

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

> On Jan 17, 2018, at 12:32 PM, Adrian Prantl wrote: > > Hi lldb-dev! > > I've been investigating some spurious LLDB test suite failures on > http://green.lab.llvm.org/green/ that had to do with build artifacts from > previous runs lying around in the test directories and this prompted me to

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

> On Jan 17, 2018, at 1:02 PM, Davide Italiano via lldb-dev > wrote: > > On Wed, Jan 17, 2018 at 12:32 PM, Adrian Prantl via lldb-dev > wrote: >> Hi lldb-dev! >> >> I've been investigating some spurious LLDB test suite failures on >> http://green.lab.llvm.org/green/ that had to do with buil

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

> On Jan 17, 2018, at 2:49 PM, Adrian Prantl wrote: > > > >> On Jan 17, 2018, at 2:31 PM, Zachary Turner wrote: >> >> I don't think new test authors really need to add CMake any more so than >> they currently need to understand Make. Which is to say, not very much. >> Most Makefiles are

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

> On Jan 17, 2018, at 2:55 PM, Adrian Prantl wrote: > > > >> On Jan 17, 2018, at 2:50 PM, Jim Ingham wrote: >> >> >> >>> On Jan 17, 2018, at 2:49 PM, Adrian Prantl wrote: >>> >>> >>> On Jan 17, 2018, at 2:31 PM, Zachary Turner wrote: I don't think new test authors real

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

Yeah, w.r.t. the actual builder part, it seems to me any option is going to be sufficiently simple to use that it would be hard for the incremental benefits to lldb developers to ever amortize the cost of switching. The only compelling reason to me is if one or the other tool made it much easie

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

> On Jan 17, 2018, at 3:25 PM, Zachary Turner wrote: > > I don't know what would be involved in getting the tests building out of tree > with Make. But I do know it would be simple with CMake. I'm sure it's > probably not terrible with Make either, I just don't know enough about it to > sa

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

> On Jan 17, 2018, at 3:32 PM, Zachary Turner wrote: > > On Wed, Jan 17, 2018 at 3:26 PM Greg Clayton wrote: > I don't see why we would go with a lit based system that manually specifies > the arguments. Seems like a pain to get the right compiler flags for creating > shared libs on differen

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

> On Jan 17, 2018, at 3:50 PM, Zachary Turner wrote: > > > > On Wed, Jan 17, 2018 at 3:44 PM Jim Ingham wrote: > > I don't see any of these operations that can't be done in a make file, after > all you can run arbitrary commands there. We do make directories, dylibs, > move and strip fil

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

> On Jan 17, 2018, at 3:47 PM, Zachary Turner wrote: > > > > On Wed, Jan 17, 2018 at 3:39 PM Adrian Prantl wrote: > >> On Jan 17, 2018, at 3:25 PM, Zachary Turner wrote: >> >> I don't know what would be involved in getting the tests building out of >> tree with Make. But I do know it wo

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

To Davide's alternative: LLDB does handle loading plugins that use the SB API's (for things like data formatters.) But there's not currently an SB interface to support writing a full language plugin, and we don't export the lldb_private API's from the lldb binary. So there's no current mechan

Re: [lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols

I must admit I've never played around with C++ demangling, but I wonder if our purposes in demangling might inform how we do this? We use demangled names for a couple of purposes. One is to print names in backtraces and thread reporting when we stop. For the most part the requests we've gotte

Re: [lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols

specialized -> specified Jim > On Jan 25, 2018, at 10:30 AM, Jim Ingham via lldb-dev > wrote: > > specialized ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols

That's along the same lines as what I was thinking. We really don't need to print all these names, and in fact the complicated ones are not useful for printing and certainly there are few times where you want to use them in their explicit forms. We really just want to pick out pieces to put in

Re: [lldb-dev] Huge mangled names are causing long delays when loading symbol table symbols

It's not just reduction of the number of demanglers we have to support, however. Greg and I both got excited by this proposal because we've had to maintain these name choppers for the tasks lldb has to do with mangled names - for instance matching incomplete human-typed in names - i.e. Class:

Re: [lldb-dev] Rust language support question

I second Greg, we don't really want to make the lldb_private namespace into API. We don't have any intention to stabilize this, and the interfaces expose a lot of clang & llvm types which are also not stable and change not infrequently. So in effect your plugin would end up being rev-locked to

Re: [lldb-dev] Rust language support question

Jason points out this was gdb writing out a binary form of gdb's psymtabs to be a cheap accelerator table. Anyway, having the data representation of debug information depend on the internal state of either the compiler or debugger is a fragile thing... Jim > On Jan 26, 2018, at 6:16 PM, Jim

Re: [lldb-dev] display register fields?

There isn't a built-in way to do this. It would be nice to have "register {format, summary, synthetic children} add {provider}" in parallel with the "type {format/summary/synthetic} add". The registers come to us as value objects so it would be straightforward to hook them up, and the vario

[lldb-dev] Testcase startup boiler-plate...

I've seen a couple new testcases coming past that copy the standard: exe = self.getBuildArtifact("a.out") self.target = self.dbg.CreateTarget(exe) self.assertTrue(self.target, VALID_TARGET) main_bp = self.target.BreakpointCreateByName("main") self.assertTr

Re: [lldb-dev] hashing pointers to strings

A quick glance indicates that this is all dead code. I can't see anything that actually instantiates either of the pubnames classes. The DWARF pubnames tables were a previous attempt at producing DWARF indexes, but they didn't contain enough information to actually forstall deep dives into the

Re: [lldb-dev] Querying build configuration of (lib)lldb from tests.

The idea of having a static function in SBDebugger that returns lldb configuration information seems good to me. Having the API return an SBStructuredData with the full configuration information seems like a pretty future-proof way to do this. I can't see that this data will get sufficiently l

Re: [lldb-dev] How to test lldb-vscode?

The SB API's were designed to be binary stable API's when used either from C++ or Python (the latter are just a SWIG-ified version of the former.) So just like the Python wrapper, with the exception that you might call an API that some older version of liblldb doesn't provide, Greg's adaptor wo

Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'

I only briefly scanned the patch, but I'm not sure treating D as another mangling variant of C++ is the best model - I think it will be easier if we gather all the separate language features up in the individual languages. You might have a look at the swift-enabled lldb (https://github.com/app

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

Jonas, What are you using to inspect the this pointer? You can use "frame variable" (the equivalent of gdb's "info locals") which just relies on debug info or the expression evaluator e.g. "print". Do both methods show the same problem? Also note that lldb by default will try to discern the f

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

Interesting. First off, you can turn off fetching dynamic values globally (including in the Xcode Locals view) by putting: settings set target.prefer-dynamic-value no-dynamic-values in your ~/.lldbinit file. You can toggle this on and off in a session, though Xcode won't notice you've chang

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

> On Feb 28, 2018, at 1:09 PM, jonas echterhoff wrote: > > > >> On Feb 28, 2018, at 9:27 PM, Jim Ingham wrote: >> >> Interesting. >> >> First off, you can turn off fetching dynamic values globally (including in >> the Xcode Locals view) by putting: >> >> settings set target.prefer-dyna

Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type

Yes, the code was assuming that "exact_match" would be obeyed so it explicitly specified returning only 1 match. When exact doesn't work, that means you get the first one... You will only have a problem with the one whose name matches both types, since the other way around the vtable name will

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

The problem with having no timeouts is that you have to then be fairly careful how you write tests. You can't do: while (1) { print("Set a breakpoint here and hit it a few times then stop the test"); } because if the breakpoint setting fails the test can run forever. And we wait forever to

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

It sounds like we timing out based on the whole test class, not the individual tests? If you're worried about test failures not hanging up the test suite the you really want to do the latter. These are all tests that contain 5 or more independent tests. That's probably why they are taking so

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

It is unfortunate that we have to set really long test timeouts because we are timing the total Test class run, not the individual tests. It is really convenient to be able to group similar tests in one class, so they can reuse setup and common check methods etc. But if we're going to have to

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

The breakpoints aren't a structural problem. If you can figure out a non-code modifying way to handle breakpoints, that would be a very surgical change. And as Fred points out, out of place execution in the target would be really handy for other things, like offloading breakpoint conditions in

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

> On Mar 29, 2018, at 10:40 AM, Greg Clayton via lldb-dev > wrote: > > > >> On Mar 29, 2018, at 10:36 AM, Frédéric Riss wrote: >> >> >> >>> On Mar 29, 2018, at 9:27 AM, Greg Clayton wrote: >>> >>> >>> On Mar 29, 2018, at 9:10 AM, Frédéric Riss wrote: > On

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

> On Apr 3, 2018, at 1:28 AM, Ramana wrote: > > > > On Thu, Mar 29, 2018 at 11:17 PM, Jim Ingham > wrote: > The breakpoints aren't a structural problem. If you can figure out a > non-code modifying way to handle breakpoints, that would be a very surgical > change

Re: [lldb-dev] [llvm-dev] lldb stops on every call to dlopen

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2

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

> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev > wrote: > > > >> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev >> wrote: >> >> Hi lldb developers, >> >> I've been researching using lldb + gdbserver stub that is based on Harvard >> architecture with multiple address

Re: [lldb-dev] FileSpec and normalization questions

The last time I looked at the llvm functions they only support the path syntax of the llvm host, which won't do for lldb. But maybe they have gotten more general recently? Jim > On Apr 19, 2018, at 11:16 AM, Davide Italiano via lldb-dev > wrote: > > IIRC We have path normalization function

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

> On Apr 19, 2018, at 10:54 AM, Greg Clayton wrote: > > > >> On Apr 19, 2018, at 10:35 AM, Jim Ingham wrote: >> >> >> >>> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev >>> wrote: >>> >>> >>> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev wrote: >>

Re: [lldb-dev] FileSpec and normalization questions

> On Apr 19, 2018, at 11:21 AM, Zachary Turner wrote: > > > > On Thu, Apr 19, 2018 at 11:19 AM Jim Ingham via lldb-dev > wrote: > The last time I looked at the llvm functions they only support the path > syntax of the llvm host, which won't do for lldb. But m

Re: [lldb-dev] FileSpec and normalization questions

I can't see any reason why we benefit from having these differently spelled equivalent paths floating around. You want to be careful to preserve the path syntax, since it would be weird to be cross debugging to a Windows machine and have to type Posix paths. But other than that, removing all t

Re: [lldb-dev] Welcome Alexander!

> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev > wrote: > > Welcome Alexander! Yes, welcome! > > The title might be more stated as "Reimplement lldb-mi to correctly use the > SB API instead of using HandleCommand and regular expressions to parse the > command results" as it is al

Re: [lldb-dev] Welcome Alexander!

> On Apr 24, 2018, at 9:44 AM, Greg Clayton wrote: > > > >> On Apr 24, 2018, at 9:37 AM, Jim Ingham wrote: >> >>> >>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev >>> wrote: >>> >>> Welcome Alexander! >> >> Yes, welcome! >> >>> >>> The title might be more stated as "Reimple

Re: [lldb-dev] Welcome Alexander!

> On Apr 24, 2018, at 2:46 PM, Greg Clayton wrote: > > > >> On Apr 24, 2018, at 2:35 PM, Jim Ingham wrote: >> >> >> >>> On Apr 24, 2018, at 9:44 AM, Greg Clayton wrote: >>> >>> >>> On Apr 24, 2018, at 9:37 AM, Jim Ingham wrote: > > On Apr 24, 2018, at 7:43 AM, Gre

Re: [lldb-dev] Welcome Alexander!

> On Apr 24, 2018, at 3:08 PM, Greg Clayton wrote: > > > >> On Apr 24, 2018, at 3:00 PM, Jim Ingham wrote: >> >> >> >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton wrote: >>> >>> >>> On Apr 24, 2018, at 2:35 PM, Jim Ingham wrote: > On Apr 24, 2018, at 9:44 AM

Re: [lldb-dev] Welcome Alexander!

> Ted > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf O

Re: [lldb-dev] Welcome Alexander!

at, I'm all for cleaning up lldb-mi. There were > > some funky decisions made when it was first developed. > > > > Ted > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >

Re: [lldb-dev] Issue with expression parser finding the correct types

> On Apr 25, 2018, at 5:52 PM, Greg Clayton via lldb-dev > wrote: > > I have identified an issue in the expression parse. If you compile this code: > > struct Foo { typedef unsigned node; }; > struct Bar { typedef int node; }; > int main(int argc, const char **argv) { > Foo::node foo_carp

Re: [lldb-dev] Issue with expression parser finding the correct types

> On Apr 25, 2018, at 7:49 PM, Jim Ingham via lldb-dev > wrote: > > NamespaceSearchContext that should be NameSearchContext. Jim ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] error printed to stderr: "Could not find implementation lookup function...."

Greg, Something is going wrong here before you get to this point. You can't get to the code in question (creating the AppleObjCTrampolineHandler) if you don't have an ObjCLanguageRuntime of some sort. The only way the trampoline gets made is in ReadObjCLibrary, which is a pure virtual method

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

Except for Windows and FreeBSD, lldb uses a server program to do the actual debugging - either debugserver on Darwin or lldb-server elsewhere. The interface to these servers (and to the in-process debugging in Windows & FreeBSD) is abstracted being Process Plugins, which the generic code uses.

Re: [lldb-dev] Making changes to the SB API

Overloading with different numbers of arguments works with no problems, and we use that in a bunch of places in the SB API. I seem to remember that SWIG doesn't always get more subtle overloading (float vrs. double) right, but I can't bring a specific example to mind. Anyway, Greg's solution s

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

Greg already wrote a "save_crashlog" Python command that writes the state of the program as a macOS flavor Crashlog file. It's in examples/Python/crashlog.py. My guess is he had something similar to that in mind, but writing a mini dump file instead. Jim > On Jun 13, 2018, at 3:20 PM, Leona

Re: [lldb-dev] clang::VersionTuple

> On Jun 15, 2018, at 3:44 AM, Pavel Labath via lldb-dev > wrote: > > Hello again, > > Just a quick update on the state of this. > > I've managed to move VersionTuple from clang to llvm. I've also > created to switch over our version > handling to that class

Re: [lldb-dev] Accessing only specific words in guest memory

By default, lldb uses a memory cache to avoid making lots of tiny memory requests, which tends to be inefficient especially when talking to a remote device. You can turn this off with the "target.process.disable-memory-cache" setting. You can also adjust the cache page size with "target.proce

Re: [lldb-dev] Accessing only specific words in guest memory

A quick scan of the code looks like this should be hooked up, but you are right, it doesn't seem to actually limit the cache page size. There's only one test for this and that one just checks that the setting has some particular value for android. Can you file a bug for this with bugs.llvm.org

Re: [lldb-dev] Accessing only specific words in guest memory

Ah, I see. It looks like you have to set this before you create the process. If I put this setting in my .lldbinit, or on the command line before I do "run" it does limit the read size. But apparently once we've created the memory cache we don't replace it when this value changes. That's sti

Re: [lldb-dev] Handling callable addresses

It's actually a little lame that we have a switch over architectures in generic Target code. This should be gotten from the architecture plugin. GetBreakableLoadAddress is even worse, there's ~150 lines of MIPS specific code in Target.cpp, which seems really wrong to me. Not really answering

Re: [lldb-dev] RFC: libtrace

Just to be clear, by "no clang integration" do you mean "no expression parser" or do you mean something more radical? For instance, adding a TypeSystem and its DWARF parser for C family languages that uses a different underlying representation than Clang AST's to store the results would be a lo

Re: [lldb-dev] RFC: libtrace

So you aren't planning to print values at all, just stop points (i.e. you are only interested in the line table and function symbols part of DWARF)? Given what you've described so far, I'm wondering if what you really want is the NativeProcess classes with some symbol-file reading pulled in? Is

Re: [lldb-dev] RFC: libtrace

nd avoid the context switches between the server and the debugger. That seems more appropriate for a lightweight tool. Jim > On Jun 26, 2018, at 12:59 PM, Jim Ingham via lldb-dev > wrote: > > So you aren't planning to print values at all, just stop points (i.e. you are &g

Re: [lldb-dev] [llvm-dev] RFC: libtrace

One important question, does this tool need to work remotely? I'm guessing the answer to this is no, since if you are working remotely you won't have a performant enough solution to really be an effective tracer. And if the guts of the debugger are remote, you care a lot less about the compl

Re: [lldb-dev] RFC: libtrace

7;d need much > else? > > Basing your work on NativeProcess rather than lldb proper would also cut the > number of observer processes in half and avoid the context switches between > the server and the debugger. That seems more appropriate for a lightweight > tool. > >

Re: [lldb-dev] RFC: libtrace

of > reporting w/o hooking into the lldb private/public state thread system. > > Jim > >> >> Thoughts? >> >> On Tue, Jun 26, 2018 at 1:09 PM Jim Ingham wrote: >> You'd probably need to pull the Unwinder in if you want backtraces, but that >> pa

Re: [lldb-dev] building only lldb with debug symbols

If you are on macOS, then the Xcode build has a "Debug" configuration which builds clang/llvm Release+asserts with no debug info, and lldb at -O0 with debug info. Jim > On Jun 28, 2018, at 2:58 AM, Pavel Labath via lldb-dev > wrote: > > On Thu, 28 Jun 2018 at 04:34, Adrian Harris via lldb-d

Re: [lldb-dev] lldb-mi doesn't propagate host environment variables

In lldb, this behavior is controlled by the setting: target.inherit-env Passing debugger environment is equal parts handy (getting a DISPLAY variable right for instance) and a cause for confusion. Not sure which is the most useful default. lldb defaults to true. But I can see an argument tha

Re: [lldb-dev] Process launch view duplication

Generally, the driver will print stop info every time a stop event is forwarded from the private event queue to the public event queue. You can check the output of the event log (log enable lldb event) to see if you are indeed sending two events. If you are sending two events, you can add the

Re: [lldb-dev] Where "thread until " should set breakpoints?

> On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev > wrote: > > On the subject line, the ToT lldb (see code around > CommandObjectThread.cpp:1230) sets the breakpoint on the first exact matching > line of 'line-number' or the closest line number > 'line-number' i.e. the > best match. > > A

Re: [lldb-dev] Where "thread until " should set breakpoints?

That's a bug. The code in CommandObjectThreadUntil needs to be a little more careful about sliding the line number to the "nearest source line that has code." It currently does: for (uint32_t line_number : line_numbers) { uint32_t start_idx_ptr = index_ptr; while (s

<    1   2   3   4   5   >