Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Pavel Labath via lldb-dev]

sleep_for is definitely better than usleep because of portability (and
we use it elsewhere already).

Could you attach the patch to phabricator instead
 ? It's easier to make
comments and iterate there. When you upload the patch be sure to
include full context in it (git diff -U or similar). Or you can
use the arcanist tool which will do it for you.

As for the test, there are two test ways you can do that. One is using
the python tests
(test/testcases/tools/lldb-server/TestGdbRemoteAttach.py would be a
good starting point), other is via googletest
(unittests/tools/lldb-server/LLGSTest.cpp). Neither of the tests is
going to be particularly nice because you will have to juggle multiple
things (speaking with the server and launching the inferior), but it
should be doable using both.

We should already be able to display a better error message, if the
server sends one (the Status overload of the SendErrorResponse
function). If the error string that comes out of that is not good
enough, then we can tweak whoever creates the Status object to fill it
out better as a separate patch.


On Thu, 7 Jun 2018 at 04:23, Ryan Lovelett via lldb-dev
 wrote:
>
> I'm attaching the first cut of the patch that I think is worth sharing for 
> feedback. There is more work to do with regard to documentation and tests. 
> Any feedback is appreciated.
>
> I am going to do my best and follow the steps listed in the "LLVM Developer 
> Policy" as this continues forward.
>
> Greg, Pavel, and Jim thank you very much for the help you have provided thus 
> far. This would have been insurmountable without the guidance.
> ___
> 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 Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

> sleep_for is definitely better than usleep because of portability (and
> we use it elsewhere already).

Okay that is what I went with.
 
> Could you attach the patch to phabricator instead
>  ? It's easier to make
> comments and iterate there. When you upload the patch be sure to
> include full context in it (git diff -U or similar). Or you can
> use the arcanist tool which will do it for you.

I _think_ I have done this correctly.

https://reviews.llvm.org/D47879

$ svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb-trunk
$ patch 0001-First-working-attempt.patch # this is what I mailed last night
$ arc diff

I was not quite sure what I should write for a title or summary. Based on other 
differentials on the site, the title usually seems to have something in 
brackets but it is not clear to me what that should be in my case.

> As for the test, there are two test ways you can do that. One is using
> the python tests
> (test/testcases/tools/lldb-server/TestGdbRemoteAttach.py would be a
> good starting point), other is via googletest
> (unittests/tools/lldb-server/LLGSTest.cpp). Neither of the tests is
> going to be particularly nice because you will have to juggle multiple
> things (speaking with the server and launching the inferior), but it
> should be doable using both.

I will see what I can glean from those examples. See if I can turn them into 
something.

> We should already be able to display a better error message, if the
> server sends one (the Status overload of the SendErrorResponse
> function). If the error string that comes out of that is not good
> enough, then we can tweak whoever creates the Status object to fill it
> out better as a separate patch.

I will look into this and see what is currently happening.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [7.0.0 Release] Schedule proposal

[Hans Wennborg via lldb-dev]

Hello everyone,

There's plenty of time before the release process starts, but I'd like
to begin the schedule discussion.

For the September release we usually branch mid-July. However, this
year my vacation runs a little later, so a good branch date for me
would be the 1st of August.

Proposal:

- 1 August 2018: Branch; RC1 soon after
- 22 August 2018: RC2; all lose ends should be tied up by now
- 5 September; final tag, release a few days later (don't slip past
first half of September)

What do you think?

I'm particularly keen to hear from those helping to test the release,
and from downstream consumers of the branch.

If the community prefers an earlier branch date, I can take a day off
vacation to set it up but I probably can't help much with bug fixing
and merging before August.

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

Re: [lldb-dev] [cfe-dev] [7.0.0 Release] Schedule proposal

[via lldb-dev]

> Proposal:
> 
> - 1 August 2018: Branch; RC1 soon after
> - 22 August 2018: RC2; all lose ends should be tied up by now
> - 5 September; final tag, release a few days later (don't slip past
> first half of September)
> 
> What do you think?
> 
> I'm particularly keen to hear from those helping to test the release,
> and from downstream consumers of the branch.

As a downstream consumer, Sony is okay with the proposed schedule.
--paulr

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