[lldb-dev] [Bug 26710] New: TestInlines fails on Linux with gcc

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26710

Bug ID: 26710
   Summary: TestInlines fails on Linux with gcc
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: tbergham...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

The test was added with rL261598 and rL261599 and failing since then on Linux
(and Android) when running with gcc on evaluating "expr inner_input" with
"error: use of undeclared identifier 'inner_input'"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26289] lldb host crashes with allocation failure when attaching to a remote android target

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26289

Luke Drummond  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Luke Drummond  ---
@ravithejawork

Thanks for helping out with this. I'm going to close this ticket, because as
you say, this is not caused by your changes (which appear correct) but is
triggered by mis-parsing the ELF section header table - which I think is
covered by #25338. Dumping all ELF files from the Android device (including the
VDSO) and then reading them with readelf shows that the ELF header and section
header table is correct, but somehow being misinterpreted in
ELFSectionHeader::Parse.

Thanks again for you help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26289] lldb host crashes with allocation failure when attaching to a remote android target

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26289

Luke Drummond  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.8 Release] Release status

[Aaron Ballman via lldb-dev]

On Mon, Feb 22, 2016 at 10:48 PM, Hans Wennborg  wrote:
> I had hoped to tag rc3 today (I feel like I've said this a lot
> lately), but it's at least really, really close. I'm waiting for:
>
> - r261297 - Implement the likely resolution of core issue 253.
>   Still in post-commit review.
>
> - D17507 - The controlling expression for _Generic is unevaluated
>   New for today. Waiting for review.

This one should hopefully be relatively straight-forward to review.

~Aaron
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-mi and shared library path

[Greg Clayton via lldb-dev]

Ok, sounds like you first need to see if "-gdb-set solib-search-path" is hooked 
up to "target modules search-paths add". If not, hook it up. Then we probably 
need to add a function to Platform.cpp that can use a target's module search 
paths to help find an executable. This can probably be a virtual function in 
Platform.h/cpp that will work for all platforms. So then each platform would 
try to locate the binary on its own using Platform::ResolveExecutable(...) or 
Platform::ResolveRemotePath(...) we should use the target's module search paths 
as places to look. This means that Platform::ResolveRemotePath(...) might need 
to take a Target list Platform::ResolveExecutable(...) already does. Does that 
make sense?

Greg

> On Feb 22, 2016, at 5:07 PM, Ted Woodward  wrote:
> 
> The Hexagon SDK taking to hardware is very bare bones. The OS is sitting on 
> the phone and is loaded to the Hexagon by Android. The debugger opens the OS 
> elf file, the user tells it where the shared libraries are, and lldb does the 
> usual stop-at-the-rendezvous function negotiation to get info when shared 
> libraries are loaded. Each example application is its own shared library, and 
> each is built in a different directory. I don't think I can have the Platform 
> do the hard work, because the shared libraries could be anywhere.
> 
> It works fine when we run lldb; it doesn't when our Eclipse guy runs lldb-mi. 
> I'm having fun looking at lots of logs!
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Monday, February 22, 2016 6:24 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: [lldb-dev] lldb-mi and shared library path
> 
> 
>> On Feb 4, 2016, at 1:51 PM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> I’d expect “-gdb-set solib-search-path” to call “target modules search-paths 
>> add”, and it does, but only when the –target-remote command is issued. It 
>> also doesn’t handle the multiple path case, :…
>> 
>> I think it should:
>> 
>> 1)  Set the search path immediately when called, if the target is 
>> connected
>> 2)  Set the search path on run/attach
>> 3)  Handle multiple paths
>> 
>> Any thoughts on this?
>> 
> 
> Here are some thoughts that say kind of how we are doing things, and after 
> reading this it might adjust your request:
> 
> In LLDB the approach we have taken is that when you are going to remotely 
> debug something, your Platform is responsible for finding any remote file 
> paths might not match the local file paths. 
> 
> For Apple with iOS, we have one or more root directories available for us to 
> grab system files from (everything from /usr/lib/* 
> /System/Library/Frameworks, etc). Only the executables you just built tend to 
> exist outside of the system roots, so as long as your provide those to LLDB 
> prior to running ("target create /path/to/locally/built/cross/executable"), 
> we will be able to match up the binaries using their UUID even if the remote 
> path is "/users/admin/executable". There are also ways to say "I built 
> /path/to/locally/built/cross/executable and 
> /path/to/locally/built/cross/libfoo.so and 
> /path/to/locally/built/cross/libbar.so", now attach to a remote binary to 
> debug these things. The extra .so files can be added to your target with 
> "target module add /path/to/locally/built/cross/libfoo.so" and "target module 
> add /path/to/locally/built/cross/libbar.so" and then we will be able to find 
> these files when they are needed.
> 
> So the main questions becomes: if you modify your platform to do the right 
> thing, do you need any of the changes you are requesting ("-gdb-set 
> solib-search-path" or "target modules search-paths add")?
> 
> This is how things were done back with GDB, but in LLDB we are trying to make 
> our Platform subclasses do a lot of this hard work for us. Your Platform 
> could check with a build server and download and cache any binaries it 
> needed. It could look through a set of directories or other commonly used 
> areas for these files, it really depends on how your SDK/PDK is setup and how 
> your builds tend to happen. If you have an IDE that is creating binaries, it 
> typically knows about all of the build products you might be trying to debug, 
> and it can often supply the build products to LLDB in case it needs them.
> 
> Let me know.
> 
> Greg Clayton
> 
> 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Module Cache improvements - RFC

[Greg Clayton via lldb-dev]

I believe this is already done.

I am guessing the main issue is this happens on the first time you debug to a 
device you and up with a 30 second delay with no feedback as to what is going 
on. So you say "launch" and then 35 seconds later you hit your breakpoint at 
main. In Xcode we solve this by downloading all of the files when we attach to 
a device for the first time and we show progress as we download all shared 
libraries. Sounds like it would be good for Android Studio to do the same thing?

Greg
> On Feb 22, 2016, at 5:27 PM, Zachary Turner  wrote:
> 
> Can't you just cache the modules locally on the disk, so that you only take 
> that 26 second hit the first time you try to download that module, and then 
> it indexes it by some sort of hash.  Then instead of just downloading it, you 
> check the local cache first and only download if it's not there.
> 
> If you already do all this, then disregard.
> 
> On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev 
>  wrote:
> 
> > On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
> >
> > Hello all,
> >
> > we are running into limitations of the current module download/caching
> > system. A simple android application can link to about 46 megabytes
> > worth of modules, and downloading that with our current transfer rates
> > takes about 25 seconds. Much of the data we download this way is never
> > actually accessed, and yet we download everything immediately upon
> > starting the debug session, which makes the first session extremely
> > laggy.
> >
> > We could speed up a lot by only downloading the portions of the module
> > that we really need (in my case this turns out to be about 8
> > megabytes). Also, further speedups could be made by increasing the
> > throughput of the gdb-remote protocol used for downloading these files
> > by using pipelining.
> >
> > I made a proof-of-concept hack  of these things, put it into lldb and
> > I was able to get the time for the startup-attach-detach-exit cycle
> > down to 5.4 seconds (for comparison, the current time for the cycle is
> > about 3.6 seconds with a hot module cache, and 28(!) seconds with an
> > empty cache).
> >
> > Now, I would like to properly implement these things in lldb properly,
> > so this is a request for comments on my plan. What I would like to do
> > is:
> > - Replace ModuleCache with a SectionCache (actually, more like a cache
> > of arbitrary file chunks). When a the cache gets a request for a file
> > and the file is not in the cache already, it returns a special kind of
> > a Module, whose fragments will be downloaded as we are trying to
> > access them. These fragments will be cached on disk, so that
> > subsequent requests for the file do not need to re-download them. We
> > can also have the option to short-circuit this logic and download the
> > whole file immediately (e.g., when the file is small, or we have a
> > super-fast way of obtaining the whole file via rsync, etc...)
> > - Add pipelining support to GDBRemoteCommunicationClient for
> > communicating with the platform. This actually does not require any
> > changes to the wire protocol. The only change is in adding the ability
> > to send an additional request to the server while waiting for the
> > response to the previous one. Since the protocol is request-response
> > based and we are communication over a reliable transport stream, each
> > response can be correctly matched to a request even though we have
> > multiple packets in flight. Any packets which need to maintain more
> > complex state (like downloading a single entity using continuation
> > packets) can still lock the stream to get exclusive access, but I am
> > not sure if we actually even have any such packets in the platform
> > flavour of the protocol.
> > - Paralelize downloading of multiple files in parallel, utilizing
> > request pipelining. Currently we get the biggest delay when first
> > attaching to a process (we download file headers and some basic
> > informative sections) and when we try to set the first symbol-level
> > breakpoint (we download symbol tables and string sections). Both of
> > these actions operate on all modules in bulk, which makes them easy
> > paralelization targets. This will provide a big speed boost, as we
> > will be eliminating communication latency. Furthermore, in case of
> > lots of files, we will be overlapping file download  (io) with parsing
> > (cpu), for an even bigger boost.
> >
> > What do you think?
> >
> 
> Feel free to implement this in PlatformAndroid and allow others to opt into 
> this. I won't want this by default in any of the Apple platforms in MachO we 
> have our entire image mapped into memory and we have other tricks for getting 
> the information quicker.
> 
> So I would leave the module cache there and not change it, but feel free to 
> add the section cache as needed. Maybe if this goes really well and it can be 
> arbitrarily used on any files types (MachO, ELF, COFF, etc) and it just work

Re: [lldb-dev] Module Cache improvements - RFC

[Tamas Berghammer via lldb-dev]

Yes we already have a disk cache on the host. I agree with you that waiting
30s at the first startup shouldn't be an issue in general (Pavel isn't
sharing my opinion). The only catch is that in case of iOS there are only a
few different builds released so if you downloaded the modules once then I
think you won't have to download them the next time when you try to use a
different device. In case of Android we have to download the symbols from
each device you are using and at that point 30s might be an issue (I still
don't think it is).

On Tue, Feb 23, 2016 at 6:00 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I believe this is already done.
>
> I am guessing the main issue is this happens on the first time you debug
> to a device you and up with a 30 second delay with no feedback as to what
> is going on. So you say "launch" and then 35 seconds later you hit your
> breakpoint at main. In Xcode we solve this by downloading all of the files
> when we attach to a device for the first time and we show progress as we
> download all shared libraries. Sounds like it would be good for Android
> Studio to do the same thing?
>
> Greg
> > On Feb 22, 2016, at 5:27 PM, Zachary Turner  wrote:
> >
> > Can't you just cache the modules locally on the disk, so that you only
> take that 26 second hit the first time you try to download that module, and
> then it indexes it by some sort of hash.  Then instead of just downloading
> it, you check the local cache first and only download if it's not there.
> >
> > If you already do all this, then disregard.
> >
> > On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > > On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
> > >
> > > Hello all,
> > >
> > > we are running into limitations of the current module download/caching
> > > system. A simple android application can link to about 46 megabytes
> > > worth of modules, and downloading that with our current transfer rates
> > > takes about 25 seconds. Much of the data we download this way is never
> > > actually accessed, and yet we download everything immediately upon
> > > starting the debug session, which makes the first session extremely
> > > laggy.
> > >
> > > We could speed up a lot by only downloading the portions of the module
> > > that we really need (in my case this turns out to be about 8
> > > megabytes). Also, further speedups could be made by increasing the
> > > throughput of the gdb-remote protocol used for downloading these files
> > > by using pipelining.
> > >
> > > I made a proof-of-concept hack  of these things, put it into lldb and
> > > I was able to get the time for the startup-attach-detach-exit cycle
> > > down to 5.4 seconds (for comparison, the current time for the cycle is
> > > about 3.6 seconds with a hot module cache, and 28(!) seconds with an
> > > empty cache).
> > >
> > > Now, I would like to properly implement these things in lldb properly,
> > > so this is a request for comments on my plan. What I would like to do
> > > is:
> > > - Replace ModuleCache with a SectionCache (actually, more like a cache
> > > of arbitrary file chunks). When a the cache gets a request for a file
> > > and the file is not in the cache already, it returns a special kind of
> > > a Module, whose fragments will be downloaded as we are trying to
> > > access them. These fragments will be cached on disk, so that
> > > subsequent requests for the file do not need to re-download them. We
> > > can also have the option to short-circuit this logic and download the
> > > whole file immediately (e.g., when the file is small, or we have a
> > > super-fast way of obtaining the whole file via rsync, etc...)
> > > - Add pipelining support to GDBRemoteCommunicationClient for
> > > communicating with the platform. This actually does not require any
> > > changes to the wire protocol. The only change is in adding the ability
> > > to send an additional request to the server while waiting for the
> > > response to the previous one. Since the protocol is request-response
> > > based and we are communication over a reliable transport stream, each
> > > response can be correctly matched to a request even though we have
> > > multiple packets in flight. Any packets which need to maintain more
> > > complex state (like downloading a single entity using continuation
> > > packets) can still lock the stream to get exclusive access, but I am
> > > not sure if we actually even have any such packets in the platform
> > > flavour of the protocol.
> > > - Paralelize downloading of multiple files in parallel, utilizing
> > > request pipelining. Currently we get the biggest delay when first
> > > attaching to a process (we download file headers and some basic
> > > informative sections) and when we try to set the first symbol-level
> > > breakpoint (we download symbol tables and string sections). Both of
> > > these actions operate on all modules in bulk, which makes them easy
> > 

Re: [lldb-dev] Module Cache improvements - RFC

[Oleksiy Vyalov via lldb-dev]

For progress purposes in Android Studio we listen on
eBroadcastBitModulesLoaded coming from the target so we can report about
every loaded SO.

On Tue, Feb 23, 2016 at 10:00 AM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I believe this is already done.
>
> I am guessing the main issue is this happens on the first time you debug
> to a device you and up with a 30 second delay with no feedback as to what
> is going on. So you say "launch" and then 35 seconds later you hit your
> breakpoint at main. In Xcode we solve this by downloading all of the files
> when we attach to a device for the first time and we show progress as we
> download all shared libraries. Sounds like it would be good for Android
> Studio to do the same thing?
>
> Greg
> > On Feb 22, 2016, at 5:27 PM, Zachary Turner  wrote:
> >
> > Can't you just cache the modules locally on the disk, so that you only
> take that 26 second hit the first time you try to download that module, and
> then it indexes it by some sort of hash.  Then instead of just downloading
> it, you check the local cache first and only download if it's not there.
> >
> > If you already do all this, then disregard.
> >
> > On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > > On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
> > >
> > > Hello all,
> > >
> > > we are running into limitations of the current module download/caching
> > > system. A simple android application can link to about 46 megabytes
> > > worth of modules, and downloading that with our current transfer rates
> > > takes about 25 seconds. Much of the data we download this way is never
> > > actually accessed, and yet we download everything immediately upon
> > > starting the debug session, which makes the first session extremely
> > > laggy.
> > >
> > > We could speed up a lot by only downloading the portions of the module
> > > that we really need (in my case this turns out to be about 8
> > > megabytes). Also, further speedups could be made by increasing the
> > > throughput of the gdb-remote protocol used for downloading these files
> > > by using pipelining.
> > >
> > > I made a proof-of-concept hack  of these things, put it into lldb and
> > > I was able to get the time for the startup-attach-detach-exit cycle
> > > down to 5.4 seconds (for comparison, the current time for the cycle is
> > > about 3.6 seconds with a hot module cache, and 28(!) seconds with an
> > > empty cache).
> > >
> > > Now, I would like to properly implement these things in lldb properly,
> > > so this is a request for comments on my plan. What I would like to do
> > > is:
> > > - Replace ModuleCache with a SectionCache (actually, more like a cache
> > > of arbitrary file chunks). When a the cache gets a request for a file
> > > and the file is not in the cache already, it returns a special kind of
> > > a Module, whose fragments will be downloaded as we are trying to
> > > access them. These fragments will be cached on disk, so that
> > > subsequent requests for the file do not need to re-download them. We
> > > can also have the option to short-circuit this logic and download the
> > > whole file immediately (e.g., when the file is small, or we have a
> > > super-fast way of obtaining the whole file via rsync, etc...)
> > > - Add pipelining support to GDBRemoteCommunicationClient for
> > > communicating with the platform. This actually does not require any
> > > changes to the wire protocol. The only change is in adding the ability
> > > to send an additional request to the server while waiting for the
> > > response to the previous one. Since the protocol is request-response
> > > based and we are communication over a reliable transport stream, each
> > > response can be correctly matched to a request even though we have
> > > multiple packets in flight. Any packets which need to maintain more
> > > complex state (like downloading a single entity using continuation
> > > packets) can still lock the stream to get exclusive access, but I am
> > > not sure if we actually even have any such packets in the platform
> > > flavour of the protocol.
> > > - Paralelize downloading of multiple files in parallel, utilizing
> > > request pipelining. Currently we get the biggest delay when first
> > > attaching to a process (we download file headers and some basic
> > > informative sections) and when we try to set the first symbol-level
> > > breakpoint (we download symbol tables and string sections). Both of
> > > these actions operate on all modules in bulk, which makes them easy
> > > paralelization targets. This will provide a big speed boost, as we
> > > will be eliminating communication latency. Furthermore, in case of
> > > lots of files, we will be overlapping file download  (io) with parsing
> > > (cpu), for an even bigger boost.
> > >
> > > What do you think?
> > >
> >
> > Feel free to implement this in PlatformAndroid and allow others to opt
> into this. I won't w

Re: [lldb-dev] Module Cache improvements - RFC

[Nico Weber via lldb-dev]

On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Yes we already have a disk cache on the host. I agree with you that
> waiting 30s at the first startup shouldn't be an issue in general (Pavel
> isn't sharing my opinion). The only catch is that in case of iOS there are
> only a few different builds released so if you downloaded the modules once
> then I think you won't have to download them the next time when you try to
> use a different device. In case of Android we have to download the symbols
> from each device you are using and at that point 30s might be an issue (I
> still don't think it is).
>

With my app developer hat on, if some program makes me wait 30s for
something then I won't like that program.


>
> On Tue, Feb 23, 2016 at 6:00 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I believe this is already done.
>>
>> I am guessing the main issue is this happens on the first time you debug
>> to a device you and up with a 30 second delay with no feedback as to what
>> is going on. So you say "launch" and then 35 seconds later you hit your
>> breakpoint at main. In Xcode we solve this by downloading all of the files
>> when we attach to a device for the first time and we show progress as we
>> download all shared libraries. Sounds like it would be good for Android
>> Studio to do the same thing?
>>
>> Greg
>> > On Feb 22, 2016, at 5:27 PM, Zachary Turner  wrote:
>> >
>> > Can't you just cache the modules locally on the disk, so that you only
>> take that 26 second hit the first time you try to download that module, and
>> then it indexes it by some sort of hash.  Then instead of just downloading
>> it, you check the local cache first and only download if it's not there.
>> >
>> > If you already do all this, then disregard.
>> >
>> > On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > > On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
>> > >
>> > > Hello all,
>> > >
>> > > we are running into limitations of the current module download/caching
>> > > system. A simple android application can link to about 46 megabytes
>> > > worth of modules, and downloading that with our current transfer rates
>> > > takes about 25 seconds. Much of the data we download this way is never
>> > > actually accessed, and yet we download everything immediately upon
>> > > starting the debug session, which makes the first session extremely
>> > > laggy.
>> > >
>> > > We could speed up a lot by only downloading the portions of the module
>> > > that we really need (in my case this turns out to be about 8
>> > > megabytes). Also, further speedups could be made by increasing the
>> > > throughput of the gdb-remote protocol used for downloading these files
>> > > by using pipelining.
>> > >
>> > > I made a proof-of-concept hack  of these things, put it into lldb and
>> > > I was able to get the time for the startup-attach-detach-exit cycle
>> > > down to 5.4 seconds (for comparison, the current time for the cycle is
>> > > about 3.6 seconds with a hot module cache, and 28(!) seconds with an
>> > > empty cache).
>> > >
>> > > Now, I would like to properly implement these things in lldb properly,
>> > > so this is a request for comments on my plan. What I would like to do
>> > > is:
>> > > - Replace ModuleCache with a SectionCache (actually, more like a cache
>> > > of arbitrary file chunks). When a the cache gets a request for a file
>> > > and the file is not in the cache already, it returns a special kind of
>> > > a Module, whose fragments will be downloaded as we are trying to
>> > > access them. These fragments will be cached on disk, so that
>> > > subsequent requests for the file do not need to re-download them. We
>> > > can also have the option to short-circuit this logic and download the
>> > > whole file immediately (e.g., when the file is small, or we have a
>> > > super-fast way of obtaining the whole file via rsync, etc...)
>> > > - Add pipelining support to GDBRemoteCommunicationClient for
>> > > communicating with the platform. This actually does not require any
>> > > changes to the wire protocol. The only change is in adding the ability
>> > > to send an additional request to the server while waiting for the
>> > > response to the previous one. Since the protocol is request-response
>> > > based and we are communication over a reliable transport stream, each
>> > > response can be correctly matched to a request even though we have
>> > > multiple packets in flight. Any packets which need to maintain more
>> > > complex state (like downloading a single entity using continuation
>> > > packets) can still lock the stream to get exclusive access, but I am
>> > > not sure if we actually even have any such packets in the platform
>> > > flavour of the protocol.
>> > > - Paralelize downloading of multiple files in parallel, utilizing
>> > > request pipelining. Currently we get the biggest delay

[lldb-dev] How to use the C++ API? No useful documentation?

[Paul Peet via lldb-dev]

Hello,

I am currently working on an IDE for C++ and I would like to integrate lldb
as a debugger using the C++ API but it has been difficult for me to
understand the architecture because there is no documentation available
(except doxygen which isn't helpful at all).
I am at the point understanding the Event system? How are Events created?
How can I use SBListener and SBBroadcaster? (What's the function of
SBBroadvaster).

My current code looks something like this:

SBListener listener;
SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
  nullptr, "/home/cynecx/dev/helloWorld",
  0, true, error);

process.Continue();

StateType state = process.GetState(); // is stopped

SBEvent event;

while(true) {
  if(listener.WaitForEvent(0x, event)) {
// This branch is never hit
SBStream stream;
event.GetDescription(stream);
std::cout << stream.GetData() << std::endl;
  } else {
break;
  }
}

It would help developers (IDE) a lot if there might be some
tutorials/documentation on how to use the API.

Regards,
Paul
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Module Cache improvements - RFC

[Greg Clayton via lldb-dev]

> On Feb 23, 2016, at 10:31 AM, Nico Weber  wrote:
> 
> On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev 
>  wrote:
> Yes we already have a disk cache on the host. I agree with you that waiting 
> 30s at the first startup shouldn't be an issue in general (Pavel isn't 
> sharing my opinion). The only catch is that in case of iOS there are only a 
> few different builds released so if you downloaded the modules once then I 
> think you won't have to download them the next time when you try to use a 
> different device. In case of Android we have to download the symbols from 
> each device you are using and at that point 30s might be an issue (I still 
> don't think it is).
> 
> With my app developer hat on, if some program makes me wait 30s for something 
> then I won't like that program.

I agree, but if the first time you hook your phone up Android Studio pops up a 
dialog box saying "This is the first time you have connected this device, hold 
on while I cache the shared libraries for this device..." then it wouldn't be 
too bad. It is primarily the fact that the 30 seconds is happening without 
feedback during first launch or attach. Also, you can probably use something 
faster than the lldb-platform to download all of the files. In Xcode, we 
download all symbols into the users home directory in a known location:

~/Library/Developer/Xcode/iOS DeviceSupport

This folder contains the exact OS version and a build number:

(lldb) platform select remote-ios 
  Platform: remote-ios
 Connected: no
 SDK Roots: [ 0] "~/Library/Developer/Xcode/iOS DeviceSupport/9.0 (W)"
 SDK Roots: [ 1] "~/Library/Developer/Xcode/iOS DeviceSupport/9.1 (X)"
 SDK Roots: [ 2] "~/Library/Developer/Xcode/iOS DeviceSupport/9.2 (Y)"

Where W, X, Y are build numbers. We know we can look in these 
folders for any files that are from the device. They get populated and these 
SDK directories get searched by LLDB's PlatformRemoteiOS so they get found (we 
don't use the file cache that the PlatformAndroid currently uses).

So with a little work, I would add some functionality to your Android Studio, 
have something that knows how to copy files from device as quickly as possible 
(using lldb-platform is slwww and that is the way it is currently done I 
believe) into some such directory, all while showing a progress dialog to the 
user on first device connect, and then debugging will always be quick. And you 
can probably make it quicker than 30 seconds.

Greg Clayton


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Jim Ingham via lldb-dev]

The Python API is pretty much a mirror of the C++ API's.  The process_events.py 
example: 
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py 
should give you a sense of how the broadcasters & listeners are used.  
Translating that from Python to C++ is quite straightforward.  There is some 
documentation in the SB API header files which can be helpful, though that is 
not complete.  There have been discussions on some of these issues on the 
mailing list previously that also might be of some help.

But you are right, we don't have a how-to manual for writing a debugger with 
the SB API's.  It would be great if somebody who was trying to use them for 
this purpose would draft up such a thing as they were going.  I am sure the 
folks on this list would be happy to help out and suggest better ways to do 
things, etc.

Jim

> On Feb 20, 2016, at 3:04 PM, Paul Peet via lldb-dev  
> wrote:
> 
> Hello,
> 
> I am currently working on an IDE for C++ and I would like to integrate lldb 
> as a debugger using the C++ API but it has been difficult for me to 
> understand the architecture because there is no documentation available 
> (except doxygen which isn't helpful at all).
> I am at the point understanding the Event system? How are Events created?
> How can I use SBListener and SBBroadcaster? (What's the function of 
> SBBroadvaster).
> 
> My current code looks something like this:
> 
> SBListener listener;
> SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
>   nullptr, "/home/cynecx/dev/helloWorld",
>   0, true, error);
> 
> process.Continue();
> 
> StateType state = process.GetState(); // is stopped
> 
> SBEvent event;
> 
> while(true) {
>   if(listener.WaitForEvent(0x, event)) {
> // This branch is never hit
> SBStream stream;
> event.GetDescription(stream);
> std::cout << stream.GetData() << std::endl;
>   } else {
> break;
>   }
> }
> 
> It would help developers (IDE) a lot if there might be some 
> tutorials/documentation on how to use the API.
> 
> Regards,
> Paul
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

[Jeffrey Tan via lldb-dev]

Hi,

I have got lldb launch working fine on my macbook for sometime. But when I
try the same code on Linux, it failed to emit any stopping events during
initial launch.

When I run the reproduce code(listed at the end), I got the following
different results:

The key difference is that Macbook will emit a stopped event which caused
our IDE UI to enter break mode, while Linux violates this assumption. Is
this a bug?

==Mac==
lldb_pythonpath:
/Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
Launch result: success
 Listening Thread ID: 4610625536
dbg> *Target event: ModulesLoaded*
*Process event: StateChanged, Stopped*
*Stop reason: 5*
dbg> bt
* thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop
reason = signal SIGSTOP
  * frame #0: 0x7fff6401a000 dyld`_dyld_start
==Mac==

==Linux==
python linux_launch.py
find_lldb: 
Launch result: success
 Listening Thread ID: 140316621375232
dbg> bt
* thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop reason =
signal SIGSTOP
  * frame #0: 0x7f6165b7bb00
==Linux==

Repro main.py
# Should be first for LLDB package to be added to search path.
from find_lldb import lldb
import sys
import os
import time
from sys import stdin, stdout
from event_thread import LLDBListenerThread
import threading


def interctive_loop(debugger):
while (True):
stdout.write('dbg> ')
command = stdin.readline().rstrip()
if len(command) == 0:
continue
if command == 'q':
return
debugger.HandleCommand(command)

def do_test():
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(True)
executable_path =
'~/Personal/compiler/CompilerConstruction/code/compiler'
target = debugger.CreateTargetWithFileAndArch(executable_path,
lldb.LLDB_ARCH_DEFAULT)

listener = lldb.SBListener('Event Listener')
error = lldb.SBError()
process = target.Launch (listener,
 None,  # argv
 None,  # envp
 None,  # stdin_path
 None,  # stdout_path
 None,  # stderr_path
 None,  # working directory
 0, # launch flags
 True, # Stop at entry
 error) # error
print 'Launch result: %s' % str(error)

running_signal = threading.Event()
stopped_signal = threading.Event()
event_thread = LLDBListenerThread(debugger, running_signal,
stopped_signal)
event_thread.start()

interctive_loop(debugger)

event_thread.should_quit = True
event_thread.join()

lldb.SBDebugger.Destroy(debugger)
return debugger

def main():
debugger = do_test()

if __name__ == '__main__':
main()

Event_thread
class LLDBListenerThread(Thread):
should_quit = False

def __init__(self, debugger, running_signal=None, stopped_sigal=None):
  Thread.__init__(self)
  self._running_signal = running_signal
  self._stopped_sigal = stopped_sigal
  process = debugger.GetSelectedTarget().process
  self.listener = debugger.GetListener()
  self._add_listener_to_process(process)
  self._add_listener_to_target(process.target)


def _add_listener_to_target(self, target):
# Listen for breakpoint/watchpoint events
(Added/Removed/Disabled/etc).
broadcaster = target.GetBroadcaster()
mask = lldb.SBTarget.eBroadcastBitBreakpointChanged |
lldb.SBTarget.eBroadcastBitWatchpointChanged |
lldb.SBTarget.eBroadcastBitModulesLoaded
broadcaster.AddListener(self.listener, mask)

def _add_listener_to_process(self, process):
# Listen for process events (Start/Stop/Interrupt/etc).
broadcaster = process.GetBroadcaster()
mask = lldb.SBProcess.eBroadcastBitStateChanged |
lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR |
lldb.SBProcess.eBroadcastBitInterrupt
broadcaster.AddListener(self.listener, mask)

def run(self):
print ' Listening Thread ID: %d' % thread.get_ident()
while not self.should_quit:
event = lldb.SBEvent()
if self.listener.WaitForEvent(1, event):
if lldb.SBTarget.EventIsTargetEvent(event):
self._handle_target_event(event)
elif lldb.SBProcess.EventIsProcessEvent(event):
self._handle_process_event(event)
elif lldb.SBBreakpoint.EventIsBreakpointEvent(event):
self._handle_breakpoint_event(event)
elif lldb.SBThread.EventIsThreadEvent(even

[lldb-dev] [3.8 Release] RC3 has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

Release Candidate 3 has just been tagged [1]. Please build, test, and
upload to the sftp.

If there are no regressions from previous release candidates, this
will be the last release candidate before the final release.

Release notes can still go into the branch.

Thanks again for all your work!
Hans

 [1] 
http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [3.8 Release] Release status

[Hans Wennborg via lldb-dev]

On Mon, Feb 22, 2016 at 11:47 PM, Ismail Donmez  wrote:
> On Tue, Feb 23, 2016 at 5:48 AM, Hans Wennborg via Openmp-dev
>  wrote:
>> I had hoped to tag rc3 today (I feel like I've said this a lot
>> lately), but it's at least really, really close. I'm waiting for:
>>
>> - r261297 - Implement the likely resolution of core issue 253.
>>   Still in post-commit review.
>
> I originally wanted this one but the fix involved even more discussion
> so I guess it would be safer to put it in 3.8.1 instead.

Right. Since this seems complicated, and not strictly fixing a
regression, I'm not going to wait for it.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

[Jim Ingham via lldb-dev]

If the linux side is not obeying "stop_at_entry" then that is a bug.

Jim


> On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I have got lldb launch working fine on my macbook for sometime. But when I 
> try the same code on Linux, it failed to emit any stopping events during 
> initial launch. 
> 
> When I run the reproduce code(listed at the end), I got the following 
> different results:
> 
> The key difference is that Macbook will emit a stopped event which caused our 
> IDE UI to enter break mode, while Linux violates this assumption. Is this a 
> bug?
> 
> ==Mac==
> lldb_pythonpath: 
> /Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
> Launch result: success
>  Listening Thread ID: 4610625536
> dbg> Target event: ModulesLoaded
> Process event: StateChanged, Stopped
> Stop reason: 5
> dbg> bt
> * thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop 
> reason = signal SIGSTOP
>   * frame #0: 0x7fff6401a000 dyld`_dyld_start
> ==Mac==
> 
> ==Linux==
> python linux_launch.py
> find_lldb:  '/home/jeffreytan/project/llvm-bin/Debug+Asserts/lib/python2.7/site-packages/lldb/__init__.pyc'>
> Launch result: success
>  Listening Thread ID: 140316621375232
> dbg> bt
> * thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop reason = 
> signal SIGSTOP
>   * frame #0: 0x7f6165b7bb00
> ==Linux==
> 
> Repro main.py
> # Should be first for LLDB package to be added to search path.
> from find_lldb import lldb
> import sys
> import os
> import time
> from sys import stdin, stdout
> from event_thread import LLDBListenerThread
> import threading
> 
> 
> def interctive_loop(debugger):
> while (True):
> stdout.write('dbg> ')
> command = stdin.readline().rstrip()
> if len(command) == 0:
> continue
> if command == 'q':
> return
> debugger.HandleCommand(command)
> 
> def do_test():
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(True)
> executable_path = '~/Personal/compiler/CompilerConstruction/code/compiler'
> target = debugger.CreateTargetWithFileAndArch(executable_path, 
> lldb.LLDB_ARCH_DEFAULT)
> 
> listener = lldb.SBListener('Event Listener')
> error = lldb.SBError()
> process = target.Launch (listener,
>  None,  # argv
>  None,  # envp
>  None,  # stdin_path
>  None,  # stdout_path
>  None,  # stderr_path
>  None,  # working directory
>  0, # launch flags
>  True, # Stop at entry
>  error) # error
> print 'Launch result: %s' % str(error)
> 
> running_signal = threading.Event()
> stopped_signal = threading.Event()
> event_thread = LLDBListenerThread(debugger, running_signal, 
> stopped_signal)
> event_thread.start()
> 
> interctive_loop(debugger)
> 
> event_thread.should_quit = True
> event_thread.join()
> 
> lldb.SBDebugger.Destroy(debugger)
> return debugger
> 
> def main():
> debugger = do_test()
> 
> if __name__ == '__main__':
> main()
> 
> Event_thread
> class LLDBListenerThread(Thread):
> should_quit = False
> 
> def __init__(self, debugger, running_signal=None, stopped_sigal=None):
>   Thread.__init__(self)
>   self._running_signal = running_signal
>   self._stopped_sigal = stopped_sigal
>   process = debugger.GetSelectedTarget().process
>   self.listener = debugger.GetListener()
>   self._add_listener_to_process(process)
>   self._add_listener_to_target(process.target)
> 
> 
> def _add_listener_to_target(self, target):
> # Listen for breakpoint/watchpoint events 
> (Added/Removed/Disabled/etc).
> broadcaster = target.GetBroadcaster()
> mask = lldb.SBTarget.eBroadcastBitBreakpointChanged | 
> lldb.SBTarget.eBroadcastBitWatchpointChanged | 
> lldb.SBTarget.eBroadcastBitModulesLoaded
> broadcaster.AddListener(self.listener, mask)
> 
> def _add_listener_to_process(self, process):
> # Listen for process events (Start/Stop/Interrupt/etc).
> broadcaster = process.GetBroadcaster()
> mask = lldb.SBProcess.eBroadcastBitStateChanged | 
> lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR | 
> lldb.SBProcess.eBroadcastBitInterrupt
> broadcaster.AddListener(self.listener, mask)
> 
> def run(self):
> print ' Listening Thread ID: %d' % thread.get_ident()
> while not s

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Greg Clayton via lldb-dev]

I need to spend some time writing this up, but until then here is some info.

We created a python script that uses the LLDB public API to grab async events 
so people can see how to do things:

svn cat 
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py

If you look in here you will see the correct way to do things.

I will answer you questions inlined into your email below and then add some 
extra tips at the end:

> On Feb 20, 2016, at 3:04 PM, Paul Peet via lldb-dev  
> wrote:
> 
> Hello,
> 
> I am currently working on an IDE for C++ and I would like to integrate lldb 
> as a debugger using the C++ API but it has been difficult for me to 
> understand the architecture because there is no documentation available 
> (except doxygen which isn't helpful at all).
> I am at the point understanding the Event system? How are Events created?

You need to be able to listen for events from your debug session. In order to 
do this, SBBroadcaster objects can broadcast events as SBEvent objects. You 
need to listen for events using a SBListener. Each SBBroadcaster will broadcast 
events where each different kind of event is represented by one bit in a 32 bit 
uint32_t. 

> How can I use SBListener and SBBroadcaster? (What's the function of 
> SBBroadvaster).

Yes you can. You might want to use a SBBroadcaster to send events to your main 
event loop in the debugger:

using namespace lldb;
SBBroadcaster gui_event_broadcaster("gui-events");

// Define the event bits we will use for gui_event_broadcaster
enum
{
  eGUIEventBitLaunch   = (1u << 0),
  eGUIEventBitKill = (1u << 1),
  eGUIEventBitStepOver = (1u << 2),
  eGUIEventBitStepOut  = (1u << 3),
  eGUIEventBitStepInto = (1u << 4),
  eGUIEventBitContinue = (1u << 5),
  eGUIEventBitHalt = (1u << 6),
  eGUIEventBitQuit = (1u << 7),
  eGUIEventAll = UINT32_MAX
};

SBListener run_loop_listener("run-loop-listener");
// Listen for any event from gui_event_broadcaster by listening to all event 
bits
run_loop_listener.StartListeningForEvents(gui_event_broadcaster, eGUIEventAll);

You can then run an event loop on a thread:

void
RunLoop()
{
  SBEvent event;
  bool done = false
  while (!done)
  {
if (listener.WaitForEvent(UINT32_MAX, event))
{
  const uint32_t event_type = event.GetType();
  if (event.BroadcasterMatchesRef(gui_event_broadcaster))
  {
switch (event_type)
{
case eGUIEventBitLaunch:
case eGUIEventBitKill:
case eGUIEventBitQuit:
}
  }
}
  }
}


Then on another thread, you can broadcast events. Lets say the user clicked the 
"kill" button in your IDE, you could broadcast an event:

gui_event_broadcaster.BroadcastEventByType(eGUIEventBitKill);

Then the event loop would receive the event, as long as it is listening for 
these events. So you can use SBBroadcaster and SBListener yourself, but many 
objects (like SBTarget, SBProcess and SBThread) are already broadcasters and 
will broadcast events to you and you can sign up to listen to the events they 
send out. I would recommend starting with SBProcess, and you will see how to 
listen to events by looking at the python code.


> 
> My current code looks something like this:
> 
> SBListener listener;
> SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
>   nullptr, "/home/cynecx/dev/helloWorld",
>   0, true, error);
> 
> process.Continue();
> 
> StateType state = process.GetState(); // is stopped
> 
> SBEvent event;
> 
> while(true) {
>   if(listener.WaitForEvent(0x, event)) {
> // This branch is never hit
> SBStream stream;
> event.GetDescription(stream);
> std::cout << stream.GetData() << std::endl;
>   } else {
> break;
>   }
> }
> 
> It would help developers (IDE) a lot if there might be some 
> tutorials/documentation on how to use the API.

I agree. We will try to get this up on the web at some point in the near future.

Some more pointers:

- When launching, use a SBLaunchInfo:

const char *argv[] = { "/bin/ls", "-l", "-A", "-F", nullptr };
SBLaunchInfo launch_info(argv);
launch_info.SetWorkingDirectory("/tmp");
SBError error;
SBProcess process = target.Launch (launch_info, error);

This will allow you to fill in a SBLaunchInfo from your IDE and possibly keep 
it around for re-use on next launch.

- When attaching, use a SBAttachInfo. Same reason as launch info.

pid_t pid = 123;
SBAttachInfo attach_info(pid)

or

const bool wait_for = true;
SBAttachInfo attach_info("my_program", wait_for);

Then do:

SBProcess process = target.Attach (attach_info, error);

- I would recommend having one thread that is the main LLDB event loop and have 
this event loop also do process control. You can usually use the SBDebugger's 
listener as it will be hooked up by default to the process if you don't specify 
a listener:

SBListener listener = debugger.GetListener();
SBEvent event;
const uint32

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

[Jeffrey Tan via lldb-dev]

I am not sure. From the output, it seems lldb does stop at the entry
point(because you can issue "bt" command to dump the stack) in both
platforms; the problem seems to be that it did not emit the stopped event
for its stop on linux.

On Tue, Feb 23, 2016 at 2:03 PM, Jim Ingham  wrote:

> If the linux side is not obeying "stop_at_entry" then that is a bug.
>
> Jim
>
>
> > On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I have got lldb launch working fine on my macbook for sometime. But when
> I try the same code on Linux, it failed to emit any stopping events during
> initial launch.
> >
> > When I run the reproduce code(listed at the end), I got the following
> different results:
> >
> > The key difference is that Macbook will emit a stopped event which
> caused our IDE UI to enter break mode, while Linux violates this
> assumption. Is this a bug?
> >
> > ==Mac==
> > lldb_pythonpath:
> /Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
> > Launch result: success
> >  Listening Thread ID: 4610625536
> > dbg> Target event: ModulesLoaded
> > Process event: StateChanged, Stopped
> > Stop reason: 5
> > dbg> bt
> > * thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop
> reason = signal SIGSTOP
> >   * frame #0: 0x7fff6401a000 dyld`_dyld_start
> > ==Mac==
> >
> > ==Linux==
> > python linux_launch.py
> > find_lldb:  '/home/jeffreytan/project/llvm-bin/Debug+Asserts/lib/python2.7/site-packages/lldb/__init__.pyc'>
> > Launch result: success
> >  Listening Thread ID: 140316621375232
> > dbg> bt
> > * thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop
> reason = signal SIGSTOP
> >   * frame #0: 0x7f6165b7bb00
> > ==Linux==
> >
> > Repro main.py
> > # Should be first for LLDB package to be added to search path.
> > from find_lldb import lldb
> > import sys
> > import os
> > import time
> > from sys import stdin, stdout
> > from event_thread import LLDBListenerThread
> > import threading
> >
> >
> > def interctive_loop(debugger):
> > while (True):
> > stdout.write('dbg> ')
> > command = stdin.readline().rstrip()
> > if len(command) == 0:
> > continue
> > if command == 'q':
> > return
> > debugger.HandleCommand(command)
> >
> > def do_test():
> > debugger = lldb.SBDebugger.Create()
> > debugger.SetAsync(True)
> > executable_path =
> '~/Personal/compiler/CompilerConstruction/code/compiler'
> > target = debugger.CreateTargetWithFileAndArch(executable_path,
> lldb.LLDB_ARCH_DEFAULT)
> >
> > listener = lldb.SBListener('Event Listener')
> > error = lldb.SBError()
> > process = target.Launch (listener,
> >  None,  # argv
> >  None,  # envp
> >  None,  # stdin_path
> >  None,  # stdout_path
> >  None,  # stderr_path
> >  None,  # working directory
> >  0, # launch flags
> >  True, # Stop at entry
> >  error) # error
> > print 'Launch result: %s' % str(error)
> >
> > running_signal = threading.Event()
> > stopped_signal = threading.Event()
> > event_thread = LLDBListenerThread(debugger, running_signal,
> stopped_signal)
> > event_thread.start()
> >
> > interctive_loop(debugger)
> >
> > event_thread.should_quit = True
> > event_thread.join()
> >
> > lldb.SBDebugger.Destroy(debugger)
> > return debugger
> >
> > def main():
> > debugger = do_test()
> >
> > if __name__ == '__main__':
> > main()
> >
> > Event_thread
> > class LLDBListenerThread(Thread):
> > should_quit = False
> >
> > def __init__(self, debugger, running_signal=None,
> stopped_sigal=None):
> >   Thread.__init__(self)
> >   self._running_signal = running_signal
> >   self._stopped_sigal = stopped_sigal
> >   process = debugger.GetSelectedTarget().process
> >   self.listener = debugger.GetListener()
> >   self._add_listener_to_process(process)
> >   self._add_listener_to_target(process.target)
> >
> >
> > def _add_listener_to_target(self, target):
> > # Listen for breakpoint/watchpoint events
> (Added/Removed/Disabled/etc).
> > broadcaster = target.GetBroadcaster()
> > mask = lldb.SBTarget.eBroadcastBitBreakpointChanged |
> lldb.SBTarget.eBroadcastBitWatchpointChanged |
> lldb.SBTarget.eBroadcastBitModulesLoaded
> > broadcaster.AddListener(self.listener, mask)

[lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Ted Woodward via lldb-dev]

Background: Hexagon clang doesn't have JIT support, so lldb for Hexagon only
uses the IR Interpreter (Codeplay wrote it for us).

 

Sean, r260768 broke the expression parser with functions.

 

Without connecting to a target, I can't get the info for main:

(lldb) e main

error: Can't run the expression locally: Interpreter doesn't handle one of
the expression's operands

 

Connected to a target, I can't run a function:

(lldb) e factorial(5)

error: Can't run the expression locally: Interpreter doesn't handle one of
the expression's operands

 

 

I've traced the failure to the call to CanResolveConstant() in
IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the
working case, the Value ID is 0xa - Value::ConstantExprVal. In the failing
case, it is 0x5. Since it's defined in a .def file, I can't be sure, but my
guess is its Value::FunctionVal.

 

 

Where is the Value ID set?

 

 

 

Some info from the expr log:

 

; Function Attrs: nounwind

define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {

entry:

  %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4

  store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4

  %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  %guard.uninitialized = icmp eq i8 %0, 0

  br i1 %guard.uninitialized, label %init.check, label %init.end

 

init.check:   ; preds = %entry

  %call = call i32 @factorial(i32 5)

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align
4

  store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  br label %init.end

 

init.end: ; preds = %init.check,
%entry

  ret void

}

 

 

Unsupported constant: declare i32 @factorial(i32) #1

 

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Sean Callanan via lldb-dev]

Ted,

I’m not sure who inside Clang actually sets the value ID – it’s the code 
generator’s job to make IR, we don’t construct it.
I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
returning true.

Sean

> On Feb 23, 2016, at 3:28 PM, Ted Woodward  wrote:
> 
> Background: Hexagon clang doesn’t have JIT support, so lldb for Hexagon only 
> uses the IR Interpreter (Codeplay wrote it for us).
>  
> Sean, r260768 broke the expression parser with functions.
>  
> Without connecting to a target, I can’t get the info for main:
> (lldb) e main
> error: Can't run the expression locally: Interpreter doesn't handle one of 
> the expression's operands
>  
> Connected to a target, I can’t run a function:
> (lldb) e factorial(5)
> error: Can't run the expression locally: Interpreter doesn't handle one of 
> the expression's operands
>  
>  
> I’ve traced the failure to the call to CanResolveConstant() in 
> IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the 
> working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing 
> case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my 
> guess is its Value::FunctionVal.
>  
>  
> Where is the Value ID set?
>  
>  
>  
> Some info from the expr log:
>  
> ; Function Attrs: nounwind
> define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {
> entry:
>   %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4
>   store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4
>   %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>   %guard.uninitialized = icmp eq i8 %0, 0
>   br i1 %guard.uninitialized, label %init.check, label %init.end
>  
> init.check:   ; preds = %entry
>   %call = call i32 @factorial(i32 5)
>   store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4
>   store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>   br label %init.end
>  
> init.end: ; preds = %init.check, 
> %entry
>   ret void
> }
>  
>  
> Unsupported constant: declare i32 @factorial(i32) #1
>  
>  
> Ted
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Ted Woodward via lldb-dev]

Unfortunately, that leads to another error, in the Instruction::Store case. 
IRInterpreter::ResolveConstantValue() returns an error because it doesn’t like 
the value id of FunctionVal. “Interpreter couldn't resolve a value during 
execution”.

 

If I go back 1 commit from r260768 (r260767), it works. The value id is 0xa, 
ConstantIntVal. So something in r260768 is either setting the value id to 0x5, 
or keeping the value id from being set to 0xa.

 

Ted

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: scalla...@apple.com [mailto:scalla...@apple.com] 
Sent: Tuesday, February 23, 2016 5:41 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
expression parser with function on Hexagon

 

Ted,

 

I’m not sure who inside Clang actually sets the value ID – it’s the code 
generator’s job to make IR, we don’t construct it.

I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
returning true.

 

Sean

 

On Feb 23, 2016, at 3:28 PM, Ted Woodward mailto:ted.woodw...@codeaurora.org> > wrote:

 

Background: Hexagon clang doesn’t have JIT support, so lldb for Hexagon only 
uses the IR Interpreter (Codeplay wrote it for us).

 

Sean, r260768 broke the expression parser with functions.

 

Without connecting to a target, I can’t get the info for main:

(lldb) e main

error: Can't run the expression locally: Interpreter doesn't handle one of the 
expression's operands

 

Connected to a target, I can’t run a function:

(lldb) e factorial(5)

error: Can't run the expression locally: Interpreter doesn't handle one of the 
expression's operands

 

 

I’ve traced the failure to the call to CanResolveConstant() in 
IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the 
working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing 
case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my 
guess is its Value::FunctionVal.

 

 

Where is the Value ID set?

 

 

 

Some info from the expr log:

 

; Function Attrs: nounwind

define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {

entry:

  %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4

  store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4

  %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  %guard.uninitialized = icmp eq i8 %0, 0

  br i1 %guard.uninitialized, label %init.check, label %init.end

 

init.check:   ; preds = %entry

  %call = call i32 @factorial(i32 5)

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4

  store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1

  br label %init.end

 

init.end: ; preds = %init.check, %entry

  ret void

}

 

 

Unsupported constant: declare i32 @factorial(i32) #1

 

 

Ted

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

[Sean Callanan via lldb-dev]

At that point, I’d set a watchpoint and see what is setting it. I would expect 
that

  %call = call i32 @factorial(i32 5)

would put a normal value in call, which would then be the value stored by the 
store instruction

  store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4

The store instruction should not have an operand of function type… right?

Sean

> On Feb 23, 2016, at 4:21 PM, Ted Woodward  wrote:
> 
> Unfortunately, that leads to another error, in the Instruction::Store case. 
> IRInterpreter::ResolveConstantValue() returns an error because it doesn’t 
> like the value id of FunctionVal. “Interpreter couldn't resolve a value 
> during execution”.
>  
> If I go back 1 commit from r260768 (r260767), it works. The value id is 0xa, 
> ConstantIntVal. So something in r260768 is either setting the value id to 
> 0x5, or keeping the value id from being set to 0xa.
>  
> Ted
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: scalla...@apple.com [mailto:scalla...@apple.com] 
> Sent: Tuesday, February 23, 2016 5:41 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
> expression parser with function on Hexagon
>  
> Ted,
>  
> I’m not sure who inside Clang actually sets the value ID – it’s the code 
> generator’s job to make IR, we don’t construct it.
> I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
> returning true.
>  
> Sean
>  
>> On Feb 23, 2016, at 3:28 PM, Ted Woodward > > wrote:
>>  
>> Background: Hexagon clang doesn’t have JIT support, so lldb for Hexagon only 
>> uses the IR Interpreter (Codeplay wrote it for us).
>>  
>> Sean, r260768 broke the expression parser with functions.
>>  
>> Without connecting to a target, I can’t get the info for main:
>> (lldb) e main
>> error: Can't run the expression locally: Interpreter doesn't handle one of 
>> the expression's operands
>>  
>> Connected to a target, I can’t run a function:
>> (lldb) e factorial(5)
>> error: Can't run the expression locally: Interpreter doesn't handle one of 
>> the expression's operands
>>  
>>  
>> I’ve traced the failure to the call to CanResolveConstant() in 
>> IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the 
>> working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing 
>> case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my 
>> guess is its Value::FunctionVal.
>>  
>>  
>> Where is the Value ID set?
>>  
>>  
>>  
>> Some info from the expr log:
>>  
>> ; Function Attrs: nounwind
>> define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {
>> entry:
>>   %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4
>>   store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4
>>   %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>>   %guard.uninitialized = icmp eq i8 %0, 0
>>   br i1 %guard.uninitialized, label %init.check, label %init.end
>>  
>> init.check:   ; preds = %entry
>>   %call = call i32 @factorial(i32 5)
>>   store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4
>>   store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>>   br label %init.end
>>  
>> init.end: ; preds = %init.check, 
>> %entry
>>   ret void
>> }
>>  
>>  
>> Unsupported constant: declare i32 @factorial(i32) #1
>>  
>>  
>> Ted
>>  
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

[Jim Ingham via lldb-dev]

That also is a bug.  If it is going to do a public stop, it has to send a stop 
event.

Jim

> On Feb 23, 2016, at 2:52 PM, Jeffrey Tan  wrote:
> 
> I am not sure. From the output, it seems lldb does stop at the entry 
> point(because you can issue "bt" command to dump the stack) in both 
> platforms; the problem seems to be that it did not emit the stopped event for 
> its stop on linux.  
> 
> On Tue, Feb 23, 2016 at 2:03 PM, Jim Ingham  wrote:
> If the linux side is not obeying "stop_at_entry" then that is a bug.
> 
> Jim
> 
> 
> > On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev 
> >  wrote:
> >
> > Hi,
> >
> > I have got lldb launch working fine on my macbook for sometime. But when I 
> > try the same code on Linux, it failed to emit any stopping events during 
> > initial launch.
> >
> > When I run the reproduce code(listed at the end), I got the following 
> > different results:
> >
> > The key difference is that Macbook will emit a stopped event which caused 
> > our IDE UI to enter break mode, while Linux violates this assumption. Is 
> > this a bug?
> >
> > ==Mac==
> > lldb_pythonpath: 
> > /Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
> > Launch result: success
> >  Listening Thread ID: 4610625536
> > dbg> Target event: ModulesLoaded
> > Process event: StateChanged, Stopped
> > Stop reason: 5
> > dbg> bt
> > * thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop 
> > reason = signal SIGSTOP
> >   * frame #0: 0x7fff6401a000 dyld`_dyld_start
> > ==Mac==
> >
> > ==Linux==
> > python linux_launch.py
> > find_lldb:  > '/home/jeffreytan/project/llvm-bin/Debug+Asserts/lib/python2.7/site-packages/lldb/__init__.pyc'>
> > Launch result: success
> >  Listening Thread ID: 140316621375232
> > dbg> bt
> > * thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop reason = 
> > signal SIGSTOP
> >   * frame #0: 0x7f6165b7bb00
> > ==Linux==
> >
> > Repro main.py
> > # Should be first for LLDB package to be added to search path.
> > from find_lldb import lldb
> > import sys
> > import os
> > import time
> > from sys import stdin, stdout
> > from event_thread import LLDBListenerThread
> > import threading
> >
> >
> > def interctive_loop(debugger):
> > while (True):
> > stdout.write('dbg> ')
> > command = stdin.readline().rstrip()
> > if len(command) == 0:
> > continue
> > if command == 'q':
> > return
> > debugger.HandleCommand(command)
> >
> > def do_test():
> > debugger = lldb.SBDebugger.Create()
> > debugger.SetAsync(True)
> > executable_path = 
> > '~/Personal/compiler/CompilerConstruction/code/compiler'
> > target = debugger.CreateTargetWithFileAndArch(executable_path, 
> > lldb.LLDB_ARCH_DEFAULT)
> >
> > listener = lldb.SBListener('Event Listener')
> > error = lldb.SBError()
> > process = target.Launch (listener,
> >  None,  # argv
> >  None,  # envp
> >  None,  # stdin_path
> >  None,  # stdout_path
> >  None,  # stderr_path
> >  None,  # working directory
> >  0, # launch flags
> >  True, # Stop at entry
> >  error) # error
> > print 'Launch result: %s' % str(error)
> >
> > running_signal = threading.Event()
> > stopped_signal = threading.Event()
> > event_thread = LLDBListenerThread(debugger, running_signal, 
> > stopped_signal)
> > event_thread.start()
> >
> > interctive_loop(debugger)
> >
> > event_thread.should_quit = True
> > event_thread.join()
> >
> > lldb.SBDebugger.Destroy(debugger)
> > return debugger
> >
> > def main():
> > debugger = do_test()
> >
> > if __name__ == '__main__':
> > main()
> >
> > Event_thread
> > class LLDBListenerThread(Thread):
> > should_quit = False
> >
> > def __init__(self, debugger, running_signal=None, stopped_sigal=None):
> >   Thread.__init__(self)
> >   self._running_signal = running_signal
> >   self._stopped_sigal = stopped_sigal
> >   process = debugger.GetSelectedTarget().process
> >   self.listener = debugger.GetListener()
> >   self._add_listener_to_process(process)
> >   self._add_listener_to_target(process.target)
> >
> >
> > def _add_listener_to_target(self, target):
> > # Listen for breakpoint/watchpoint events 
> > (Added/Removed/Disabled/etc).
> > broadcaster = target.GetBroadcaster()
> > mask = lldb.SBTarget.eBr

Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged

[Ben Pope via lldb-dev]

On Wednesday, February 24, 2016 05:51 AM, Hans Wennborg via 
Release-testers wrote:

Dear testers,

Release Candidate 3 has just been tagged [1]. Please build, test, and
upload to the sftp.


On Ubuntu 15.10 x86_64 I got:

Failing Tests (2):
MemorySanitizer :: Linux/forkpty.cc
MemorySanitizer :: Linux/tcgetattr.cc

  Expected Passes: 31860
  Expected Failures  : 209
  Unsupported Tests  : 648
  Unexpected Failures: 2

With RC2 there were no failures, but it looks like 15 tests have been added.

Ben
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Jeffrey.fudan via lldb-dev]

This is a very useful read! I am also building a IDE debugger using lldb, and I 
found the initial attach/launch API and eventing system has a lot quirks. After 
getting to stopped state, querying info is relative trivial. Thanks again.

Sent from my iPad

> On Feb 23, 2016, at 2:40 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> I need to spend some time writing this up, but until then here is some info.
> 
> We created a python script that uses the LLDB public API to grab async events 
> so people can see how to do things:
> 
> svn cat 
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
> 
> If you look in here you will see the correct way to do things.
> 
> I will answer you questions inlined into your email below and then add some 
> extra tips at the end:
> 
>> On Feb 20, 2016, at 3:04 PM, Paul Peet via lldb-dev 
>>  wrote:
>> 
>> Hello,
>> 
>> I am currently working on an IDE for C++ and I would like to integrate lldb 
>> as a debugger using the C++ API but it has been difficult for me to 
>> understand the architecture because there is no documentation available 
>> (except doxygen which isn't helpful at all).
>> I am at the point understanding the Event system? How are Events created?
> 
> You need to be able to listen for events from your debug session. In order to 
> do this, SBBroadcaster objects can broadcast events as SBEvent objects. You 
> need to listen for events using a SBListener. Each SBBroadcaster will 
> broadcast events where each different kind of event is represented by one bit 
> in a 32 bit uint32_t. 
> 
>> How can I use SBListener and SBBroadcaster? (What's the function of 
>> SBBroadvaster).
> 
> Yes you can. You might want to use a SBBroadcaster to send events to your 
> main event loop in the debugger:
> 
> using namespace lldb;
> SBBroadcaster gui_event_broadcaster("gui-events");
> 
> // Define the event bits we will use for gui_event_broadcaster
> enum
> {
>  eGUIEventBitLaunch   = (1u << 0),
>  eGUIEventBitKill = (1u << 1),
>  eGUIEventBitStepOver = (1u << 2),
>  eGUIEventBitStepOut  = (1u << 3),
>  eGUIEventBitStepInto = (1u << 4),
>  eGUIEventBitContinue = (1u << 5),
>  eGUIEventBitHalt = (1u << 6),
>  eGUIEventBitQuit = (1u << 7),
>  eGUIEventAll = UINT32_MAX
> };
> 
> SBListener run_loop_listener("run-loop-listener");
> // Listen for any event from gui_event_broadcaster by listening to all event 
> bits
> run_loop_listener.StartListeningForEvents(gui_event_broadcaster, 
> eGUIEventAll);
> 
> You can then run an event loop on a thread:
> 
> void
> RunLoop()
> {
>  SBEvent event;
>  bool done = false
>  while (!done)
>  {
>if (listener.WaitForEvent(UINT32_MAX, event))
>{
>  const uint32_t event_type = event.GetType();
>  if (event.BroadcasterMatchesRef(gui_event_broadcaster))
>  {
>switch (event_type)
>{
>case eGUIEventBitLaunch:
>case eGUIEventBitKill:
>case eGUIEventBitQuit:
>}
>  }
>}
>  }
> }
> 
> 
> Then on another thread, you can broadcast events. Lets say the user clicked 
> the "kill" button in your IDE, you could broadcast an event:
> 
> gui_event_broadcaster.BroadcastEventByType(eGUIEventBitKill);
> 
> Then the event loop would receive the event, as long as it is listening for 
> these events. So you can use SBBroadcaster and SBListener yourself, but many 
> objects (like SBTarget, SBProcess and SBThread) are already broadcasters and 
> will broadcast events to you and you can sign up to listen to the events they 
> send out. I would recommend starting with SBProcess, and you will see how to 
> listen to events by looking at the python code.
> 
> 
>> 
>> My current code looks something like this:
>> 
>> SBListener listener;
>> SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
>>  nullptr, "/home/cynecx/dev/helloWorld",
>>  0, true, error);
>> 
>> process.Continue();
>> 
>> StateType state = process.GetState(); // is stopped
>> 
>> SBEvent event;
>> 
>> while(true) {
>>  if(listener.WaitForEvent(0x, event)) {
>>// This branch is never hit
>>SBStream stream;
>>event.GetDescription(stream);
>>std::cout << stream.GetData() << std::endl;
>>  } else {
>>break;
>>  }
>> }
>> 
>> It would help developers (IDE) a lot if there might be some 
>> tutorials/documentation on how to use the API.
> 
> I agree. We will try to get this up on the web at some point in the near 
> future.
> 
> Some more pointers:
> 
> - When launching, use a SBLaunchInfo:
> 
> const char *argv[] = { "/bin/ls", "-l", "-A", "-F", nullptr };
> SBLaunchInfo launch_info(argv);
> launch_info.SetWorkingDirectory("/tmp");
> SBError error;
> SBProcess process = target.Launch (launch_info, error);
> 
> This will allow you to fill in a SBLaunchInfo from your IDE and possibly keep 
> it around for re-use on next launch.
> 
> - When attaching, use a SBAttachInfo. Same reason as launch 

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

[Jeffrey.fudan via lldb-dev]

Makes sense, will file a bug for it.

Sent from my iPad

> On Feb 23, 2016, at 5:10 PM, Jim Ingham  wrote:
> 
> That also is a bug.  If it is going to do a public stop, it has to send a 
> stop event.
> 
> Jim
> 
>> On Feb 23, 2016, at 2:52 PM, Jeffrey Tan  wrote:
>> 
>> I am not sure. From the output, it seems lldb does stop at the entry 
>> point(because you can issue "bt" command to dump the stack) in both 
>> platforms; the problem seems to be that it did not emit the stopped event 
>> for its stop on linux.  
>> 
>> On Tue, Feb 23, 2016 at 2:03 PM, Jim Ingham  wrote:
>> If the linux side is not obeying "stop_at_entry" then that is a bug.
>> 
>> Jim
>> 
>> 
>>> On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I have got lldb launch working fine on my macbook for sometime. But when I 
>>> try the same code on Linux, it failed to emit any stopping events during 
>>> initial launch.
>>> 
>>> When I run the reproduce code(listed at the end), I got the following 
>>> different results:
>>> 
>>> The key difference is that Macbook will emit a stopped event which caused 
>>> our IDE UI to enter break mode, while Linux violates this assumption. Is 
>>> this a bug?
>>> 
>>> ==Mac==
>>> lldb_pythonpath: 
>>> /Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
>>> Launch result: success
>>>  Listening Thread ID: 4610625536
>>> dbg> Target event: ModulesLoaded
>>> Process event: StateChanged, Stopped
>>> Stop reason: 5
>>> dbg> bt
>>> * thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop 
>>> reason = signal SIGSTOP
>>>  * frame #0: 0x7fff6401a000 dyld`_dyld_start
>>> ==Mac==
>>> 
>>> ==Linux==
>>> python linux_launch.py
>>> find_lldb: >> '/home/jeffreytan/project/llvm-bin/Debug+Asserts/lib/python2.7/site-packages/lldb/__init__.pyc'>
>>> Launch result: success
>>>  Listening Thread ID: 140316621375232
>>> dbg> bt
>>> * thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop reason = 
>>> signal SIGSTOP
>>>  * frame #0: 0x7f6165b7bb00
>>> ==Linux==
>>> 
>>> Repro main.py
>>> # Should be first for LLDB package to be added to search path.
>>> from find_lldb import lldb
>>> import sys
>>> import os
>>> import time
>>> from sys import stdin, stdout
>>> from event_thread import LLDBListenerThread
>>> import threading
>>> 
>>> 
>>> def interctive_loop(debugger):
>>>while (True):
>>>stdout.write('dbg> ')
>>>command = stdin.readline().rstrip()
>>>if len(command) == 0:
>>>continue
>>>if command == 'q':
>>>return
>>>debugger.HandleCommand(command)
>>> 
>>> def do_test():
>>>debugger = lldb.SBDebugger.Create()
>>>debugger.SetAsync(True)
>>>executable_path = 
>>> '~/Personal/compiler/CompilerConstruction/code/compiler'
>>>target = debugger.CreateTargetWithFileAndArch(executable_path, 
>>> lldb.LLDB_ARCH_DEFAULT)
>>> 
>>>listener = lldb.SBListener('Event Listener')
>>>error = lldb.SBError()
>>>process = target.Launch (listener,
>>> None,  # argv
>>> None,  # envp
>>> None,  # stdin_path
>>> None,  # stdout_path
>>> None,  # stderr_path
>>> None,  # working directory
>>> 0, # launch flags
>>> True, # Stop at entry
>>> error) # error
>>>print 'Launch result: %s' % str(error)
>>> 
>>>running_signal = threading.Event()
>>>stopped_signal = threading.Event()
>>>event_thread = LLDBListenerThread(debugger, running_signal, 
>>> stopped_signal)
>>>event_thread.start()
>>> 
>>>interctive_loop(debugger)
>>> 
>>>event_thread.should_quit = True
>>>event_thread.join()
>>> 
>>>lldb.SBDebugger.Destroy(debugger)
>>>return debugger
>>> 
>>> def main():
>>>debugger = do_test()
>>> 
>>> if __name__ == '__main__':
>>>main()
>>> 
>>> Event_thread
>>> class LLDBListenerThread(Thread):
>>>should_quit = False
>>> 
>>>def __init__(self, debugger, running_signal=None, stopped_sigal=None):
>>>  Thread.__init__(self)
>>>  self._running_signal = running_signal
>>>  self._stopped_sigal = stopped_sigal
>>>  process = debugger.GetSelectedTarget().process
>>>  self.listener = debugger.GetListener()
>>>  self._add_listener_to_process(process)
>>>  self._add_listener_to_target(process.target)
>>> 
>>> 
>>>def _add_listener_to_target(self, target):
>>># Listen for breakpoint/watchpoint events 
>>> (Added/Remo