Hi,
I am running Linux Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-51-generic x86_64) in
virtual machine.
When I am trying to write memory in my process, sometimes it works but
sometimes lldb-server goes unresponsive. It spins with 100% CPU utilization and
does not respond to any signals except SIGK
I'm not able to repro at head (on Windows 7).
On Tue, Dec 6, 2016 at 10:48 AM, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I've also never seen either problem. I'm not debugging Windows apps, but
> Hexagon apps, running lldb and the Hexagon simulator on Win7.
>
> --
> Qualcomm
This seems to work: https://reviews.llvm.org/D27476
On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg wrote:
> The only thing needed to build the installer should be having NSIS
> installed and building the "package" target generated by CMake. The
> other prerequisites are mostly for building the v
On Tue, Dec 6, 2016 at 10:31 AM Greg Clayton wrote:
>
>
>
> It should be a formatter option for collections to allow you to print out
> different ranges. If I have a target and a target knows how to print the
> process and the process knows how to print the threads and the threads know
> how to p
On 6 December 2016 at 18:30, Jim Ingham wrote:
>
>> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote:
>>
>>> I think having a convenience to add function name decorators is fine, but
>>> we need a way not to do it all the time. We have logs that don't have
>>> function names because they log ov
I've also never seen either problem. I'm not debugging Windows apps, but
Hexagon apps, running lldb and the Hexagon simulator on Win7.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
> -Ori
> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote:
>
>> I think having a convenience to add function name decorators is fine, but we
>> need a way not to do it all the time. We have logs that don't have function
>> names because they log over several functions, and having the different
>> na
> On Dec 6, 2016, at 10:20 AM, Pavel Labath wrote:
>
> On 6 December 2016 at 17:39, Jim Ingham wrote:
>>
>>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>>>
>>> Hello all,
>>>
>>> I've been thinking about how to simplify the way we do logging in
>>> lldb. The main two problems I see are
On 6 December 2016 at 17:39, Jim Ingham wrote:
>
>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>>
>> Hello all,
>>
>> I've been thinking about how to simplify the way we do logging in
>> lldb. The main two problems I see are:
>> a) inability to print complex types easily - this was always tr
I like the the llvm::formatv stuff and could see using this exclusively. I am
getting scared of using streams and << the more I think about it after my
previous email since we would need to mark a log message as starting and ending
somehow and that would make things messy.
Note that our logging
> On Dec 6, 2016, at 10:07 AM, Zachary Turner wrote:
>
> Merging the thread over from lldb-commits:
>
>
>
> On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator
> wrote:
> jingham added a comment.
>
> I not infrequently have some non-trivial code in the "if (log)" block that
> gather
The other problem with using streams is we need each log line to come out in a
single chunk. So we somehow need to specify the start and end of a log. For
example if two threads are doing:
if (log)
log->Printf("%i %i %i\n", x, y z);
And we switch over to using:
if (log) *log << 1 << ' ' <<
Merging the thread over from lldb-commits:
On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> I not infrequently have some non-trivial code in the "if (log)" block that
> gathers the information that I am then going to pri
BTW, I just want to make it clear in this discussion that logging is a really
important part of lldb. This isn't a matter of "you had some debug logging you
put in to solve a problem, and you didn't want to have to take it out next time
you use it." We very often get bugs from customers who ca
> On Dec 6, 2016, at 9:32 AM, Pavel Labath wrote:
>
> Ah, I totally forgot about the llvm DEBUG macro. I would be open to
> trying merge these two approaches together. However, I think our's is
> a much more heavy-weight system, so it might be too heavy for llvm,
> and I am not sure how much wou
> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>
> Hello all,
>
> I've been thinking about how to simplify the way we do logging in
> lldb. The main two problems I see are:
> a) inability to print complex types easily - this was always tricky,
> but lately has become even more problematic, a
Ah, I totally forgot about the llvm DEBUG macro. I would be open to
trying merge these two approaches together. However, I think our's is
a much more heavy-weight system, so it might be too heavy for llvm,
and I am not sure how much would we be willing to lose in the process:
- we have two level lo
Ah, cool! I'll have a look.
Jim
> On Dec 6, 2016, at 8:57 AM, Pavel Labath wrote:
>
> On 6 December 2016 at 16:51, Jim Ingham wrote:
>> Sorry, I'm being dense. What is Dx?
>>
>> Jim
>>
>>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>>>
>>> I have created straw-man implementation
My only concern reading this is that LLVM already has a similar mechanism for
channel-based logging that is used throughout the backends. Is there a reason
to invent our own? Maybe we can take what is in LLVM, enhance it and use shared
functionality?
There are a few differences between your sol
On 6 December 2016 at 16:51, Jim Ingham wrote:
> Sorry, I'm being dense. What is Dx?
>
> Jim
>
>> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>>
>> I have created straw-man implementation of such an interface in
>> Dx, together with some examples of how it's used, and I'd like to
>
Code review with an unspecified number I think
On Tue, Dec 6, 2016 at 8:55 AM Jim Ingham wrote:
> Sorry, I'm being dense. What is Dx?
>
> Jim
>
> > On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
> >
> > I have created straw-man implementation of such an interface in
> > Dx, together wi
It's not atomic, but I specify a specific revision when creating the
branch, across all projects, so it has the same effect.
When creating tags on the branch I just create it on tip-of-tree since
the branch is low traffic.
Does that address your concerns?
On Tue, Dec 6, 2016 at 3:31 AM, NAKAMURA
Sorry, I'm being dense. What is Dx?
Jim
> On Dec 6, 2016, at 8:23 AM, Pavel Labath wrote:
>
> I have created straw-man implementation of such an interface in
> Dx, together with some examples of how it's used, and I'd like to
___
lldb-dev ma
> From: Zachary Turner
> Date: Tue, 06 Dec 2016 16:22:51 +
>
> I have never seen either of those problems, but I can test it out and see if
> I can reproduce.
Thanks.
If you are unable to reproduce, I wonder why it happens to me. The
system where I installed lldb is just a vanilla Windows
(Or if you see any other code that looks like it's work-in-progress,
and it's timeout related. I don't want to leave stuff half-finished.)
On 6 December 2016 at 16:29, Pavel Labath wrote:
> Hi all,
>
> I have removed llvm and lldb TimeValues, and ported the remaining
> usages of raw timeout value
Hi all,
I have removed llvm and lldb TimeValues, and ported the remaining
usages of raw timeout values I found to std::chrono (SB API excluded).
If you find any that are left, let me know, and I can get to them as
well.
pl
On 12 October 2016 at 10:11, Pavel Labath wrote:
> My current plan is to
Hello all,
I've been thinking about how to simplify the way we do logging in
lldb. The main two problems I see are:
a) inability to print complex types easily - this was always tricky,
but lately has become even more problematic, as we're starting to
introduce llvm::StringRef, chrono, and other no
I have never seen either of those problems, but I can test it out and see
if I can reproduce.
On Tue, Dec 6, 2016 at 7:59 AM Eli Zaretskii via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> > Date: Tue, 15 Nov 2016 18:08:03 +0200
> > Cc: lldb-dev@lists.llvm.org
> > From: Eli Zaretskii via lldb-dev
> Date: Tue, 15 Nov 2016 18:08:03 +0200
> Cc: lldb-dev@lists.llvm.org
> From: Eli Zaretskii via lldb-dev
>
> > From: Rudy Pons
> > Date: Tue, 15 Nov 2016 01:08:52 +0100
> > Cc: lldb-dev@lists.llvm.org
> >
> > I had a similar crash, and submitted a patch commited in rL285843
> > You could try to
I hope you could branch and tag to projects atomically. Are you able?
On Tue, Dec 6, 2016 at 3:26 AM Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:
> Dear everyone,
>
> There's still plenty of time left, but I'd like to get the schedule
> set before folks start disappe
30 matches
Mail list logo
