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

[karnajit wangkhem via lldb-dev]

Thanks for the info. I will keep that in mind.

On Mon, Aug 28, 2017 at 11:05 PM, Jim Ingham  wrote:

> That will be great!  Last time we were more aggressive about normalizing
> paths we caused a decent performance regression by normalizing all the
> paths every time we did a file-name compare for setting breakpoints.  If
> you look at FileSpec::Equal we added some "is it worth doing this work"
> preparatory work.  I don't know where you'll find the additional places
> this needed to be done, but it's worth keeping an eye out for not putting
> GetNormalizedPath on a hot path.
>
> Jim
>
>
>
> > On Aug 28, 2017, at 1:19 AM, karnajit wangkhem 
> wrote:
> >
> > Thanks Jim for the help. I would definitely like to work on this PR soon.
> >
> > Filed the PR here
> > https://bugs.llvm.org/show_bug.cgi?id=34341
> >
> > Regards,
> > Karan
> >
> > On Thu, Aug 24, 2017 at 11:17 PM, Jim Ingham  wrote:
> >
> > > On Aug 24, 2017, at 10:06 AM, karnajit wangkhem 
> wrote:
> > >
> > > Hi Jim,
> > >
> > > Thanks for the valuable reply. Please find my comments inline.
> > >
> > > Regards,
> > > Karan
> > >
> > > On Wed, Aug 23, 2017 at 12:32 AM, Jim Ingham 
> wrote:
> > >
> > > > On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Below is a sample example, where target.source-map seems to have a
> limitation. The limitation seems to be because
> > > > 1. lldb does not have an equivalent command like directory in gdb
> > >
> > > The gdb "dir" command seemed always to be more annoying than useful in
> real situations.  If your project had any complexity in the directory
> structure you ended up having to add dir commands for all the
> subdirectories, which got tedious quickly.  Since you pretty much always
> move your sources around rigidly, "source maps" are a more natural way to
> specify this.
> > >
> > > Note, we could add a recursive "dir" command, but you can't do the
> simpleminded recursive search or you'll mess up when the sources have same
> named files in different directories.  Because of this, again the source
> maps seem more suited.
> > >
> > >
> > > -- Really a good info to know. Thanks!
> > >
> > > > 2. target.source-map does not accept multiple mapping entries. I
> checked this only with freebsd.
> > > >
> > > > (lldb) settings show target.source-map
> > > > target.source-map (path-map) =
> > > > [0] "/home/karnajitw/lldb_test_execs/test_source_line1" ->
> "/u/test/test_source_line1"
> > >
> > > That is not correct:
> > >
> > > (lldb) settings set target.source-map /some/source/path /tmp
> /some/other/source/path /tmp
> > > (lldb) settings show target.source-map
> > > target.source-map (path-map) =
> > > [0] "/some/source/path" -> "/tmp"
> > > [1] "/some/other/source/path" -> "/tmp"
> > >
> > > or
> > >
> > > (lldb) set set target.source-map /some/source/path /tmp
> > > (lldb) set append target.source-map /some/other/source/path /tmp
> > > (lldb) set show target.source-map
> > > target.source-map (path-map) =
> > > [0] "/some/source/path" -> "/tmp"
> > > [1] "/some/other/source/path" -> "/tmp"
> > >
> > > - Thanks! This helped.
> > >
> > > >
> > > > 3. Haven't checked in the code yet, but if we see the mappings of
> scenario 1, they all point to a single real path 
> /home/karnajitw/lldb_test_execs/test_source_line1.
> But looks like the mapping logic only considers strings into account. But,
> at the same time, I am not claiming that they should be interpreted as path
> from a different machine during the mapping.
> > > >
> > >
> > > I'm not sure what you mean here.  lldb does what it can to unwind the
> source path, but it doesn't assume that those paths actually exist locally,
> so the most it can do is remove redundant "/"-s and "/./"-s and unwind
> ".."-s.  We do this before most source path comparisons (it's part of the
> FileSpec Equals method).  We've been tinkering with this over time so make
> sure you are using a recent version of lldb.  If there are places where we
> don't do this, then that's easily fixed.
> > >
> > >
> > > - Your answer is in line with what I wanted to know. My lldb should be
> quite recent. But I used it only for freebsd currently.
> > >
> > > % ./lldb --version
> > > lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk
> revision 305778)
> > >   clang revision 305546
> > >   llvm revision 305548
> > >
> > >
> > > > I want to check on this issue in-depth. But before that, want to
> confirm if this is real issue or there are other ways to deal these
> scenarios which I am not aware of?
> > > >
> > > > I am referring below link for the lldb commands.
> > > > https://lldb.llvm.org/lldb-gdb.html
> > > >
> > > > 1. First scenario: Different souce file path representation
> > > >
> > > > [/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g
> /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ain

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

Thank you, Chris. Looking forward to the patch.

On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman  wrote:
> I had a chance to look into this more, and I found a bug in the listen 
> behavior. I'm testing a solution to it now. Will post it if it resolves the 
> issue.
>
> -Chris
>
>> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>>  wrote:
>>
>> Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
>> work around?
>>
>>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman  wrote:
>>>
>>> Since lldb-server only supports running on a limited set of host operating 
>>> systems it is hard for me to diagnose the issue completely, but I suspect 
>>> the problem is caused by the fact that the new listening code can open more 
>>> than one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
>>>
>>> I'm unlikely to have time to investigate further until next week, but it 
>>> should be possible to craft a unit test that verifies that 
>>> GetLocalPortNumber() returns non-zero on a socket that is listening before 
>>> a connection is established. That might reproduce the issue in a more easy 
>>> to debug environment.
>>>
>>> -Chris
>>>
 On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev  
 wrote:

 Ted, Greg,

 I have built lldb tools @r300578 and the lldb-server is returning the
 proper port number to lldb client and the remote debugging is working.
 I have given the lldb-server log at the bottom of my reply.

 So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
 support IPv6 over TCP) is causing the issue.

> Ramana, can you stick in a log message to print port_cstr? I suspect it's 
> actually getting 0 back from lldb-server, which would tell us the error 
> is in the server code, not the client code.

 Ted, I did that and actually the pipe read is returning zero port
 number. So definitely the issue is on the server side.

   GDBRemoteCommunication::StartDebugserverProcess() port_cstr
 before socket pipe read
   GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
 socket pipe read


> Ted's comments are correct and I am guessing we will find the 
> "lldb-server gdb-server" is not doing the right thing and it isn't 
> returning the correctly bound port.
>
> When we are doing remote stuff we must use TCP so there should be 
> lldb-server should be opening a TCP socket, binding, listening and 
> accepting a connection from the remote LLDB.
>
> Greg

 Greg, thanks for the comments. Are you saying I should check what is
 happening on the TCP socket side? How do I do it other than walking
 through the code?


 root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
 --log-file Ramana/remote.log --log-channels "gdb-remote process"
 --server --listen *:1400
 Connection established.
 error: lost connection
 lldb-server exiting...
 ^C
 root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
 lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
 revision 300578)
 clang revision 300578
 llvm revision 300578
 root@arria5:~# cat Ramana/remote.log
 GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, 
 port=0)
 GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
 stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
 launch info for gdb-remote stub:
 Executable: lldb-server
 Triple: *-*-*
 Arguments:
 argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
 argv[1]="gdbserver"
 argv[2]="tcp://10.10.12.3:0"
 argv[3]="--native-regs"
 argv[4]="--pipe"
 argv[5]="7"
 argv[6]=NULL

 Environment:
 env[0]="XDG_SESSION_ID=c7"
 env[1]="TERM=xterm-256color"
 env[2]="SHELL=/bin/sh"
 env[3]="SSH_CLIENT=172.16.16.51 40072 22"
 env[4]="SSH_TTY=/dev/pts/0"
 env[5]="USER=root"
 env[6]="MAIL=/var/mail/root"
 env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
 env[8]="PWD=/home/root"
 env[9]="EDITOR=vi"
 env[10]="PS1=\u@\h:\w\$ "
 env[11]="SHLVL=1"
 env[12]="HOME=/home/root"
 env[13]="LOGNAME=root"
 env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
 env[15]="XDG_RUNTIME_DIR=/run/user/0"
 env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
 env[17]=NULL

 GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 
 48039 port


 Regards,
 Ramana

 On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton  wrote:
>
>> On Aug 24, 2017, at 8:33 AM, Ted Woodward  
>> wrote:
>>
>> The lldb-server launch line looks ok; it should take the port 0 arg and 
>> get a port from the OS.
>> lldb is getting the port back from lldb-server in 4.0.1, as seen here:
>>
>>> GDBRemoteCommu

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Greg Clayton via lldb-dev]

Very nice! Look forward to seeing what you find.

> On Aug 28, 2017, at 12:58 PM, Chris Bieneman  wrote:
> 
> I had a chance to look into this more, and I found a bug in the listen 
> behavior. I'm testing a solution to it now. Will post it if it resolves the 
> issue.
> 
> -Chris
> 
>> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>>  wrote:
>> 
>> Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
>> work around?
>> 
>>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman  wrote:
>>> 
>>> Since lldb-server only supports running on a limited set of host operating 
>>> systems it is hard for me to diagnose the issue completely, but I suspect 
>>> the problem is caused by the fact that the new listening code can open more 
>>> than one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
>>> 
>>> I'm unlikely to have time to investigate further until next week, but it 
>>> should be possible to craft a unit test that verifies that 
>>> GetLocalPortNumber() returns non-zero on a socket that is listening before 
>>> a connection is established. That might reproduce the issue in a more easy 
>>> to debug environment.
>>> 
>>> -Chris
>>> 
 On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev  
 wrote:
 
 Ted, Greg,
 
 I have built lldb tools @r300578 and the lldb-server is returning the
 proper port number to lldb client and the remote debugging is working.
 I have given the lldb-server log at the bottom of my reply.
 
 So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
 support IPv6 over TCP) is causing the issue.
 
> Ramana, can you stick in a log message to print port_cstr? I suspect it's 
> actually getting 0 back from lldb-server, which would tell us the error 
> is in the server code, not the client code.
 
 Ted, I did that and actually the pipe read is returning zero port
 number. So definitely the issue is on the server side.
 
  GDBRemoteCommunication::StartDebugserverProcess() port_cstr
 before socket pipe read
  GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
 socket pipe read
 
 
> Ted's comments are correct and I am guessing we will find the 
> "lldb-server gdb-server" is not doing the right thing and it isn't 
> returning the correctly bound port.
> 
> When we are doing remote stuff we must use TCP so there should be 
> lldb-server should be opening a TCP socket, binding, listening and 
> accepting a connection from the remote LLDB.
> 
> Greg
 
 Greg, thanks for the comments. Are you saying I should check what is
 happening on the TCP socket side? How do I do it other than walking
 through the code?
 
 
 root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
 --log-file Ramana/remote.log --log-channels "gdb-remote process"
 --server --listen *:1400
 Connection established.
 error: lost connection
 lldb-server exiting...
 ^C
 root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
 lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
 revision 300578)
 clang revision 300578
 llvm revision 300578
 root@arria5:~# cat Ramana/remote.log
 GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, 
 port=0)
 GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
 stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
 launch info for gdb-remote stub:
 Executable: lldb-server
 Triple: *-*-*
 Arguments:
 argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
 argv[1]="gdbserver"
 argv[2]="tcp://10.10.12.3:0"
 argv[3]="--native-regs"
 argv[4]="--pipe"
 argv[5]="7"
 argv[6]=NULL
 
 Environment:
 env[0]="XDG_SESSION_ID=c7"
 env[1]="TERM=xterm-256color"
 env[2]="SHELL=/bin/sh"
 env[3]="SSH_CLIENT=172.16.16.51 40072 22"
 env[4]="SSH_TTY=/dev/pts/0"
 env[5]="USER=root"
 env[6]="MAIL=/var/mail/root"
 env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
 env[8]="PWD=/home/root"
 env[9]="EDITOR=vi"
 env[10]="PS1=\u@\h:\w\$ "
 env[11]="SHLVL=1"
 env[12]="HOME=/home/root"
 env[13]="LOGNAME=root"
 env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
 env[15]="XDG_RUNTIME_DIR=/run/user/0"
 env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
 env[17]=NULL
 
 GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 
 48039 port
 
 
 Regards,
 Ramana
 
 On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton  wrote:
> 
>> On Aug 24, 2017, at 8:33 AM, Ted Woodward  
>> wrote:
>> 
>> The lldb-server launch line looks ok; it should take the port 0 arg and 
>> get a port from the OS.
>> lldb is getting the port back from lldb-server in 4.0.1, as seen here:

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Chris Bieneman via lldb-dev]

I had a chance to look into this more, and I found a bug in the listen 
behavior. I'm testing a solution to it now. Will post it if it resolves the 
issue.

-Chris

> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
> work around?
> 
>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman  wrote:
>> 
>> Since lldb-server only supports running on a limited set of host operating 
>> systems it is hard for me to diagnose the issue completely, but I suspect 
>> the problem is caused by the fact that the new listening code can open more 
>> than one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
>> 
>> I'm unlikely to have time to investigate further until next week, but it 
>> should be possible to craft a unit test that verifies that 
>> GetLocalPortNumber() returns non-zero on a socket that is listening before a 
>> connection is established. That might reproduce the issue in a more easy to 
>> debug environment.
>> 
>> -Chris
>> 
>>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev  
>>> wrote:
>>> 
>>> Ted, Greg,
>>> 
>>> I have built lldb tools @r300578 and the lldb-server is returning the
>>> proper port number to lldb client and the remote debugging is working.
>>> I have given the lldb-server log at the bottom of my reply.
>>> 
>>> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
>>> support IPv6 over TCP) is causing the issue.
>>> 
 Ramana, can you stick in a log message to print port_cstr? I suspect it's 
 actually getting 0 back from lldb-server, which would tell us the error is 
 in the server code, not the client code.
>>> 
>>> Ted, I did that and actually the pipe read is returning zero port
>>> number. So definitely the issue is on the server side.
>>> 
>>>   GDBRemoteCommunication::StartDebugserverProcess() port_cstr
>>> before socket pipe read
>>>   GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
>>> socket pipe read
>>> 
>>> 
 Ted's comments are correct and I am guessing we will find the "lldb-server 
 gdb-server" is not doing the right thing and it isn't returning the 
 correctly bound port.
 
 When we are doing remote stuff we must use TCP so there should be 
 lldb-server should be opening a TCP socket, binding, listening and 
 accepting a connection from the remote LLDB.
 
 Greg
>>> 
>>> Greg, thanks for the comments. Are you saying I should check what is
>>> happening on the TCP socket side? How do I do it other than walking
>>> through the code?
>>> 
>>> 
>>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
>>> --log-file Ramana/remote.log --log-channels "gdb-remote process"
>>> --server --listen *:1400
>>> Connection established.
>>> error: lost connection
>>> lldb-server exiting...
>>> ^C
>>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
>>> lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
>>> revision 300578)
>>> clang revision 300578
>>> llvm revision 300578
>>> root@arria5:~# cat Ramana/remote.log
>>> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, 
>>> port=0)
>>> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
>>> stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
>>> launch info for gdb-remote stub:
>>> Executable: lldb-server
>>> Triple: *-*-*
>>> Arguments:
>>> argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
>>> argv[1]="gdbserver"
>>> argv[2]="tcp://10.10.12.3:0"
>>> argv[3]="--native-regs"
>>> argv[4]="--pipe"
>>> argv[5]="7"
>>> argv[6]=NULL
>>> 
>>> Environment:
>>> env[0]="XDG_SESSION_ID=c7"
>>> env[1]="TERM=xterm-256color"
>>> env[2]="SHELL=/bin/sh"
>>> env[3]="SSH_CLIENT=172.16.16.51 40072 22"
>>> env[4]="SSH_TTY=/dev/pts/0"
>>> env[5]="USER=root"
>>> env[6]="MAIL=/var/mail/root"
>>> env[7]="PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
>>> env[8]="PWD=/home/root"
>>> env[9]="EDITOR=vi"
>>> env[10]="PS1=\u@\h:\w\$ "
>>> env[11]="SHLVL=1"
>>> env[12]="HOME=/home/root"
>>> env[13]="LOGNAME=root"
>>> env[14]="SSH_CONNECTION=172.16.16.51 40072 10.10.2.4 22"
>>> env[15]="XDG_RUNTIME_DIR=/run/user/0"
>>> env[16]="_=/mnt/var/patch_bins/binaries/bin/lldb-server"
>>> env[17]=NULL
>>> 
>>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 48039 
>>> port
>>> 
>>> 
>>> Regards,
>>> Ramana
>>> 
>>> On Thu, Aug 24, 2017 at 10:10 PM, Greg Clayton  wrote:
 
> On Aug 24, 2017, at 8:33 AM, Ted Woodward  
> wrote:
> 
> The lldb-server launch line looks ok; it should take the port 0 arg and 
> get a port from the OS.
> lldb is getting the port back from lldb-server in 4.0.1, as seen here:
> 
>> GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 
>> 56543 port
> 
> But for 5.0.0 we see it fail the debugserver launch, and get:
> 
>> GDBRemoteCommunication::StartDebugserverProcess() d

[lldb-dev] [5.0.0 Release] Release Candidate 3 source and binaries available

[Hans Wennborg via lldb-dev]

Hello everyone,

Source, binaries and docs for LLVM-5.0.0-rc3 are now available at
http://prereleases.llvm.org/5.0.0/#rc3

(I'll add more binaries as they become available.)

We're a little behind schedule, but hopefully will be ready for the
final release soon.

Please report any problems you find, ideally as bugs marked as
blockers of http://llvm.org/pr33849.

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

Re: [lldb-dev] [llvm-dev] [Release-testers] [5.0.0 Release] Release Candidate 3 tagged

[Hans Wennborg via lldb-dev]

I see there's a patch in progress to fix this: https://reviews.llvm.org/D36049

Since the issue was raised so late in the process, I don't think it
will get fixed for 5.0.0 however. Maybe for 5.0.1.

Thanks,
Hans

On Mon, Aug 28, 2017 at 12:40 AM, Dr.-Ing. Christoph Cullmann
 wrote:
> Hi,
>
> one issue I have with rc3 is that tools using it don't compile with C++17 as 
> public LLVM
> headers seem to use a removed feature, std::pointer_to_unary_function.
>
> [ 12%] Building CXX object tsl/CMakeFiles/tsl.dir/src/generated/combined.cpp.o
> In file included from 
> /local/cullmann/build/eco.default/eco/tsl/src/generated/combined.cpp:3:
> In file included from 
> /local/cullmann/build/eco.default/eco/tsl/src/graph.cpp:29:
> In file included from 
> /local/cullmann/build/eco.default/eco/tsl/include/tsl/graph.h:32:
> In file included from 
> /local/cullmann/build/eco.default/eco/tsl/include/tsl/llvm.h:52:
> In file included from 
> /local/cullmann/build/eco.default/usr/include/llvm/Analysis/BasicAliasAnalysis.h:18:
> In file included from 
> /local/cullmann/build/eco.default/usr/include/llvm/Analysis/AliasAnalysis.h:41:
> In file included from 
> /local/cullmann/build/eco.default/usr/include/llvm/Analysis/MemoryLocation.h:20:
> In file included from 
> /local/cullmann/build/eco.default/usr/include/llvm/IR/CallSite.h:37:
> /local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4198:26: 
> error: no template named 'pointer_to_unary_function' in namespace 'std'
>   using DerefFnTy = std::pointer_to_unary_function;
> ~^
> /local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4199:57: 
> error: use of undeclared identifier 'DerefFnTy'
>   using handler_iterator = mapped_iterator;
> ^
> /local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4200:40: 
> error: use of undeclared identifier 'handler_iterator'
>   using handler_range = iterator_range;
>^
> /local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4202:12: 
> error: no template named 'pointer_to_unary_function' in namespace 'std'
>   std::pointer_to_unary_function;
>   ~^
> /local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4204:42: 
> error: use of undeclared identifier 'ConstDerefFnTy'
>   mapped_iterator;
>  ^
> /local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4205:46: 
> error: unknown type name 'const_handler_iterator'; did you mean 
> 'const_user_iterator'?
>   using const_handler_range = iterator_range;
>  ^~
>  const_user_iterator
> /local/cullmann/build/eco.default/usr/include/llvm/IR/Value.h:365:9: note: 
> 'const_user_iterator' declared here
>   using const_user_iterator = user_iterator_impl;
>
> Greetings
> Christoph
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [5.0.0 Release] Release Candidate 3 tagged

[Dimitry Andric via lldb-dev]

On 26 Aug 2017, at 00:52, Hans Wennborg via Release-testers 
 wrote:
> 
> 5.0.0-rc3 was just tagged.
> 
> This is a release candidate in the real sense: if nothing bad comes up
> in testing, this is what the release is going to look like.

Built and tested, no changes with respect to the previous rc.  I've uploaded:

SHA256 (clang+llvm-5.0.0-rc3-amd64-unknown-freebsd10.tar.xz) = 
510d8689239a1b83a154e8ee0230765d0f9054ca534c3a9ed4a2d4e31d8f9704
SHA256 (clang+llvm-5.0.0-rc3-i386-unknown-freebsd10.tar.xz) = 
65b21c280575dcf16449c4c051b14f9950ff5f5d0a43b59852a0e1c65a1f145c

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [PATCH] D32366: Set "success" status correctly

[John Lindal via lldb-dev]

I built lldb with XCode 8.3.3 on OX 10.12.6, using the latest from 
https://github.com/llvm-mirror/lldb.git, but I'm when I run the tests, I get 
nothing but errors.  The errors are mostly related to being unable to find 
standard C++ headers like iostream, exception, cstdlib, chrono, etc.

I'm using the lldb.xcworkspace provided in the project.  Is there something I 
need to configure?

Thanks,
John

> On Apr 24, 2017, at 3:43 AM, Pavel Labath via Phabricator 
>  wrote:
> 
> labath added a comment.
> 
> Thanks for the patch. Could you please also add an appropriate test for it? 
> Doing something similar to what 
> `packages/Python/lldbsuite/test/functionalities/frame_var/TestFrameVar.py` 
> does should be the easiest way to test this.
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D32366
> 
> 
> 

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

Re: [lldb-dev] Display of reference parameters

[Jim Ingham via lldb-dev]

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

A:

(int)   y = 33 
(int)   z = 33 
(int &) x = 0x7fff5fbff5e8 (*x = 33)
(int)   a = 33 
(int)   b = 33 

B:

(int)   y = 33 
(int)   z = 33 
(int &) x = 33 (&x = 0x7fff5fbff5e8)
(int)   a = 33 
(int)   b = 33 

C:

(int)   y = 33 
(int)   z = 33 
(int &) x @ 0x7fff5fbff5e8 = 33
(int)   a = 33 
(int)   x = 33 

I think of these B is the easiest to scan for values.  It's easiest not to be 
distracted by the appended value in that case.  A simple (one line) struct 
would be similar.  Not quite as sure what we should do for structures.  I'm not 
sure how to do A nicely.  I think B would be okay if you did it like:

(int)   y = 33 
(int)   z = 33 
(Array) my_array = {
  size = 10
  head = 0x7fff5fbff770
} (&my_array = 0x7fff5fbff5e8)
(int)   a = 33 
(int)   x = 33 

But I think C looks nicer in this case:

(int)   y = 33 
(int)   z = 33 
(Array) my_array @ 0x7fff5fbff5e8 = {
  size = 10
  head = 0x7fff5fbff770
}
(int)   a = 33 
(int)   x = 33 

Jim


  

 
> On Aug 28, 2017, at 9:42 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> 
>> On Aug 27, 2017, at 11:59 AM, Johan Engelen via lldb-dev 
>>  wrote:
>> 
>> Hi all,
>> Consider this code:
>> ```
>> void foo(int& x)
>> {
>>++x;
>>// Breakpoint
>> }
>> ```
>> 
>> Reference parameter `x` is shown like this:
>> ```
>> (lldb) frame variable
>> (int &) x = 0x7fff5fbff5e8 (&x = 33)
>> ```
>> 
>> Should this perhaps be improved? (I find the "&x = 33" a little confusing)
>> Some ideas:
>> A.(int &) x = 0x7fff5fbff5e8 (*x = 33)
>> B.(int &) x = 33 (&x = 0x7fff5fbff5e8)
> 
> The main issue is what do you want to see when things go wrong? It is nice to 
> see what the reference value is. How about:
> 
> (int &) x @ 0x7fff5fbff5e8 = 33
> 
> The main issue is we want people to know what is wrong when things go bad:
> 
> 
> void foo(int& x)
> {
>++x;
> }
> int main()
> {
>   int *int_ptr = nullptr;
>   foo(*int_ptr);
>   return 0;
> }
> 
> 
> (lldb) 
> Process 60095 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = step in
>frame #0: 0x00010f78 a.out`foo(x=0x) at main.cpp:3
>   1   void foo(int& x)
>   2   {
> -> 3  ++x;
>   4   }
>   5   int main()
>   6   {
>   7   int *int_ptr = nullptr;
> (lldb) fr var
> (int &) x = 0x
> 
> 
> This shows that the reference is clearly bad and is why we currently show the 
> reference value. The current method of display tries to display the truth. If 
> we cover up the reference then when we display things and things work 
> correctly, then we would end up showing it one way, and then how would be 
> display things if they are not correct.
> 
> If we add case C where we show "@  = ":
> 
> Current when reference is valid:
> 
> (lldb) frame variable
> (int &) x = 0x7fff5fbff5e8 (&x = 33)
> A.(int &) x = 0x7fff5fbff5e8 (*x = 33)
> B.(int &) x = 33 (&x = 0x7fff5fbff5e8)
> C.(int &) x @ 0x7fff5fbff5e8 = 33
> 
> 
> When reference is invalid:
> 
> (lldb) frame variable
> (int &) x = 0x
> A.(int &) x = 0x (*x = )
> B.(int &) x =  (&x = 0x)
> C.(int &) x @ 0x = 
> 
> It would be a good idea to see what other debuggers do and make sure we use 
> what makes the most sense to people. Also we need to think about what gets 
> shown for references to simple structs/unions/classes (like "struct Point { 
> int x,y; };" and also structs/unions/classes that are have many children as 
> all of those cases differ.
> 
> I wouldn't be against switching to "()  @  = " 
> way of displaying things.
> 
> Anyone else want to chime in?
> 
> Greg Clayton
> 
> ___
> 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

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

[Jim Ingham via lldb-dev]

That will be great!  Last time we were more aggressive about normalizing paths 
we caused a decent performance regression by normalizing all the paths every 
time we did a file-name compare for setting breakpoints.  If you look at 
FileSpec::Equal we added some "is it worth doing this work" preparatory work.  
I don't know where you'll find the additional places this needed to be done, 
but it's worth keeping an eye out for not putting GetNormalizedPath on a hot 
path.

Jim



> On Aug 28, 2017, at 1:19 AM, karnajit wangkhem  wrote:
> 
> Thanks Jim for the help. I would definitely like to work on this PR soon.
> 
> Filed the PR here
> https://bugs.llvm.org/show_bug.cgi?id=34341
> 
> Regards,
> Karan
> 
> On Thu, Aug 24, 2017 at 11:17 PM, Jim Ingham  wrote:
> 
> > On Aug 24, 2017, at 10:06 AM, karnajit wangkhem  wrote:
> >
> > Hi Jim,
> >
> > Thanks for the valuable reply. Please find my comments inline.
> >
> > Regards,
> > Karan
> >
> > On Wed, Aug 23, 2017 at 12:32 AM, Jim Ingham  wrote:
> >
> > > On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev 
> > >  wrote:
> > >
> > > Hi All,
> > >
> > > Below is a sample example, where target.source-map seems to have a 
> > > limitation. The limitation seems to be because
> > > 1. lldb does not have an equivalent command like directory in gdb
> >
> > The gdb "dir" command seemed always to be more annoying than useful in real 
> > situations.  If your project had any complexity in the directory structure 
> > you ended up having to add dir commands for all the subdirectories, which 
> > got tedious quickly.  Since you pretty much always move your sources around 
> > rigidly, "source maps" are a more natural way to specify this.
> >
> > Note, we could add a recursive "dir" command, but you can't do the 
> > simpleminded recursive search or you'll mess up when the sources have same 
> > named files in different directories.  Because of this, again the source 
> > maps seem more suited.
> >
> >
> > -- Really a good info to know. Thanks!
> >
> > > 2. target.source-map does not accept multiple mapping entries. I checked 
> > > this only with freebsd.
> > >
> > > (lldb) settings show target.source-map
> > > target.source-map (path-map) =
> > > [0] "/home/karnajitw/lldb_test_execs/test_source_line1" -> 
> > > "/u/test/test_source_line1"
> >
> > That is not correct:
> >
> > (lldb) settings set target.source-map /some/source/path /tmp 
> > /some/other/source/path /tmp
> > (lldb) settings show target.source-map
> > target.source-map (path-map) =
> > [0] "/some/source/path" -> "/tmp"
> > [1] "/some/other/source/path" -> "/tmp"
> >
> > or
> >
> > (lldb) set set target.source-map /some/source/path /tmp
> > (lldb) set append target.source-map /some/other/source/path /tmp
> > (lldb) set show target.source-map
> > target.source-map (path-map) =
> > [0] "/some/source/path" -> "/tmp"
> > [1] "/some/other/source/path" -> "/tmp"
> >
> > - Thanks! This helped.
> >
> > >
> > > 3. Haven't checked in the code yet, but if we see the mappings of 
> > > scenario 1, they all point to a single real path 
> > > /home/karnajitw/lldb_test_execs/test_source_line1. But looks like the 
> > > mapping logic only considers strings into account. But, at the same time, 
> > > I am not claiming that they should be interpreted as path from a 
> > > different machine during the mapping.
> > >
> >
> > I'm not sure what you mean here.  lldb does what it can to unwind the 
> > source path, but it doesn't assume that those paths actually exist locally, 
> > so the most it can do is remove redundant "/"-s and "/./"-s and unwind 
> > ".."-s.  We do this before most source path comparisons (it's part of the 
> > FileSpec Equals method).  We've been tinkering with this over time so make 
> > sure you are using a recent version of lldb.  If there are places where we 
> > don't do this, then that's easily fixed.
> >
> >
> > - Your answer is in line with what I wanted to know. My lldb should be 
> > quite recent. But I used it only for freebsd currently.
> >
> > % ./lldb --version
> > lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision 
> > 305778)
> >   clang revision 305546
> >   llvm revision 305548
> >
> >
> > > I want to check on this issue in-depth. But before that, want to confirm 
> > > if this is real issue or there are other ways to deal these scenarios 
> > > which I am not aware of?
> > >
> > > I am referring below link for the lldb commands.
> > > https://lldb.llvm.org/lldb-gdb.html
> > >
> > > 1. First scenario: Different souce file path representation
> > >
> > > [/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g 
> > > /home/karnajitw/lldb_test_execs///test_source_line1/main.c 
> > > /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
> > >  /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> > >
> > > Machine 1: /home/karnajitw/lldb_test_execs/test_source_line1 -> Machine 
> > > 2: /u/test/test_source_line1
> > >
> > >

Re: [lldb-dev] [5.0.0 Release] Release Candidate 3 tagged

[Hans Wennborg via lldb-dev]

On Fri, Aug 25, 2017 at 3:52 PM, Hans Wennborg  wrote:
> Dear testers,
>
> 5.0.0-rc3 was just tagged.
>
> This is a release candidate in the real sense: if nothing bad comes up
> in testing, this is what the release is going to look like.
>
> Please build, test and upload binaries to the sftp (use the
> /data/testers-uploads/ directory) and let me know what issues remain.

Windows is ready:
$ sha1sum *5.0.0-rc3*
1d4f3cf9e1463803cd5bbb95a029b5544c0989be  LLVM-5.0.0-rc3-win32.exe
72f1c558d01e8fde1da2c50b5cbb90e1bbc6375a  LLVM-5.0.0-rc3-win64.exe
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-server link failure with shared library configuration

[Greg Clayton via lldb-dev]

If we are pulling in the expression parser, that would explain our issues. If 
this currently happens in lldb-server we need to add LLVMRuntimeDyld to the 
link libraries. I know some people at Google have looked into getting 
lldb-server to link against as little as possible, and maybe this is just how 
things are for the time being. We should verify that. It would be nice if 
lldb-server didn't link against the expression parser if possible.

Greg

> On Aug 28, 2017, at 9:56 AM, Peeter Joot  wrote:
> 
> Hi Greg,
> 
> IRExecutionUnit.cpp looks like the origin of at least some of the undefined 
> symbols:
> 
> .../llvm/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:61: undefined 
> reference to `vtable for llvm::RTDyldMemoryManager'   
>
> 
> .../llvm/include/llvm/ExecutionEngine/JITSymbol.h:223: undefined reference to 
> `vtable for llvm::JITSymbolResolver'  
>
> 
> .../llvm/include/llvm/ExecutionEngine/RuntimeDyld.h:96: undefined reference 
> to `vtable for llvm::RuntimeDyld::MemoryManager'  
>  
> 
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x90): undefined 
> reference to `llvm::RTDyldMemoryManager::deregisterEHFrames()'
> 
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0xa8): undefined 
> reference to `llvm::RuntimeDyld::MemoryManager::anchor()'
> 
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x118): 
> undefined reference to `llvm::JITSymbolResolver::anchor()'
> 
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN4llvm18MCJITMemoryManagerE[_ZTVN4llvm18MCJITMemoryManagerE]+0x60):
>  undefined reference to `llvm::RuntimeDyld:
> 
> :MemoryManager::anchor()'
> 
> 
> there are a couple of undefined vtable references in headers (also above), 
> but it's not clear to me if these also neccessarily come from 
> IRExectionUnix.cpp.
> 
> --
> Peeter
> 
> 

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

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

[Greg Clayton via lldb-dev]

> On Aug 25, 2017, at 4:15 PM, Jim Ingham  wrote:
> 
> If that’s the expectation, you have to obey it...   Xcode is pretty careful 
> to only act on the elements that were visible in a view, which made the 
> locals view much less heavy-weight.  But that took some work on their end.
> 
> More to the point, this doesn’t seem to be code that should be in the MI 
> layer.  Shouldn’t this be a method on the SBValue?  If there was something 
> tricky that you could get wrong, it would be better to centralize it.
> 
> As Greg says, this shouldn’t be the default “has changed” behavior, but still 
> it seems like it should be an SBValue method.

We could possibly add:

  bool SBValue::GetValueDidChange(bool check_children);

as a new API. I still say this is a potentially very expensive operation that 
most if not all debuggers should avoid, but if they want to debug really really 
slowly under some circumstances, I don't really mind. There should be a strong 
warning on this method that things can get expensive.


Your fix of not recursing through pointers needs to also do the same for any 
references (l value, r value, and C++ 11 &&). So your fix is correct if you 
wish to keep the lldb-mi paradigm of checking all children, just add references 
to the list of things to not check. 

Just for fun, make an std::vector with a million entries, change the last 
one, and single step over it and wait to see how long this code takes just to 
make sure you really want to check that many items.

Greg


> 
> Jim
> 
>> On Aug 25, 2017, at 3:49 PM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> The spec says that's what it should do. From
>> https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Variable-Objects.html :
>> 
>> "Reevaluate the expressions corresponding to the variable object name and
>> all its direct and indirect children, and return the list of variable
>> objects whose values have changed;"
>> 
>> Also, our Eclipse guy gets grumpy when it doesn't :-)
>> 
>> Ted
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>> 
>>> -Original Message-
>>> From: Greg Clayton [mailto:clayb...@gmail.com]
>>> Sent: Friday, August 25, 2017 5:00 PM
>>> To: Ted Woodward 
>>> Cc: lldb-dev@lists.llvm.org
>>> Subject: Re: [lldb-dev] hang bug in lldb-mi -var-update
>>> 
>>> lldb-mi should never be checking the children. This is never a good idea
>> due to
>>> performance. What happens when you have an array with a million entries?
>>> Long delay. Aggregate types should never say they changed. Only SBValue
>>> objects that have values should claim to change.
>>> 
>>> Greg
>>> 
>>> 
 On Aug 25, 2017, at 10:42 AM, Ted Woodward via lldb-dev >> d...@lists.llvm.org> wrote:
 
 I found a hang in lldb-mi's -var-update. It checks to see if a var
 changed, then it checks each of the children recursively. If a child
 is a pointer back to a parent, as in this case:
 
 struct complex_type
 {
  int i;
  struct { long l; } inner;
  struct complex_type *complex_ptr;
 };
 
 void
 var_update_test(void)
 {
  struct complex_type complx_array[2];
 
  complx_array[0].i = 4;
  complx_array[0].inner.l = 4;
  complx_array[0].complex_ptr = &complx_array[1];
  complx_array[1].i = 5;
  complx_array[1].inner.l = 5;
  complx_array[1].complex_ptr = &complx_array[0];
 
 
 
 the code in CMICmdCmdVarUpdate::ExamineSBValueForChange will get into
 an infinite loop.
 
 const MIuint nChildren = vrwValue.GetNumChildren();  for (MIuint i =
 0; i < nChildren; ++i) {
  lldb::SBValue member = vrwValue.GetChildAtIndex(i);
  if (!member.IsValid())
continue;
 
  if (member.GetValueDidChange()) {
vrwbChanged = true;
return MIstatus::success;
  } else if (ExamineSBValueForChange(member, vrwbChanged) &&
>>> vrwbChanged)
// Handle composite types (i.e. struct or arrays)
return MIstatus::success;
 }
 
 I've got a patch that disables checking a pointer's children. I'll put
 it up on phabricator today.
 
 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
>> 
>> 
>> ___
>> 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

Re: [lldb-dev] lldb-server link failure with shared library configuration

[Peeter Joot via lldb-dev]

Hi Greg,

IRExecutionUnit.cpp looks like the origin of at least some of the undefined 
symbols:

.../llvm/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:61: undefined 
reference to `vtable for llvm::RTDyldMemoryManager'

.../llvm/include/llvm/ExecutionEngine/JITSymbol.h:223: undefined reference to 
`vtable for llvm::JITSymbolResolver'

.../llvm/include/llvm/ExecutionEngine/RuntimeDyld.h:96: undefined reference to 
`vtable for llvm::RuntimeDyld::MemoryManager'

lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x90): undefined 
reference to `llvm::RTDyldMemoryManager::deregisterEHFrames()'

lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0xa8): undefined 
reference to `llvm::RuntimeDyld::MemoryManager::anchor()'

lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x118): undefined 
reference to `llvm::JITSymbolResolver::anchor()'

lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN4llvm18MCJITMemoryManagerE[_ZTVN4llvm18MCJITMemoryManagerE]+0x60):
 undefined reference to `llvm::RuntimeDyld:

:MemoryManager::anchor()'

there are a couple of undefined vtable references in headers (also above), but 
it's not clear to me if these also neccessarily come from IRExectionUnix.cpp.

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

Re: [lldb-dev] lldb-server link failure with shared library configuration

[Greg Clayton via lldb-dev]

Looks like a dependency issue in LLVM? Who was using this function? Why do we 
need LLVMRuntimeDyld in lldb-server? We shouldn't have to use it. I know we 
currently have some issues in lldb-server where it is pulling in too much 
stuff, so we definitely don't want to include this just to fix a link issue. 
lldb-server shouldn't require the LLDB expression parser AFAIK.

Does the link line mention who was wanting 
llvm::RuntimeDyld::MemoryManager::anchor()?


> On Aug 28, 2017, at 9:42 AM, Peeter Joot via lldb-dev 
>  wrote:
> 
> I've built lldb in tree on Linux (RHEL 7.3) with a shared library 
> configuration:
> CC=/usr/bin/clang CXX=/usr/bin/clang++ \
> 
> cmake -G Ninja ../llvm \
> -DBUILD_SHARED_LIBS=true \
> 
> ...
> 
> The lldb-server binary does not link for me, as I get unresolved symbols 
> including:
> 
> llvm::RuntimeDyld::MemoryManager::anchor()
> 
> 
> I've worked around this by changing the link rules for lldb-server like so:
> diff --git a/tools/lldb-server/CMakeLists.txt 
> b/tools/lldb-server/CMakeLists.txt
> 
> index f8c57cb..35311a8 100644
> 
> --- a/tools/lldb-server/CMakeLists.txt
> 
> +++ b/tools/lldb-server/CMakeLists.txt
> 
> @@ -82,6 +85,7 @@ add_lldb_tool(lldb-server INCLUDE_IN_FRAMEWORK
> 
>lldbHost
> 
>lldbInitialization
> 
>lldbInterpreter
> 
> +  LLVMRuntimeDyld
> 
>${LLDB_PLUGINS}
> 
>${LLDB_SYSTEM_LIBS}
> 
> 
> Is this a known issue, and what would the proper fix for this look like?
> 
> --
> Peeter
> 
> 
> ___
> 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] lldb-server link failure with shared library configuration

[Peeter Joot via lldb-dev]

I've built lldb in tree on Linux (RHEL 7.3) with a shared library configuration:

CC=/usr/bin/clang CXX=/usr/bin/clang++ \

cmake -G Ninja ../llvm \

-DBUILD_SHARED_LIBS=true \

...

The lldb-server binary does not link for me, as I get unresolved symbols 
including:

llvm::RuntimeDyld::MemoryManager::anchor()

I've worked around this by changing the link rules for lldb-server like so:

diff --git a/tools/lldb-server/CMakeLists.txt b/tools/lldb-server/CMakeLists.txt

index f8c57cb..35311a8 100644

--- a/tools/lldb-server/CMakeLists.txt

+++ b/tools/lldb-server/CMakeLists.txt

@@ -82,6 +85,7 @@ add_lldb_tool(lldb-server INCLUDE_IN_FRAMEWORK

   lldbHost

   lldbInitialization

   lldbInterpreter

+  LLVMRuntimeDyld

   ${LLDB_PLUGINS}

   ${LLDB_SYSTEM_LIBS}

Is this a known issue, and what would the proper fix for this look like?

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

Re: [lldb-dev] Display of reference parameters

[Greg Clayton via lldb-dev]

> On Aug 27, 2017, at 11:59 AM, Johan Engelen via lldb-dev 
>  wrote:
> 
> Hi all,
>  Consider this code:
> ```
> void foo(int& x)
> {
> ++x;
> // Breakpoint
> }
> ```
> 
> Reference parameter `x` is shown like this:
> ```
> (lldb) frame variable
> (int &) x = 0x7fff5fbff5e8 (&x = 33)
> ```
> 
> Should this perhaps be improved? (I find the "&x = 33" a little confusing)
> Some ideas:
> A.(int &) x = 0x7fff5fbff5e8 (*x = 33)
> B.(int &) x = 33 (&x = 0x7fff5fbff5e8)

The main issue is what do you want to see when things go wrong? It is nice to 
see what the reference value is. How about:

(int &) x @ 0x7fff5fbff5e8 = 33

The main issue is we want people to know what is wrong when things go bad:


void foo(int& x)
{
++x;
}
int main()
{
int *int_ptr = nullptr;
foo(*int_ptr);
return 0;
}


(lldb) 
Process 60095 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x00010f78 a.out`foo(x=0x) at main.cpp:3
   1void foo(int& x)
   2{
-> 3++x;
   4}
   5int main()
   6{
   7int *int_ptr = nullptr;
(lldb) fr var
(int &) x = 0x


This shows that the reference is clearly bad and is why we currently show the 
reference value. The current method of display tries to display the truth. If 
we cover up the reference then when we display things and things work 
correctly, then we would end up showing it one way, and then how would be 
display things if they are not correct.

If we add case C where we show "@  = ":

Current when reference is valid:

(lldb) frame variable
(int &) x = 0x7fff5fbff5e8 (&x = 33)
A.(int &) x = 0x7fff5fbff5e8 (*x = 33)
B.(int &) x = 33 (&x = 0x7fff5fbff5e8)
C.(int &) x @ 0x7fff5fbff5e8 = 33


When reference is invalid:

(lldb) frame variable
(int &) x = 0x
A.(int &) x = 0x (*x = )
B.(int &) x =  (&x = 0x)
C.(int &) x @ 0x = 

It would be a good idea to see what other debuggers do and make sure we use 
what makes the most sense to people. Also we need to think about what gets 
shown for references to simple structs/unions/classes (like "struct Point { int 
x,y; };" and also structs/unions/classes that are have many children as all of 
those cases differ.

I wouldn't be against switching to "()  @  = " way 
of displaying things.

Anyone else want to chime in?

Greg Clayton

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

Re: [lldb-dev] [Release-testers] [llvm-dev] [5.0.0 Release] Release Candidate 3 tagged

[Diana Picus via lldb-dev]

Hi,

Uploaded ARM & AArch64:
ee9e89f1d5f8a5fb84cef6c82ded694c5c427e16
clang+llvm-5.0.0-rc3-aarch64-linux-gnu.tar.xz
a8b38e91288b07b2899c397373c018c6c5f6f207
clang+llvm-5.0.0-rc3-armv7a-linux-gnueabihf.tar.xz

The libunwind tests are still failing. I have reopened the bug:
https://bugs.llvm.org/show_bug.cgi?id=33858

Cheers,
Diana

On 28 August 2017 at 09:46, Sylvestre Ledru via Release-testers
 wrote:
> Hello
>
> I am not sure to understand how this relates to the 5.0.0 work?
>
> For now, it is broken because of a gcc bug:
>
> https://bugs.llvm.org/show_bug.cgi?id=34150
>
> I am planning to upgrade the gcc version to 4.9 to workaround this issue.
> Probably this week.
>
> Sylvestre
>
>
> Le 28/08/2017 à 09:40, Andrew Kelley via Release-testers a écrit :
>
> trusty on apt.llvm.org is behind the others by 9 days and is missing the
> latest rc3 release. Can we get an update on this?
>
> Regards,
> Andrew
>
> On Fri, Aug 25, 2017 at 6:52 PM, Hans Wennborg via llvm-dev
>  wrote:
>>
>> Dear testers,
>>
>> 5.0.0-rc3 was just tagged.
>>
>> This is a release candidate in the real sense: if nothing bad comes up
>> in testing, this is what the release is going to look like.
>>
>> Please build, test and upload binaries to the sftp (use the
>> /data/testers-uploads/ directory) and let me know what issues remain.
>>
>> I know we're a little bit behind schedule, but hopefully we can get to
>> 'final' soon.
>>
>> Cheers,
>> Hans
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[karnajit wangkhem via lldb-dev]

Thanks Jim for the help. I would definitely like to work on this PR soon.

Filed the PR here
https://bugs.llvm.org/show_bug.cgi?id=34341

Regards,
Karan

On Thu, Aug 24, 2017 at 11:17 PM, Jim Ingham  wrote:

>
> > On Aug 24, 2017, at 10:06 AM, karnajit wangkhem 
> wrote:
> >
> > Hi Jim,
> >
> > Thanks for the valuable reply. Please find my comments inline.
> >
> > Regards,
> > Karan
> >
> > On Wed, Aug 23, 2017 at 12:32 AM, Jim Ingham  wrote:
> >
> > > On Aug 21, 2017, at 12:02 PM, karnajit wangkhem via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > Hi All,
> > >
> > > Below is a sample example, where target.source-map seems to have a
> limitation. The limitation seems to be because
> > > 1. lldb does not have an equivalent command like directory in gdb
> >
> > The gdb "dir" command seemed always to be more annoying than useful in
> real situations.  If your project had any complexity in the directory
> structure you ended up having to add dir commands for all the
> subdirectories, which got tedious quickly.  Since you pretty much always
> move your sources around rigidly, "source maps" are a more natural way to
> specify this.
> >
> > Note, we could add a recursive "dir" command, but you can't do the
> simpleminded recursive search or you'll mess up when the sources have same
> named files in different directories.  Because of this, again the source
> maps seem more suited.
> >
> >
> > -- Really a good info to know. Thanks!
> >
> > > 2. target.source-map does not accept multiple mapping entries. I
> checked this only with freebsd.
> > >
> > > (lldb) settings show target.source-map
> > > target.source-map (path-map) =
> > > [0] "/home/karnajitw/lldb_test_execs/test_source_line1" ->
> "/u/test/test_source_line1"
> >
> > That is not correct:
> >
> > (lldb) settings set target.source-map /some/source/path /tmp
> /some/other/source/path /tmp
> > (lldb) settings show target.source-map
> > target.source-map (path-map) =
> > [0] "/some/source/path" -> "/tmp"
> > [1] "/some/other/source/path" -> "/tmp"
> >
> > or
> >
> > (lldb) set set target.source-map /some/source/path /tmp
> > (lldb) set append target.source-map /some/other/source/path /tmp
> > (lldb) set show target.source-map
> > target.source-map (path-map) =
> > [0] "/some/source/path" -> "/tmp"
> > [1] "/some/other/source/path" -> "/tmp"
> >
> > - Thanks! This helped.
> >
> > >
> > > 3. Haven't checked in the code yet, but if we see the mappings of
> scenario 1, they all point to a single real path 
> /home/karnajitw/lldb_test_execs/test_source_line1.
> But looks like the mapping logic only considers strings into account. But,
> at the same time, I am not claiming that they should be interpreted as path
> from a different machine during the mapping.
> > >
> >
> > I'm not sure what you mean here.  lldb does what it can to unwind the
> source path, but it doesn't assume that those paths actually exist locally,
> so the most it can do is remove redundant "/"-s and "/./"-s and unwind
> ".."-s.  We do this before most source path comparisons (it's part of the
> FileSpec Equals method).  We've been tinkering with this over time so make
> sure you are using a recent version of lldb.  If there are places where we
> don't do this, then that's easily fixed.
> >
> >
> > - Your answer is in line with what I wanted to know. My lldb should be
> quite recent. But I used it only for freebsd currently.
> >
> > % ./lldb --version
> > lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk
> revision 305778)
> >   clang revision 305546
> >   llvm revision 305548
> >
> >
> > > I want to check on this issue in-depth. But before that, want to
> confirm if this is real issue or there are other ways to deal these
> scenarios which I am not aware of?
> > >
> > > I am referring below link for the lldb commands.
> > > https://lldb.llvm.org/lldb-gdb.html
> > >
> > > 1. First scenario: Different souce file path representation
> > >
> > > [/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g
> /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
> /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> > >
> > > Machine 1: /home/karnajitw/lldb_test_execs/test_source_line1 ->
> Machine 2: /u/test/test_source_line1
> > >
> > > test_source_line1
> > > |-- a
> > > |   |-- ainc.c
> > > |   |-- ainc.h
> > > |   `-- b
> > > |   |-- binc.c
> > > |   `-- binc.h
> > > |-- a.out
> > > `-- main.c
> > >
> > > % ./lldb test_source_line1/a.out
> > >
> > > (lldb) target create "test_source_line1/a.out"
> > > Current executable set to 'test_source_line1/a.out' (x86_64).
> > > (lldb) l main
> > > File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
> > > (lldb) l afn
> > > File: /home/karnajitw/lldb_test_execs/../lldb_test_execs/test_
> source_line1/a/ainc.c
> > > (lldb) l bfn
> > > File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
> > >
> > > (

[lldb-dev] [Bug 34341] New: Fix lldb to use path normalization for these listed scenarios

[via lldb-dev]

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

Bug ID: 34341
   Summary: Fix lldb to use path normalization for these listed
scenarios
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: FreeBSD
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: karnaj...@gmail.com
CC: llvm-b...@lists.llvm.org

Raising this PR based on the following discussion
http://lists.llvm.org/pipermail/lldb-dev/2017-August/012665.html

This issue is seen in 2 scenarios:

Scenario 1: Different source file path representation

[/home/karnajitw/lldb_test_execs/test_source_line1] $ clang -O0 -g
/home/karnajitw/lldb_test_execs///test_source_line1/main.c
/home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
/home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c

(lldb) settings set target.source-map
/home/karnajitw/lldb_test_execs///test_source_line1 /u/test/test_source_line1

(lldb) l main
File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
   1#include "a/ainc.h"
   2
   3int main()
   4{
   5  afn();
   6
   7  bfn();
   8
   9  return 0;
   10   }
(lldb) l afn
File:
/home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
(lldb) l bfn
File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c

(lldb) settings set target.source-map
/home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1
/u/test/test_source_line1

(lldb) l main
File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
(lldb) l afn
File:
/home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
   1#include 
   2#include "ainc.h"
   3
   4void afn()
   5{
   6  printf("Hello this is afn...\n");
   7}
(lldb) l bfn
File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c

(lldb) settings set target.source-map
/home/karnajitw/lldb_test_execs/test_source_line1 /u/test/test_source_line1

(lldb) l main
File: /home/karnajitw/lldb_test_execs///test_source_line1/main.c
(lldb) l afn
File:
/home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1/a/ainc.c
(lldb) l bfn
File: /home/karnajitw/lldb_test_execs/test_source_line1/a/b/binc.c
   1#include 
   2#include "binc.h"
   3
   4void bfn()
   5{
   6  printf("Hello this is bfn...\n");
   7}

* We require all these 3 source mappings to list main, afn & bfn together. But
the LHS and RHS actually points to the same path. So this sould have required
only single mapping.

(lldb)
target.source-map (path-map) =
[0] "/home/karnajitw/lldb_test_execs///test_source_line1" ->
"/u/test/test_source_line1"
[1] "/home/karnajitw/lldb_test_execs/../lldb_test_execs/test_source_line1" ->
"/u/test/test_source_line1"
[2] "/home/karnajitw/lldb_test_execs/test_source_line1" ->
"/u/test/test_source_line1"

Scenario 2: Deep directory structure

$ build/bin/lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) settings set target.source-map
/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/../../../../../../../src/a/b/c/d/e/app
/home/karnajitw/app
(lldb) l main
File:
/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/../../../../../../../src/a/b/c/d/e/app/main.c
   1#include "sub/subfile.h"
   2
   3int main()
   4{
   5  subfn();
   6
   7  return 0;
   8}
   9
(lldb) l subfn
File:
/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app/sub/subfile.c

(lldb) settings append target.source-map
/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app
/home/karnajitw/app
(lldb) l subfn
File:
/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app/sub/subfile.c
   1#include 
   2#include "subfile.h"
   3
   4void subfn()
   5{
   6  printf("This is subfn...\n");
   7}
   8

* Similarly, this requires 2 source mappings to list both main and subfn.

(lldb) settings show target.source-map
target.source-map (path-map) =
[0]
"/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/../../../../../../../src/a/b/c/d/e/app"
-> "/home/karnajitw/app"
[1]
"/home/karnajitw/lldbtest/obj/a/b/c/d/e/app/sub/../../../../../../../../src/a/b/c/d/e/app"
-> "/home/karnajitw/app"


* Jim has already given the hint to solve this issue
"There's a method in FileSpec (GetNormalizedPath) that canonicalizes paths by
doing the obvious text substitution (unwinding ..'s and removing /./ and /// ->
/, etc.)  Somewhere in the comparison of the source and build paths we aren't
using this when we should do.  There's also a FileSpec::Equal method that
allows a canonicalized comparison.  It might be that there's just some obvious
place we should have been using that."

-- 
You are receiving this mail because:
You are the assignee 

Re: [lldb-dev] [Release-testers] [llvm-dev] [5.0.0 Release] Release Candidate 3 tagged

[Sylvestre Ledru via lldb-dev]

Hello

I am not sure to understand how this relates to the 5.0.0 work?

For now, it is broken because of a gcc bug:

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

I am planning to upgrade the gcc version to 4.9 to workaround this
issue. Probably this week.

Sylvestre


Le 28/08/2017 à 09:40, Andrew Kelley via Release-testers a écrit :
> trusty on apt.llvm.org  is behind the others by 9
> days and is missing the latest rc3 release. Can we get an update on this?
>
> Regards,
> Andrew
>
> On Fri, Aug 25, 2017 at 6:52 PM, Hans Wennborg via llvm-dev
> mailto:llvm-...@lists.llvm.org>> wrote:
>
> Dear testers,
>
> 5.0.0-rc3 was just tagged.
>
> This is a release candidate in the real sense: if nothing bad comes up
> in testing, this is what the release is going to look like.
>
> Please build, test and upload binaries to the sftp (use the
> /data/testers-uploads/ directory) and let me know what issues remain.
>
> I know we're a little bit behind schedule, but hopefully we can get to
> 'final' soon.
>
> Cheers,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
>
>
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev