Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu

[Pavel Labath via lldb-dev]

I think that's a question for your distro's (or ubuntu's) lldb package
maintainer. I think they probably have some custom patches there (if
they don't then they probably need them). If I'm not mistaken vanilla
lldb does not even support multiple lldb instalations side-by-side
(i.e., it will always search for "lldb-server", with no suffix).

As a workaround, you may be able to get this working by setting the
LLDB_DEBUGSERVER_PATH environment variable to point to the right
executable.

On 26 November 2017 at 06:04, Jeremiah via lldb-dev
 wrote:
> On my Pop!_OS machine (which is based on Ubuntu 17.10), using any
> version of LLDB above 3.8 gives me the error "process launch failed:
> unable to locate lldb-server-x.x.x" but when version 3.8 is installed,
> it works just fine.
>
> There are various posts across the web about the same problem on
> multipler versions of Ubuntu. The most common solution presented is to
> use update-alternatives, but that did not solve the problem for me. I
> also checked my bin directories and the binaries for lldb-server are
> there for any version I install.
> ___
> 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] Deadline extension: [CFP] LLVM toolchain devroom CFP at FOSDEM 2018

[Kristof Beyls via lldb-dev]

Hi all,

We've extended the deadline for submission to Sunday 3rd of December.

Thanks,

Kristof

2017-11-21 10:02 GMT+01:00 Kristof Beyls :

> This is just a gentle reminder that the deadline for submission is coming
> Sunday, 26th of November.
>
> Thanks,
>
> Kristof
>
> 2017-10-13 10:51 GMT+02:00 Kristof Beyls :
>
>> *CALL FOR PAPERS / PARTICIPATION*
>>
>> At FOSDEM 2018, LLVM will again participate with a dedicated devroom, on
>> February 4th, in Brussels.
>> As possibly the largest European Open Source Conference, FOSDEM attracts
>> more than 400 lectures and over 5000 hackers - many core contributors of
>> the worlds leading open source projects.
>> Complementing the LLVM developer meetings, the devroom at FOSDEM provides
>> a great opportunity for LLVM developers and the wider open source community
>> to get together, connect and discuss.
>>
>> We invite academic, industrial and hobbyist speakers to present their
>> work on developing or using LLVM, Clang, LLDB, Polly, Compiler-rt, etc.
>> We are looking for:
>>
>>- Keynote speakers.
>>- Technical presentations (30 minutes plus questions and discussion)
>>related to development of LLVM, Clang etc.
>>- Presentations about the use of LLVM, Clang in commercial, academic,
>>hobbyist and other projects.
>>- Tutorials.
>>- Lightning talks (5 minutes).
>>- Demos.
>>
>> The deadline for receiving proposals is November 26th, 2017.
>> Speakers will be notified of acceptance or rejection by December 12th.
>> Please find some advice on what constitutes a good proposal at the end of
>> this CFP.
>>
>> To submit a proposal, please create an account on the FOSDEM interface (
>> https://penta.fosdem.org/user/new_account). If you already have an
>> account from previous years, please reuse that.
>> Submit your proposal following https://penta.fosdem.org/submi
>> ssion/FOSDEM18, “Create Event”.
>> Please make sure you select "LLVM toolchain devroom" as the "Track”.
>> Presentations will be recorded and streamed. Sending your proposal
>> implies giving permission to be recorded. However, exceptions can be made
>> for exceptional circumstances.
>>
>>
>> *Registration*
>> FOSDEM does not require any registration and is free of charge.
>>
>>
>> *Organization*
>> The mailing list llvm-devroom at lists.fosdem.org can be used to discuss
>> issues of general interest related to the conference organization. Please,
>> do not reply to this email, as it is cross posted to many lists.
>>
>>
>> *Financial support*
>> There may be a possibility of limited funding to help presenting students
>> or presenting contributors who could not otherwise attend the conference.
>> If you need funding to be able to present at the meeting, or can help
>> sponsor, please tell us on llvm-devroom at lists.fosdem.org.
>>
>>
>> *Guidance on writing a proposal for the LLVM Dev Room*
>> This is a guide to help you submit a good proposal and increase your
>> chances of your proposal being accepted.
>>
>> If you have never presented at an LLVM meeting, then do not fear this
>> process. We are actively looking for new speakers who are excited about
>> LLVM and helping grow the community through these educational talks! You do
>> not need to be a long time developer to submit a proposal.
>>
>> General Guidelines:
>>
>>- It should be clear from your abstract what your topic is, who your
>>targeted audience is, and what are the takeaways for attendees. The 
>> program
>>committee does not have time to read 10 page papers for each submission.
>>- Talks about a use of LLVM (etc) should include details about how
>>LLVM is used and not only be about the resulting application.
>>- Tutorials on “how to use X” in LLVM (or other subproject) are
>>greatly desired and beneficial to many developers. Entry level topics are
>>encouraged as well.
>>- Typically a few paragraphs are sufficient.
>>
>>
>> Best regards,
>>
>> LLVM @ FOSDEM organisers
>>
>>
>>
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu

[Ted Woodward via lldb-dev]

I ran into the same problem with lldb 3.8 on Ubuntu 14.04. I created symlinks 
to get things working right. Now I can run "lldb" and it finds lldb-server.

In /usr/bin:
0 lrwxrwxrwx 1 root root 26 Nov 17 15:22 /usr/bin/lldb -> 
/usr/lib/llvm-3.8/bin/lldb*
0 lrwxrwxrwx 1 root root 24 Jul 18 11:06 /usr/bin/lldb-3.8 -> 
../lib/llvm-3.8/bin/lldb*
0 lrwxrwxrwx 1 root root 30 Jul 18 11:06 /usr/bin/lldb-3.8.0-3.8 -> 
../lib/llvm-3.8/bin/lldb-3.8.0*
0 lrwxrwxrwx 1 root root 24 Aug 23 17:50 /usr/bin/lldb-server -> 
/usr/bin/lldb-server-3.8*
0 lrwxrwxrwx 1 root root 31 Jul 18 11:06 /usr/bin/lldb-server-3.8 -> 
../lib/llvm-3.8/bin/lldb-server*

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

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
> Labath via lldb-dev
> Sent: Monday, November 27, 2017 5:32 AM
> To: Jeremiah 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Unable to Locate lldb-server on Ubuntu
> 
> I think that's a question for your distro's (or ubuntu's) lldb package 
> maintainer. I
> think they probably have some custom patches there (if they don't then they
> probably need them). If I'm not mistaken vanilla lldb does not even support
> multiple lldb instalations side-by-side (i.e., it will always search for 
> "lldb-
> server", with no suffix).
> 
> As a workaround, you may be able to get this working by setting the
> LLDB_DEBUGSERVER_PATH environment variable to point to the right
> executable.
> 
> On 26 November 2017 at 06:04, Jeremiah via lldb-dev  d...@lists.llvm.org> wrote:
> > On my Pop!_OS machine (which is based on Ubuntu 17.10), using any
> > version of LLDB above 3.8 gives me the error "process launch failed:
> > unable to locate lldb-server-x.x.x" but when version 3.8 is installed,
> > it works just fine.
> >
> > There are various posts across the web about the same problem on
> > multipler versions of Ubuntu. The most common solution presented is to
> > use update-alternatives, but that did not solve the problem for me. I
> > also checked my bin directories and the binaries for lldb-server are
> > there for any version I install.
> > ___
> > 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

[lldb-dev] race condition using gdb-remote over ssh port forwarding

[Christopher Book via lldb-dev]

Greetings, I've been using liblldb to remotely debug to a linux server with
port forwarding.  To do this, I start lldb-server to with --listen
specifying a localhost port, as well as with min-gdbserver-port and
--max-gdbserver-port to specify a specific port for use by 'gdb remote'.
Both ports are forwarded to the remote PC, where liblldb connects to
localhost.

This generally works fine, but there is a race condition.  When the client
tells lldb-server to start gdb-remote, the port is returned to the client
which may try to connect before the gdb-remote process is actually
listening.  Without port-forwarding, this is okay because the client has
retry logic:

ProcessGDBRemote::ConnectToDebugserver
...
   retry_count++;
if (retry_count >= max_retry_count)
  break;
usleep(10);

But with port-forwarding, the initial connection is always accepted by the
port-forwarder, and only then does it try to establish a connection to the
remote port.  It has no way to not accept the incoming local connection
until it tries the remote end.

lldb has some logic to detect this further in the function, by using a
handshake to ensure the connection is actually made:

  // We always seem to be able to open a connection to a local port
  // so we need to make sure we can then send data to it. If we can't
  // then we aren't actually connected to anything, so try and do the
  // handshake with the remote GDB server and make sure that goes
  // alright.
  if (!m_gdb_comm.HandshakeWithServer(&error)) {
m_gdb_comm.Disconnect();
if (error.Success())
  error.SetErrorString("not connected to remote gdb server");
return error;
  }

But the problem here is that no retry is performed on failure.  The caller
to the 'attach' API also can't retry because the gdb server is terminated
on the error.

I would like to submit a patch, but first check to see if this solution
would be acceptable:
- Include the handshake within the connection retry loop.
- This means fully disconnecting the re-establishing the connection in the
loop if the handshake fails.
- Changing the timeout check to be based on a total absolute time instead
of 50 iterations with a 100ms sleep.

Thoughts?

Alternatives could be:
- Have lldb-server delay responding to the 'start gdb server' request until
it could tell (somehow) that the process is listening.
- A sleep of some kind on the client side after starting the server but
before trying to connect.

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

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

[Greg Clayton via lldb-dev]

When I wrote the code I was assuming that when the platform lldb-server 
responds with the port that the gdb-remote would be ready to receive packets 
right away, so I can see how and why this is happening. Seems like we have the 
retry stuff under control when we don't get a connection right away, but we 
should fix this such that when we hand the port back to LLDB from platform 
lldb-server, it should be listening and ready to accept a connection right away 
with no delays needed, though this can wait until later since it currently 
works.

What kind of port forwarding are you using? The main issue is I would assume 
that when someone tries to connect to a port on the port forwarder that it 
would fail to connect if it isn't able to connect on the other side. So this 
really comes down to a question of what a standard port forwarder's contract 
should really be. 

If anyone has extensive experience in port forward tech, please chime in.

Short answer: not sure what the right solution is as it depends on what proper 
port forwarding etiquette is.

Greg





> On Nov 27, 2017, at 12:33 PM, Christopher Book via lldb-dev 
>  wrote:
> 
> Greetings, I've been using liblldb to remotely debug to a linux server with 
> port forwarding.  To do this, I start lldb-server to with --listen specifying 
> a localhost port, as well as with min-gdbserver-port and 
> --max-gdbserver-port to specify a specific port for use by 'gdb remote'.  
> Both ports are forwarded to the remote PC, where liblldb connects to 
> localhost.
> 
> This generally works fine, but there is a race condition.  When the client 
> tells lldb-server to start gdb-remote, the port is returned to the client 
> which may try to connect before the gdb-remote process is actually listening. 
>  Without port-forwarding, this is okay because the client has retry logic:
> 
> ProcessGDBRemote::ConnectToDebugserver
> ...
>retry_count++;
> if (retry_count >= max_retry_count)
>   break;
> usleep(10);
> 
> But with port-forwarding, the initial connection is always accepted by the 
> port-forwarder, and only then does it try to establish a connection to the 
> remote port.  It has no way to not accept the incoming local connection until 
> it tries the remote end.
> 
> lldb has some logic to detect this further in the function, by using a 
> handshake to ensure the connection is actually made:
> 
>   // We always seem to be able to open a connection to a local port
>   // so we need to make sure we can then send data to it. If we can't
>   // then we aren't actually connected to anything, so try and do the
>   // handshake with the remote GDB server and make sure that goes
>   // alright.
>   if (!m_gdb_comm.HandshakeWithServer(&error)) {
> m_gdb_comm.Disconnect();
> if (error.Success())
>   error.SetErrorString("not connected to remote gdb server");
> return error;
>   }
> 
> But the problem here is that no retry is performed on failure.  The caller to 
> the 'attach' API also can't retry because the gdb server is terminated on the 
> error.
> 
> I would like to submit a patch, but first check to see if this solution would 
> be acceptable:
> - Include the handshake within the connection retry loop.
> - This means fully disconnecting the re-establishing the connection in the 
> loop if the handshake fails.
> - Changing the timeout check to be based on a total absolute time instead of 
> 50 iterations with a 100ms sleep.
> 
> Thoughts?
> 
> Alternatives could be:
> - Have lldb-server delay responding to the 'start gdb server' request until 
> it could tell (somehow) that the process is listening.
> - A sleep of some kind on the client side after starting the server but 
> before trying to connect.
> 
> Thanks,
> Chris
> 
> 
> ___
> 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] race condition using gdb-remote over ssh port forwarding

[Jan Kratochvil via lldb-dev]

On Mon, 27 Nov 2017 21:33:04 +0100, Christopher Book via lldb-dev wrote:
> Thoughts?

Not sure if it is applicable in this case but GDB has this feature:
https://sourceware.org/gdb/onlinedocs/gdb/Server.html#Running-gdbserver
(gdb) target remote | ssh -T hostname gdbserver - hello


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

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

[Christopher Book via lldb-dev]

I have been using both a custom port-forwarding program as well as
OpenSSH.  The custom solution is a bit slower because it goes through a
proxy, so the problem doesn't manifest.  I've been trying to switch to
OpenSSH which is fast enough to consistent hit the race condition.

I would expect other solutions to be similar to OpenSSH because I don't
think there's a way to have the client connection fail based on the result
of a remote connection.  Our own forwarding solution was built using this
method because of this.

I agree that fixing this on the server seems like a better solution, since
the client only gets a port when it has one to connect to.  But I don't
know the best way to make this happen from lldb-server after launching the
gdb instance.

On Mon, Nov 27, 2017 at 4:48 PM Greg Clayton  wrote:

> When I wrote the code I was assuming that when the platform lldb-server
> responds with the port that the gdb-remote would be ready to receive
> packets right away, so I can see how and why this is happening. Seems like
> we have the retry stuff under control when we don't get a connection right
> away, but we should fix this such that when we hand the port back to LLDB
> from platform lldb-server, it should be listening and ready to accept a
> connection right away with no delays needed, though this can wait until
> later since it currently works.
>
> What kind of port forwarding are you using? The main issue is I would
> assume that when someone tries to connect to a port on the port forwarder
> that it would fail to connect if it isn't able to connect on the other
> side. So this really comes down to a question of what a standard port
> forwarder's contract should really be.
>
> If anyone has extensive experience in port forward tech, please chime in.
>
> Short answer: not sure what the right solution is as it depends on what
> proper port forwarding etiquette is.
>
> Greg
>
>
>
>
>
> > On Nov 27, 2017, at 12:33 PM, Christopher Book via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Greetings, I've been using liblldb to remotely debug to a linux server
> with port forwarding.  To do this, I start lldb-server to with --listen
> specifying a localhost port, as well as with min-gdbserver-port and
> --max-gdbserver-port to specify a specific port for use by 'gdb remote'.
> Both ports are forwarded to the remote PC, where liblldb connects to
> localhost.
> >
> > This generally works fine, but there is a race condition.  When the
> client tells lldb-server to start gdb-remote, the port is returned to the
> client which may try to connect before the gdb-remote process is actually
> listening.  Without port-forwarding, this is okay because the client has
> retry logic:
> >
> > ProcessGDBRemote::ConnectToDebugserver
> > ...
> >retry_count++;
> > if (retry_count >= max_retry_count)
> >   break;
> > usleep(10);
> >
> > But with port-forwarding, the initial connection is always accepted by
> the port-forwarder, and only then does it try to establish a connection to
> the remote port.  It has no way to not accept the incoming local connection
> until it tries the remote end.
> >
> > lldb has some logic to detect this further in the function, by using a
> handshake to ensure the connection is actually made:
> >
> >   // We always seem to be able to open a connection to a local port
> >   // so we need to make sure we can then send data to it. If we can't
> >   // then we aren't actually connected to anything, so try and do the
> >   // handshake with the remote GDB server and make sure that goes
> >   // alright.
> >   if (!m_gdb_comm.HandshakeWithServer(&error)) {
> > m_gdb_comm.Disconnect();
> > if (error.Success())
> >   error.SetErrorString("not connected to remote gdb server");
> > return error;
> >   }
> >
> > But the problem here is that no retry is performed on failure.  The
> caller to the 'attach' API also can't retry because the gdb server is
> terminated on the error.
> >
> > I would like to submit a patch, but first check to see if this solution
> would be acceptable:
> > - Include the handshake within the connection retry loop.
> > - This means fully disconnecting the re-establishing the connection in
> the loop if the handshake fails.
> > - Changing the timeout check to be based on a total absolute time
> instead of 50 iterations with a 100ms sleep.
> >
> > Thoughts?
> >
> > Alternatives could be:
> > - Have lldb-server delay responding to the 'start gdb server' request
> until it could tell (somehow) that the process is listening.
> > - A sleep of some kind on the client side after starting the server but
> before trying to connect.
> >
> > Thanks,
> > Chris
> >
> >
> > ___
> > 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.l

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

[Greg Clayton via lldb-dev]

> On Nov 27, 2017, at 3:50 PM, Christopher Book  wrote:
> 
> I have been using both a custom port-forwarding program as well as OpenSSH.  
> The custom solution is a bit slower because it goes through a proxy, so the 
> problem doesn't manifest.  I've been trying to switch to OpenSSH which is 
> fast enough to consistent hit the race condition.
> 
> I would expect other solutions to be similar to OpenSSH because I don't think 
> there's a way to have the client connection fail based on the result of a 
> remote connection.  Our own forwarding solution was built using this method 
> because of this.
> 
> I agree that fixing this on the server seems like a better solution, since 
> the client only gets a port when it has one to connect to.  But I don't know 
> the best way to make this happen from lldb-server after launching the gdb 
> instance.
> 

You might need to connect to it from the platform lldb-server and then 
disconnect and have the gdb-server listen for another connection. Maybe if you 
pass an extra argument for the double connect?


> On Mon, Nov 27, 2017 at 4:48 PM Greg Clayton  > wrote:
> When I wrote the code I was assuming that when the platform lldb-server 
> responds with the port that the gdb-remote would be ready to receive packets 
> right away, so I can see how and why this is happening. Seems like we have 
> the retry stuff under control when we don't get a connection right away, but 
> we should fix this such that when we hand the port back to LLDB from platform 
> lldb-server, it should be listening and ready to accept a connection right 
> away with no delays needed, though this can wait until later since it 
> currently works.
> 
> What kind of port forwarding are you using? The main issue is I would assume 
> that when someone tries to connect to a port on the port forwarder that it 
> would fail to connect if it isn't able to connect on the other side. So this 
> really comes down to a question of what a standard port forwarder's contract 
> should really be.
> 
> If anyone has extensive experience in port forward tech, please chime in.
> 
> Short answer: not sure what the right solution is as it depends on what 
> proper port forwarding etiquette is.
> 
> Greg
> 
> 
> 
> 
> 
> > On Nov 27, 2017, at 12:33 PM, Christopher Book via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > Greetings, I've been using liblldb to remotely debug to a linux server with 
> > port forwarding.  To do this, I start lldb-server to with --listen 
> > specifying a localhost port, as well as with min-gdbserver-port and 
> > --max-gdbserver-port to specify a specific port for use by 'gdb remote'.  
> > Both ports are forwarded to the remote PC, where liblldb connects to 
> > localhost.
> >
> > This generally works fine, but there is a race condition.  When the client 
> > tells lldb-server to start gdb-remote, the port is returned to the client 
> > which may try to connect before the gdb-remote process is actually 
> > listening.  Without port-forwarding, this is okay because the client has 
> > retry logic:
> >
> > ProcessGDBRemote::ConnectToDebugserver
> > ...
> >retry_count++;
> > if (retry_count >= max_retry_count)
> >   break;
> > usleep(10);
> >
> > But with port-forwarding, the initial connection is always accepted by the 
> > port-forwarder, and only then does it try to establish a connection to the 
> > remote port.  It has no way to not accept the incoming local connection 
> > until it tries the remote end.
> >
> > lldb has some logic to detect this further in the function, by using a 
> > handshake to ensure the connection is actually made:
> >
> >   // We always seem to be able to open a connection to a local port
> >   // so we need to make sure we can then send data to it. If we can't
> >   // then we aren't actually connected to anything, so try and do the
> >   // handshake with the remote GDB server and make sure that goes
> >   // alright.
> >   if (!m_gdb_comm.HandshakeWithServer(&error)) {
> > m_gdb_comm.Disconnect();
> > if (error.Success())
> >   error.SetErrorString("not connected to remote gdb server");
> > return error;
> >   }
> >
> > But the problem here is that no retry is performed on failure.  The caller 
> > to the 'attach' API also can't retry because the gdb server is terminated 
> > on the error.
> >
> > I would like to submit a patch, but first check to see if this solution 
> > would be acceptable:
> > - Include the handshake within the connection retry loop.
> > - This means fully disconnecting the re-establishing the connection in the 
> > loop if the handshake fails.
> > - Changing the timeout check to be based on a total absolute time instead 
> > of 50 iterations with a 100ms sleep.
> >
> > Thoughts?
> >
> > Alternatives could be:
> > - Have lldb-server delay responding to the 'start gdb server' request until 
> > it could tell (somehow) that the process is listenin