Re: [lldb-dev] [llvm-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)

2017-02-23 Thread David Chisnall via lldb-dev 
On 18 Feb 2017, at 02:10, Anna Zaks via llvm-dev  
wrote:
> 
> While students with previous LLVM dev experience will be more productive, 
> GSoC is a great way of attracting newcomers to the project! So if a proposal 
> is scoped to be completed in time even by someone not familiar with LLVM, we 
> should still accept it.

I’d also add, from having mentored GSoC projects for several open source 
projects, that there are two ways of considering success for a GSoC project:

1. The student completes the work and it’s incorporated into trunk.
2. The student becomes engaged with the project and continues to contribute 
after the end of the GSoC.

The former treats the GSoC as an expensive way of getting a particular feature 
added (yes, Google pays the student, but generally the mentor time comes from 
somewhere and that’s not free, it’s time that would otherwise be spent 
contributing to the project in another way).  The second treats the GSoC as a 
powerful recruitment tool.  I’ve had a couple of students that succeeded in the 
first way, but didn’t really benefit the project, because they left at the end 
of the GSoC.  I’ve also had a few that managed some proof-of-concept code that 
ended up showing that the entire GSoC project idea was the wrong approach, but 
then remained active contributors for years and ended up contributing far more 
(good) code than I’d have written if I’d spent the time that I spent mentoring 
them on hacking.

I would strongly encourage treating the GSoC as a way of engaging students.  
I’d also hope that the Foundation’s Women in Compilers and Tools project will 
help encourage this kind of participation in a way that meshes well with the 
GSoC.  

David

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

Re: [lldb-dev] problem question, LLDB: process launch failed: Lost debug server connection

2017-02-23 Thread Greg Clayton via lldb-dev 
Check your ptrace permissions?

http://askubuntu.com/questions/41629/after-upgrade-gdb-wont-attach-to-process


> On Feb 22, 2017, at 7:01 PM, 이승준 via lldb-dev  wrote:
> 
> Hello. I am Lee.  
> I have trouble to run lldb.
> My system is Ubutu 16.10-server & downloaded lldb version 3.8.1 via apt-get 
> install.
>  
> I wand just local debugging. But err message is like below.
>  
> tt@ttt:~/trunk$ lldb /system/bin/cwm
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named lldb.embedded_interpreter
> (lldb) target create "/system/bin/cwm"
> Current executable set to '/system/bin/cwm' (i386).
> (lldb) r
> error: process launch failed: Lost debug server connection
> (lldb)
>  
> Plz answer about this problem
>  
> Thank you.
> 
> 
>  
> 이 이메일은 Avast 안티바이러스 소프트웨어로 바이러스 검사를 완료했습니다. 
> www.avast.com 
> ___
> 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] Fwd: GDB Remote target descriptions

2017-02-23 Thread jw4...@gmail.com via lldb-dev 
Never got a response to this, did I miss it somehow?  If not, please see
below.

-- Forwarded message --
From: jw4...@gmail.com 
Date: Fri, Dec 2, 2016 at 9:21 PM
Subject: GDB Remote target descriptions
To: lldb-dev@lists.llvm.org


Hi all,

I've been adding support for the qXfer:features:read:target.xml message for
our tools at $WORK and have run into a couple hiccups to puzzle over.
First off, the request message as defined at https://sourceware.org/gdb/
onlinedocs/gdb/General-Query-Packets.html#qXfer%20target%
20description%20read is in the form qXfer:features:read:annex:offset,size.
When talking to GDB it works to respond with a 'l' or 'm' message smaller
than size, then GDB proceeds to request the next chunk, and so on until the
debug server says there is no more data.  I believe there is a bug in
lldb's handling of this message in that if the response is shorter than
'size' while also being incomplete, lldb requests the next chunk with a
giant offset.  This patch fixes the behavior:

Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
(revision 288181)
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
(working copy)
@@ -3342,7 +3342,7 @@
 case ('m'):
   if (str.length() > 1)
 output << &str[1];
-  offset += size;
+  offset += str.length() - 1;
   break;

 // unknown chunk

Secondly, it appears that lldb only processes a single  element
per "file" when discovering the register descriptions, the workaround seems
to be to put each individual feature in an  file or
conglomerate everything under a single feature in target.xml, but that has
an unfortunate side effect of not working right when talking to GDB.  This
one I didn't dig too far into that code but it looks like
ProcessGDBRemote::GetGDBServerRegisterInfo
only extracts a single  node (the last one) from the target
description.

In any case, these are both able to be worked around in my environment
without too much work but it would be nice to get at least that first item
fixed.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] GDB Remote target descriptions

2017-02-23 Thread Greg Clayton via lldb-dev 
That first change looks ok. Feel free to submit a patch for the multiple 
 request. Someone added this on linux a while back and was probably 
just working with their gdbserver that only sent a single packet. Shouldn't be 
too hard to fix.

Feel free to submit a patch via Phabricator:

http://llvm.org/docs/Phabricator.html


> On Dec 2, 2016, at 9:21 PM, jw4...@gmail.com via lldb-dev 
>  wrote:
> 
> Hi all,
> 
> I've been adding support for the qXfer:features:read:target.xml message for 
> our tools at $WORK and have run into a couple hiccups to puzzle over.
> First off, the request message as defined at 
> https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20target%20description%20read
>  
> 
>  is in the form qXfer:features:read:annex:offset,size.  When talking to GDB 
> it works to respond with a 'l' or 'm' message smaller than size, then GDB 
> proceeds to request the next chunk, and so on until the debug server says 
> there is no more data.  I believe there is a bug in lldb's handling of this 
> message in that if the response is shorter than 'size' while also being 
> incomplete, lldb requests the next chunk with a giant offset.  This patch 
> fixes the behavior:
> 
> Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
> ===
> --- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp  
> (revision 288181)
> +++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp  
> (working copy)
> @@ -3342,7 +3342,7 @@
>  case ('m'):
>if (str.length() > 1)
>  output << &str[1];
> -  offset += size;
> +  offset += str.length() - 1;
>break;
> 
>  // unknown chunk
> 
> Secondly, it appears that lldb only processes a single  element per 
> "file" when discovering the register descriptions, the workaround seems to be 
> to put each individual feature in an  file or conglomerate 
> everything under a single feature in target.xml, but that has an unfortunate 
> side effect of not working right when talking to GDB.  This one I didn't dig 
> too far into that code but it looks like 
> ProcessGDBRemote::GetGDBServerRegisterInfo only extracts a single  
> node (the last one) from the target description.
> 
> In any case, these are both able to be worked around in my environment 
> without too much work but it would be nice to get at least that first item 
> fixed.
> ___
> 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] [Bug 32053] New: lldb-mi outputs extra =thread-group-exited after -gdb-exit

2017-02-23 Thread via lldb-dev 
http://bugs.llvm.org/show_bug.cgi?id=32053

Bug ID: 32053
   Summary: lldb-mi outputs extra =thread-group-exited after
-gdb-exit
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: malape...@gmail.com
CC: llvm-b...@lists.llvm.org

Reproduced on macOS 10.12 with latest SVN trunk and Ubuntu 16.04 with lldb 3.8

For example, if I start debugging this simple program:

int main() {
}

lldb-mi ./a.out

-exec-run
...
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)
-gdb-exit
^exit
=thread-group-exited,id="i1"
(gdb)


(Here back to terminal)

I don't think there should be any "=thread-group-exited" after the exit.

The GDB output looks like this:
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb) 
-gdb-exit
^exit
(Here back to terminal)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev