[lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread René J . V . Bertin via lldb-dev 
Hi,

I've been working on a MacPorts port for lldb (MacPorts already provides ports 
for llvm and clang; cf. https://trac.macports.org/ticket/45251). Using the 
Xcode project isn't really an option here, so I've based my approach on the 
instructions for building using CMake on *n*x. 

In short:

- unpack llvm sources
- unpack lldb sources in the expected location in the llvm tree
- call cmake from an out-of-tree build directory pointing it to the toplevel 
CMakeLists.txt (i.e. the one in llvm-src)
- call make in the lldb subdir under the build directory (build/tools/lldb).

The nice thing with CMake's Makefiles generator is that it is usually able to 
figure out what needs to be built from upstreams when make is called in a 
project subdirectory, and this works with lldb.

Yet I've been asked to look into the possibility of building *just* lldb, using 
whatever dependencies it requires from the already installed llvm+clang 
directory.

I'm presuming that there might be a benefit to that approach on other Unices 
too. Has anyone tried whether this is the case, assuming that it's actually 
possible?

NB: MacPorts' port:lldb will depend on port:llvm and port:clang, so prebuilt 
dependencies will be available, as long as nothing is required that is omitted 
from a standard install.

Thanks,
René
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread Pavel Labath via lldb-dev 
Hi Rene,

building lldb on osx with cmake should work fine when you're doing it
as a part of llvm (our buildbot is doing it
).

What you are asking for is called a "standalone" build of LLDB. I
don't think anyone has tried it on a mac, but other people are using
it, with varying levels of success. You should look at
lldb/cmake/modules/LLDBStandalone.cmake for how to set it up. As far
as I know, the main trick is pointing your build to the llvm-config
binary installed by the llvm package (you should just check out the
lldb repo, without llvm and clang sources).

good luck,
pl


On 9 September 2016 at 09:55, René J.V. Bertin via lldb-dev
 wrote:
> Hi,
>
> I've been working on a MacPorts port for lldb (MacPorts already provides 
> ports for llvm and clang; cf. https://trac.macports.org/ticket/45251). Using 
> the Xcode project isn't really an option here, so I've based my approach on 
> the instructions for building using CMake on *n*x.
>
> In short:
>
> - unpack llvm sources
> - unpack lldb sources in the expected location in the llvm tree
> - call cmake from an out-of-tree build directory pointing it to the toplevel 
> CMakeLists.txt (i.e. the one in llvm-src)
> - call make in the lldb subdir under the build directory (build/tools/lldb).
>
> The nice thing with CMake's Makefiles generator is that it is usually able to 
> figure out what needs to be built from upstreams when make is called in a 
> project subdirectory, and this works with lldb.
>
> Yet I've been asked to look into the possibility of building *just* lldb, 
> using whatever dependencies it requires from the already installed llvm+clang 
> directory.
>
> I'm presuming that there might be a benefit to that approach on other Unices 
> too. Has anyone tried whether this is the case, assuming that it's actually 
> possible?
>
> NB: MacPorts' port:lldb will depend on port:llvm and port:clang, so prebuilt 
> dependencies will be available, as long as nothing is required that is 
> omitted from a standard install.
>
> Thanks,
> René
> ___
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread René J . V . Bertin via lldb-dev 
On Friday September 09 2016 10:42:34 Pavel Labath wrote:

Hi Pavel

Thanks for pointing me to
> Hi Rene,

> lldb/cmake/modules/LLDBStandalone.cmake for how to set it up. As far
> as I know, the main trick is pointing your build to the llvm-config
> binary installed by the llvm package

So, adding

 -DLLVM_CONFIG=/opt/local/libexec/llvm-3.9/bin/llvm-config 
-DLLVM_DIR=/opt/local/libexec/llvm-3.9/lib/cmake/llvm

almost allows cmake to succeed when pointed to ../llvm-3.9.0.src/tools/lldb, 
except for 1 pesky error:

-- Found LLVM_CONFIG as /opt/local/libexec/llvm-3.9/bin/llvm-config
-- Building with -fPIC
CMake Error at cmake/modules/LLDBStandalone.cmake:89 (include):
  include could not find load file:

CheckAtomic
Call Stack (most recent call first):
  CMakeLists.txt:3 (include)

and with reason: the path to that file is 
llvm-3.9.0.src/cmake/modules/CheckAtomic.cmake

> (you should just check out the
> lldb repo, without llvm and clang sources).

Yeah, one would hope for that, eh? :)

Thanks,
René
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem with watchpoints

2016-09-09 Thread Greg Clayton via lldb-dev 

> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I recently discovered a problem with watchpoints talking to the Hexagon 
> simulator:
>  
> (lldb) w s e 0x1000
> error: Watchpoint creation failed (addr=0x1000, size=4).
> error: Target supports (0) hardware watchpoint slots.
>  
>  
> It seems that lldb now sends a qWatchpointSupportInfo packet. But this packet 
> isn’t defined in lldb-gdb-remote.txt.
>  
> Looking at the code, it expects to get back a pair “num:#”. If it doesn’t it 
> returns 0. The caller will report the above error if the number returned is 
> 0. So if qWatchpointSupportInfo isn’t supported, lldb can’t set a watchpoint.
>  
>  
> What is the definition of the response to qWatchpointSupportInfo? Is the the 
> number of supported watchpoints, or the number of available watchpoints? If 
> it’s supported, then CheckIfWatchpointsExhausted won’t really check if the 
> watchpoints are exhausted. If it’s available, then a return of 0 doesn’t let 
> us aggregate watchpoints – a 4 byte watchpoint at 0x1000 and one at 0x1004 
> could be one going from 0x1000-0x1007.

The person that checked this in no longer is working on LLDB and it has been 
like this since May 2012. It should return the total number of supported 
watchpoints. 
>  
> Wouldn’t it be better to try to set the watchpoint, then report a failure if 
> we get an error back from the remote server?

It is kind of nice to know that you can't set watchpoints because they aren't 
supported since we can provide a nicer message than "E98 returned from GDB 
server". Errors in GDB remote protocol are a horrible mess and they don't mean 
anything. So any clearer we can be about this, the better, so we should keep 
the qWatchpointSupportInfo packet IMHO. I am fine with us modifying the 
GDBRemoteCommunicationClient to try and send this packet and if it comes back 
as unimplemented (response of $#00), you can set the num supported hardware 
watchpoints to UINT32_MAX. We should document that this means we don't know how 
many hardware watchpoints are supported, but it should then allow us to set 
hardware watchpoints if the GDB server doesn't support this packet. 

Watchpoints definitely need some work as they were done quickly by someone that 
is no longer around and they could use some TLC. 

>  
> --
> 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
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread Greg Clayton via lldb-dev 
The biggest issue with trying to use cmake on macOS is that there is no support 
for building frameworks, please correct me if I am wrong. The xcode build will 
build a "LLDB.framework" that contains all headers and the shared library, and 
the "lldb" command line tool that links against that. We really want the 
LLDB.framework since it gives us a bundle like directory that contains 
everything we need. Current the LLDB.framework contains:
- LLDB headers
- clang headers needed for expression compilation where the compiler parses 
modules
- associated binaries needed for debugging (lldb-server, lldb-argdumper, 
debugserver, darwin-debug
- Python module and packages
- XPC services for debugging as root

I believe the normal cmake build just will build a lldb.dylib or lldb.so 
instead of a LLDB.framework. Then you would need to find a place for all of the 
remaining stuff just like you have to do on linux. 

With MacPorts, do all projects tend to not build frameworks, or do some build 
frameworks?

Greg Clayton
> On Sep 9, 2016, at 1:55 AM, René J.V. Bertin via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I've been working on a MacPorts port for lldb (MacPorts already provides 
> ports for llvm and clang; cf. https://trac.macports.org/ticket/45251). Using 
> the Xcode project isn't really an option here, so I've based my approach on 
> the instructions for building using CMake on *n*x. 
> 
> In short:
> 
> - unpack llvm sources
> - unpack lldb sources in the expected location in the llvm tree
> - call cmake from an out-of-tree build directory pointing it to the toplevel 
> CMakeLists.txt (i.e. the one in llvm-src)
> - call make in the lldb subdir under the build directory (build/tools/lldb).
> 
> The nice thing with CMake's Makefiles generator is that it is usually able to 
> figure out what needs to be built from upstreams when make is called in a 
> project subdirectory, and this works with lldb.
> 
> Yet I've been asked to look into the possibility of building *just* lldb, 
> using whatever dependencies it requires from the already installed llvm+clang 
> directory.
> 
> I'm presuming that there might be a benefit to that approach on other Unices 
> too. Has anyone tried whether this is the case, assuming that it's actually 
> possible?
> 
> NB: MacPorts' port:lldb will depend on port:llvm and port:clang, so prebuilt 
> dependencies will be available, as long as nothing is required that is 
> omitted from a standard install.
> 
> Thanks,
> René
> ___
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread Zachary Turner via lldb-dev 
It's possible they weren't supported in the past, but creating Frameworks
is definitely supported now.

https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html#apple-frameworks
https://cmake.org/cmake/help/v3.6/prop_tgt/FRAMEWORK.html#prop_tgt:FRAMEWORK

Here's a more detailed example.

https://gitlab.kitware.com/cmake/cmake/blob/v3.6.2/Tests/Framework/CMakeLists.txt


On Fri, Sep 9, 2016 at 10:34 AM Greg Clayton via lldb-dev <
[email protected]> wrote:

> The biggest issue with trying to use cmake on macOS is that there is no
> support for building frameworks, please correct me if I am wrong. The xcode
> build will build a "LLDB.framework" that contains all headers and the
> shared library, and the "lldb" command line tool that links against that.
> We really want the LLDB.framework since it gives us a bundle like directory
> that contains everything we need. Current the LLDB.framework contains:
> - LLDB headers
> - clang headers needed for expression compilation where the compiler
> parses modules
> - associated binaries needed for debugging (lldb-server, lldb-argdumper,
> debugserver, darwin-debug
> - Python module and packages
> - XPC services for debugging as root
>
> I believe the normal cmake build just will build a lldb.dylib or lldb.so
> instead of a LLDB.framework. Then you would need to find a place for all of
> the remaining stuff just like you have to do on linux.
>
> With MacPorts, do all projects tend to not build frameworks, or do some
> build frameworks?
>
> Greg Clayton
> > On Sep 9, 2016, at 1:55 AM, René J.V. Bertin via lldb-dev <
> [email protected]> wrote:
> >
> > Hi,
> >
> > I've been working on a MacPorts port for lldb (MacPorts already provides
> ports for llvm and clang; cf. https://trac.macports.org/ticket/45251).
> Using the Xcode project isn't really an option here, so I've based my
> approach on the instructions for building using CMake on *n*x.
> >
> > In short:
> >
> > - unpack llvm sources
> > - unpack lldb sources in the expected location in the llvm tree
> > - call cmake from an out-of-tree build directory pointing it to the
> toplevel CMakeLists.txt (i.e. the one in llvm-src)
> > - call make in the lldb subdir under the build directory
> (build/tools/lldb).
> >
> > The nice thing with CMake's Makefiles generator is that it is usually
> able to figure out what needs to be built from upstreams when make is
> called in a project subdirectory, and this works with lldb.
> >
> > Yet I've been asked to look into the possibility of building *just*
> lldb, using whatever dependencies it requires from the already installed
> llvm+clang directory.
> >
> > I'm presuming that there might be a benefit to that approach on other
> Unices too. Has anyone tried whether this is the case, assuming that it's
> actually possible?
> >
> > NB: MacPorts' port:lldb will depend on port:llvm and port:clang, so
> prebuilt dependencies will be available, as long as nothing is required
> that is omitted from a standard install.
> >
> > Thanks,
> > René
> > ___
> > lldb-dev mailing list
> > [email protected]
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread René J . V . Bertin via lldb-dev 
On Friday September 09 2016 10:34:37 Greg Clayton wrote:

Hi,

>The biggest issue with trying to use cmake on macOS is that there is no 
>support for building frameworks, please correct me if I am wrong. The xcode 
>build will build a "LLDB.framework" that contains all headers and the shared 
>library, and the "lldb" command line tool that links against that. We really 
>want the LLDB.framework since it gives us a bundle like directory that 
>contains everything we need. 

That may not be supported by the current cmake system, but cmake definitely 
supports the possibility as pointed out by Zachary.
However, it's not an issue for MacPorts. In fact,

>Current the LLDB.framework contains:
>- LLDB headers
>- clang headers needed for expression compilation where the compiler parses 
>modules
>- associated binaries needed for debugging (lldb-server, lldb-argdumper, 
>debugserver, darwin-debug
>- Python module and packages

This is may be an issue with MacPorts. I haven't looked at that.

Since you mention it: the other parts of LLVM and Clang aren't built as 
frameworks, correct? If Xcode were to include an llvm-config utility, would it 
point dependents to the correct locations inside the framework(s)?

>- XPC services for debugging as root

>
>I believe the normal cmake build just will build a lldb.dylib or lldb.so 
>instead of a LLDB.framework. Then you would need to find a place for all of 
>the remaining stuff just like you have to do on linux. 

Indeed. And that just works without any problem at all; the stuff all gets 
installed into ${prefix}/libexec/llvm-${branch}.

>
>With MacPorts, do all projects tend to not build frameworks, or do some build 
>frameworks?

Some build frameworks, but as a general rule of thumb one can say that 
cross-platform software is built and installed as it would on any other Unix 
system. That's the best guarantee that the largest selection of dependent 
software will also build.

Example: Qt builds frameworks even under MacPorts, just to be sure we install 
.dylib symlinks to the framework binaries (which AFAIK are redundant nowadays). 
But all of KDE builds regular shared libraries that link to the Qt frameworks 
without a glitch. To make things even more "perverse": Qt installs a range of 
plugins, which go into standard XDG-compliant locations.

R.
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread René J . V . Bertin via lldb-dev 
Hi,

I wanted to see how far I could get with a standalone build, so I copied the 
missing CheckAtomic.cmake file into the installed cmake/llvm directory, and 
tried to build lldb. 
It aborted at 93% because it tried to include a headerfile from the llvm source:

{{{
In file included from 
/opt/local/var/macports/build/_opt_local_site-ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-mi/MICmdCmdData.cpp:45:
/opt/local/var/macports/build/_opt_local_site-ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-mi/MIUtilParse.h:13:10:
 fatal error: 
  '../lib/Support/regex_impl.h' file not found
#include "../lib/Support/regex_impl.h"
 ^
1 error generated.
}}}

To be honest, I'm not sure how this could have worked with my approach of 
calling make in build/tools/lldb, but that looks like a clear bug if standalone 
builds are to be possible.

R.
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread Zachary Turner via lldb-dev 
Yes, this is a bug in LLDB.  You're welcome to try to fix it by changing it
to include "llvm/Support/Regex.h" instead of this private header.  Not sure
if you will run into any issues, but in theory I see no reason why it
shouldn't work.

On Fri, Sep 9, 2016 at 12:37 PM René J.V. Bertin via lldb-dev <
[email protected]> wrote:

> Hi,
>
> I wanted to see how far I could get with a standalone build, so I copied
> the missing CheckAtomic.cmake file into the installed cmake/llvm directory,
> and tried to build lldb.
> It aborted at 93% because it tried to include a headerfile from the llvm
> source:
>
> {{{
> In file included from
> /opt/local/var/macports/build/_opt_local_site-ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-mi/MICmdCmdData.cpp:45:
> /opt/local/var/macports/build/_opt_local_site-ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-mi/MIUtilParse.h:13:10:
> fatal error:
>   '../lib/Support/regex_impl.h' file not found
> #include "../lib/Support/regex_impl.h"
>  ^
> 1 error generated.
> }}}
>
> To be honest, I'm not sure how this could have worked with my approach of
> calling make in build/tools/lldb, but that looks like a clear bug if
> standalone builds are to be possible.
>
> R.
> ___
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-09 Thread Zachary Turner via lldb-dev 
To be completely honest with you I don't even know why this class exists.
All it needs to do is use llvm's regex class.  The entire MIUtilParse.h /
.cpp files can be deleted as far as I'm concerned.

On Fri, Sep 9, 2016 at 12:45 PM Zachary Turner  wrote:

> Yes, this is a bug in LLDB.  You're welcome to try to fix it by changing
> it to include "llvm/Support/Regex.h" instead of this private header.  Not
> sure if you will run into any issues, but in theory I see no reason why it
> shouldn't work.
>
> On Fri, Sep 9, 2016 at 12:37 PM René J.V. Bertin via lldb-dev <
> [email protected]> wrote:
>
> Hi,
>
> I wanted to see how far I could get with a standalone build, so I copied
> the missing CheckAtomic.cmake file into the installed cmake/llvm directory,
> and tried to build lldb.
> It aborted at 93% because it tried to include a headerfile from the llvm
> source:
>
> {{{
> In file included from
> /opt/local/var/macports/build/_opt_local_site-ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-mi/MICmdCmdData.cpp:45:
> /opt/local/var/macports/build/_opt_local_site-ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-mi/MIUtilParse.h:13:10:
> fatal error:
>   '../lib/Support/regex_impl.h' file not found
> #include "../lib/Support/regex_impl.h"
>  ^
> 1 error generated.
> }}}
>
> To be honest, I'm not sure how this could have worked with my approach of
> calling make in build/tools/lldb, but that looks like a clear bug if
> standalone builds are to be possible.
>
> R.
> ___
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem with watchpoints

2016-09-09 Thread Daniel Noland via lldb-dev 
I have also noticed a few problems similar to Ted's and I plan to
address them assuming nobody else is already on it.  That said, I am new
around here so please bear with me :)

In fact, I have been hacking on a few watchpoint methods for a while
now.  I have implemented some features I personally wanted (specifically
callback functions in the SBWatchpoint api). 

I have not yet created a PR (or whatever SVN equivalent) for several
reasons (obviously including the big reformat), but mostly I am a bit
lost with respect to proper procedure here.  I have gone through the
code guidelines for LLVM and LLDB, but I am confused about some things.

* I have written unit test logic, but I don't really understand the LLDB
testing framework.  Also, I understand from other threads that the
framework is currently in flux in any case.

* I have written documentation, but I don't know if what I have written
is even desirable.  For instance, the corresponding breakpoint
implementation is almost totally lacking in source doc.

* I will need to rebase this patch on the reformatted code.  That is no
big deal, but I have little experience with SVN and I will need to do
some research to avoid turning an eventual merge into a big chore.

* I am pretty unclear on the appropriate way to make my changes work
with the Python API.  Should that be on a different PR?  Are we
targeting Python 2.7 and 3.{4,5} on all platforms?

* Do I need to check that the test suite passes on other platforms, or
will other devs take care of that?  I don't use OSX or Windows.

Basically, I would like to help, but more than that I want my "help" to
be helpful.

If somebody who knows what is going on would help me out I would greatly
appreciate it.

\author{Daniel Noland}

On 09/09/2016 11:28 AM, Greg Clayton via lldb-dev wrote:
>> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev 
>>  wrote:
>>
>> I recently discovered a problem with watchpoints talking to the Hexagon 
>> simulator:
>>  
>> (lldb) w s e 0x1000
>> error: Watchpoint creation failed (addr=0x1000, size=4).
>> error: Target supports (0) hardware watchpoint slots.
>>  
>>  
>> It seems that lldb now sends a qWatchpointSupportInfo packet. But this 
>> packet isn’t defined in lldb-gdb-remote.txt.
>>  
>> Looking at the code, it expects to get back a pair “num:#”. If it doesn’t it 
>> returns 0. The caller will report the above error if the number returned is 
>> 0. So if qWatchpointSupportInfo isn’t supported, lldb can’t set a watchpoint.
>>  
>>  
>> What is the definition of the response to qWatchpointSupportInfo? Is the the 
>> number of supported watchpoints, or the number of available watchpoints? If 
>> it’s supported, then CheckIfWatchpointsExhausted won’t really check if the 
>> watchpoints are exhausted. If it’s available, then a return of 0 doesn’t let 
>> us aggregate watchpoints – a 4 byte watchpoint at 0x1000 and one at 0x1004 
>> could be one going from 0x1000-0x1007.
> The person that checked this in no longer is working on LLDB and it has been 
> like this since May 2012. It should return the total number of supported 
> watchpoints. 
>>  
>> Wouldn’t it be better to try to set the watchpoint, then report a failure if 
>> we get an error back from the remote server?
> It is kind of nice to know that you can't set watchpoints because they aren't 
> supported since we can provide a nicer message than "E98 returned from GDB 
> server". Errors in GDB remote protocol are a horrible mess and they don't 
> mean anything. So any clearer we can be about this, the better, so we should 
> keep the qWatchpointSupportInfo packet IMHO. I am fine with us modifying the 
> GDBRemoteCommunicationClient to try and send this packet and if it comes back 
> as unimplemented (response of $#00), you can set the num supported hardware 
> watchpoints to UINT32_MAX. We should document that this means we don't know 
> how many hardware watchpoints are supported, but it should then allow us to 
> set hardware watchpoints if the GDB server doesn't support this packet. 
>
> Watchpoints definitely need some work as they were done quickly by someone 
> that is no longer around and they could use some TLC. 
>
>>  
>> --
>> 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
>> [email protected]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem with watchpoints

2016-09-09 Thread Jim Ingham via lldb-dev 
The main problem with the watchpoint code is that it doesn't share nearly as 
much of the implementation of options and callback handling with the 
breakpoints as it should.  For instance, there's very little need for 
WatchpointOptions and BreakpointOptions to be separate classes, they do pretty 
much exactly the same thing.  If you want to hack on this, the best approach I 
think would be to remove the watchpoint options, and see how far you can get 
using the breakpoint option class.  I bet a lot of goodness will fall out of 
that.  The PerformActions for the StopInfoWatchpoint and StopInfoBreakpoint 
could probably share much of their implementations as well.  This is one of 
those cleanups that's been floating around on all our to-do lists for a while 
now, but keeps getting displaced by other tasks.

The BreakpointOptions.h and WatchpointOptions.h files a pretty well documented. 
 That's a fairly good example of how we used to do this.  We don't tend to put 
top-level docs in .cpp files.

Jim


> On Sep 9, 2016, at 2:13 PM, Daniel Noland via lldb-dev 
>  wrote:
> 
> I have also noticed a few problems similar to Ted's and I plan to
> address them assuming nobody else is already on it.  That said, I am new
> around here so please bear with me :)
> 
> In fact, I have been hacking on a few watchpoint methods for a while
> now.  I have implemented some features I personally wanted (specifically
> callback functions in the SBWatchpoint api). 
> 
> I have not yet created a PR (or whatever SVN equivalent) for several
> reasons (obviously including the big reformat), but mostly I am a bit
> lost with respect to proper procedure here.  I have gone through the
> code guidelines for LLVM and LLDB, but I am confused about some things.
> 
> * I have written unit test logic, but I don't really understand the LLDB
> testing framework.  Also, I understand from other threads that the
> framework is currently in flux in any case.
> 
> * I have written documentation, but I don't know if what I have written
> is even desirable.  For instance, the corresponding breakpoint
> implementation is almost totally lacking in source doc.
> 
> * I will need to rebase this patch on the reformatted code.  That is no
> big deal, but I have little experience with SVN and I will need to do
> some research to avoid turning an eventual merge into a big chore.
> 
> * I am pretty unclear on the appropriate way to make my changes work
> with the Python API.  Should that be on a different PR?  Are we
> targeting Python 2.7 and 3.{4,5} on all platforms?
> 
> * Do I need to check that the test suite passes on other platforms, or
> will other devs take care of that?  I don't use OSX or Windows.
> 
> Basically, I would like to help, but more than that I want my "help" to
> be helpful.
> 
> If somebody who knows what is going on would help me out I would greatly
> appreciate it.
> 
> \author{Daniel Noland}
> 
> On 09/09/2016 11:28 AM, Greg Clayton via lldb-dev wrote:
>>> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev 
>>>  wrote:
>>> 
>>> I recently discovered a problem with watchpoints talking to the Hexagon 
>>> simulator:
>>> 
>>> (lldb) w s e 0x1000
>>> error: Watchpoint creation failed (addr=0x1000, size=4).
>>> error: Target supports (0) hardware watchpoint slots.
>>> 
>>> 
>>> It seems that lldb now sends a qWatchpointSupportInfo packet. But this 
>>> packet isn’t defined in lldb-gdb-remote.txt.
>>> 
>>> Looking at the code, it expects to get back a pair “num:#”. If it doesn’t 
>>> it returns 0. The caller will report the above error if the number returned 
>>> is 0. So if qWatchpointSupportInfo isn’t supported, lldb can’t set a 
>>> watchpoint.
>>> 
>>> 
>>> What is the definition of the response to qWatchpointSupportInfo? Is the 
>>> the number of supported watchpoints, or the number of available 
>>> watchpoints? If it’s supported, then CheckIfWatchpointsExhausted won’t 
>>> really check if the watchpoints are exhausted. If it’s available, then a 
>>> return of 0 doesn’t let us aggregate watchpoints – a 4 byte watchpoint at 
>>> 0x1000 and one at 0x1004 could be one going from 0x1000-0x1007.
>> The person that checked this in no longer is working on LLDB and it has been 
>> like this since May 2012. It should return the total number of supported 
>> watchpoints. 
>>> 
>>> Wouldn’t it be better to try to set the watchpoint, then report a failure 
>>> if we get an error back from the remote server?
>> It is kind of nice to know that you can't set watchpoints because they 
>> aren't supported since we can provide a nicer message than "E98 returned 
>> from GDB server". Errors in GDB remote protocol are a horrible mess and they 
>> don't mean anything. So any clearer we can be about this, the better, so we 
>> should keep the qWatchpointSupportInfo packet IMHO. I am fine with us 
>> modifying the GDBRemoteCommunicationClient to try and send this packet and 
>> if it comes back as unimplemented (response of $#00), you can set the num

Re: [lldb-dev] Problem with watchpoints

2016-09-09 Thread Daniel Noland via lldb-dev 
Yes, that was pretty much my assessment when I read through the code.

My existing patch (which I will post when I get home) takes a very
conservative approach and only modifies what is strictly necessary to make
the callback feature work.

That said, I found myself copy / paste / slight changing a fair bit of code
to make it work.  Usually a very bad sign.

If we can agree that a more aggressive refactor is desirable I would prefer
that route.

It may be worth looking at the GDB Python API (
https://sourceware.org/gdb/onlinedocs/gdb/Breakpoints-In-Python.html#Breakpoints-In-Python).
Watchpoints are just a species of breakpoint in that implementation.

I have done extensive work with that API, and while there are things I
would do very differently, I generally consider it to be fairly good.

In fact, I think that the LLDB SB API could profit quite a bit from several
of the things GDB has done on that front.  That is particularly true with
respect to symbols, variables, and frames.  That subject likely deserves a
different thread.

\author{Dan}

On Fri, Sep 9, 2016 at 3:52 PM, Jim Ingham  wrote:

> The main problem with the watchpoint code is that it doesn't share nearly
> as much of the implementation of options and callback handling with the
> breakpoints as it should.  For instance, there's very little need for
> WatchpointOptions and BreakpointOptions to be separate classes, they do
> pretty much exactly the same thing.  If you want to hack on this, the best
> approach I think would be to remove the watchpoint options, and see how far
> you can get using the breakpoint option class.  I bet a lot of goodness
> will fall out of that.  The PerformActions for the StopInfoWatchpoint and
> StopInfoBreakpoint could probably share much of their implementations as
> well.  This is one of those cleanups that's been floating around on all our
> to-do lists for a while now, but keeps getting displaced by other tasks.
>
> The BreakpointOptions.h and WatchpointOptions.h files a pretty well
> documented.  That's a fairly good example of how we used to do this.  We
> don't tend to put top-level docs in .cpp files.
>
> Jim
>
>
> > On Sep 9, 2016, at 2:13 PM, Daniel Noland via lldb-dev <
> [email protected]> wrote:
> >
> > I have also noticed a few problems similar to Ted's and I plan to
> > address them assuming nobody else is already on it.  That said, I am new
> > around here so please bear with me :)
> >
> > In fact, I have been hacking on a few watchpoint methods for a while
> > now.  I have implemented some features I personally wanted (specifically
> > callback functions in the SBWatchpoint api).
> >
> > I have not yet created a PR (or whatever SVN equivalent) for several
> > reasons (obviously including the big reformat), but mostly I am a bit
> > lost with respect to proper procedure here.  I have gone through the
> > code guidelines for LLVM and LLDB, but I am confused about some things.
> >
> > * I have written unit test logic, but I don't really understand the LLDB
> > testing framework.  Also, I understand from other threads that the
> > framework is currently in flux in any case.
> >
> > * I have written documentation, but I don't know if what I have written
> > is even desirable.  For instance, the corresponding breakpoint
> > implementation is almost totally lacking in source doc.
> >
> > * I will need to rebase this patch on the reformatted code.  That is no
> > big deal, but I have little experience with SVN and I will need to do
> > some research to avoid turning an eventual merge into a big chore.
> >
> > * I am pretty unclear on the appropriate way to make my changes work
> > with the Python API.  Should that be on a different PR?  Are we
> > targeting Python 2.7 and 3.{4,5} on all platforms?
> >
> > * Do I need to check that the test suite passes on other platforms, or
> > will other devs take care of that?  I don't use OSX or Windows.
> >
> > Basically, I would like to help, but more than that I want my "help" to
> > be helpful.
> >
> > If somebody who knows what is going on would help me out I would greatly
> > appreciate it.
> >
> > \author{Daniel Noland}
> >
> > On 09/09/2016 11:28 AM, Greg Clayton via lldb-dev wrote:
> >>> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev <
> [email protected]> wrote:
> >>>
> >>> I recently discovered a problem with watchpoints talking to the
> Hexagon simulator:
> >>>
> >>> (lldb) w s e 0x1000
> >>> error: Watchpoint creation failed (addr=0x1000, size=4).
> >>> error: Target supports (0) hardware watchpoint slots.
> >>>
> >>>
> >>> It seems that lldb now sends a qWatchpointSupportInfo packet. But this
> packet isn’t defined in lldb-gdb-remote.txt.
> >>>
> >>> Looking at the code, it expects to get back a pair “num:#”. If it
> doesn’t it returns 0. The caller will report the above error if the number
> returned is 0. So if qWatchpointSupportInfo isn’t supported, lldb can’t set
> a watchpoint.
> >>>
> >>>
> >>> What is the definition of the respo