Re: [lldb-dev] Welcome Alexander!

> On Apr 24, 2018, at 5:24 PM, Александр Поляков wrote: > > Thanks Jim, it helped me a lot. > > Can we do something like this: >1) having empty dummy target; Yes, you don't need to do anything here. The Debugger object always makes a dummy target. >2)

Re: [lldb-dev] Welcome Alexander!

Thanks Jim, it helped me a lot. Can we do something like this: 1) having empty dummy target; 2) setting breakpoints to this dummy target until getting real file through -file-exec-and-symbols; 3) creating new target and moving all breakpoints from dummy target to it; 4) clearing all

Re: [lldb-dev] Welcome Alexander!

In lldb, one Debugger can debug multiple different processes at a time. This is one of the ways lldb differs from gdb (*)... In lldb, the Target is the entity that represents a thing that you could debug. A Target might or might not actually be debugging anything. If it is, the Target will

Re: [lldb-dev] Welcome Alexander!

I don't completely understand how it possible to add breakpoint before choosing a file(did you mean -file-exec-and-symbols cmd?). And another important thing: could you explain me what is target in terms of lldb? Thanks in advance. Regards, Alexander Polyakov 2018-04-25 1:32 GMT+03:00 Ted

Re: [lldb-dev] Welcome Alexander!

You'll still need HandleCommand for pass through commands. lldb commands send to lldb-mi are handled normally, so something like "file a.out" would set up a target using a.out. "-interpreter exec console " does the same thing. Other than that, I'm all for cleaning up lldb-mi. There were some

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

Re: [lldb-dev] Welcome Alexander!

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

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

Re: [lldb-dev] Welcome Alexander!

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

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,

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

> On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev > wrote: > > Hey guys, > > I'm trying to track down an issue I'm seeing where dlopen takes significantly > longer to execute when LLDB is attached vs GDB (I've attached a simple > program that I used

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

No liblldb.so didn't have any debug information, I made sure to strip it. With debug information it was 1.7GB which took way too long to load for a practical reproduction case. On Tue, Apr 24, 2018 at 3:36 PM Jason Molenda wrote: > Was liblldb.so build with debug

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

Was liblldb.so build with debug information? You're probably looking at lldb scanning the DWARF to make up its symbol table. That would be re-used on subsequent reruns so you're only seeing the cost that first time through. gdb may be using the standard dwarf accelerator tables, or it may be

[lldb-dev] Dlopen extremely slow while LLDB is attached

Hey guys, I'm trying to track down an issue I'm seeing where dlopen takes significantly longer to execute when LLDB is attached vs GDB (I've attached a simple program that I used to reproduce the issue). I was wondering if anybody had any idea what might be contributing to the additional

Re: [lldb-dev] Welcome Alexander!

​Thanks Greg, I changed the title and abstract, please check it out. https://summerofcode.withgoogle.com/projects/#5427847301169152​ Regards, Alexander Polyakov 2018-04-24 19:44 GMT+03:00 Greg Clayton : > > > On Apr 24, 2018, at 9:37 AM, Jim Ingham

Re: [lldb-dev] Welcome Alexander!

> 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

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 >

Re: [lldb-dev] Welcome Alexander!

Welcome Alexander! The title might be more stated as "Reimplement lldb-mi to correctly use the SB API instead of using HandleCommand and regular expressions to parse the command results" as it is already using the SB API, just not using it anywhere close to correctly! I look forward to