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

[Ryan Lovelett via lldb-dev]

Greg,

Is there anything I can do to help you implement or test this feature?
Obviously I'm willing to roll-up my sleeves and work on this myself too
if you've become more busy than you expected. That happens to us all and
I completely understand.
Not being able to debug in this manner is blocking me from adding Linux
support to a Swift program. As you might imagine, I'm a little antsy to
get past this so I can start writing some code.
On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
> 
> 
>> On May 31, 2018, at 12:40 PM, Ryan Lovelett  wrote:>> 
>> Well at least there is a little good news. I understood way more of
>> those logs than I thought I did.>> 
>>> So two issues here:
>>> 1 - we need a better error message when vAttachWait returns
>>> unsupported>>> 2 - fix lldb-server to support vAttachWait
>> 
>> A few questions.
>> 
>> What is the protocol here? Can/should I report the issues at
>> https://bugs.llvm.org/ ? Or is that something that a project member
>> needs to do? Assuming that I can, would this be two seperate issues
>> or one "large" issue?>> 
>> Barring that this is not something someone else might implement
>> better/faster than me. Considering I have zero LLDB development
>> experience is this something that I could tackle?> 
> I didn't realize this functionality was missing in lldb-server. I can
> take a stab at implementing it and see what I can do. Stay tuned.> 
>> 
>> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
>>> lldb-server claims it doesn't support it:
>>> 
>>> lldb <  48> send packet:
>>> $vAttachWait;6c616e677365727665722d7377696674#d6>>> lldb <   4> 
>>> read packet: $#00
>>> 
>>> 
>>> Returning the empty packet ("$#00") means it is not supported, but
>>> we really should give a better error message than this.>>> 
>>> It isn't that hard to implement. It would be easy to copy the code
>>> that is in debugserver in DNB.cpp in the DNBProcessAttachWait
>>> function. Most of it is probably posix style stuff.>>> 
>>> So two issues here:
>>> 1 - we need a better error message when vAttachWait returns
>>> unsupported>>> 2 - fix lldb-server to support vAttachWait
>>> 
>>> Greg
>>> 
>>> 
 On May 31, 2018, at 11:04 AM, Ryan Lovelett 
 wrote: 
> It might be a lldb-server issue?
 
 How would one go about determining this?
 
 (lldb) log enable -f /tmp/packates.txt gdb-remote packets
 (lldb) process attach --name "" --waitfor
 error: attach failed: lost connection
 
 Attached the log output. Maybe it'll make more sense to you
 than me. 
 That escalated quickly. So I've read through that log. I found
 something that says $qVAttachOrWaitSupported#38 with the following
 response being $#00. Perhaps I'm reading too much but is it that
 it's reporting that it is not supported? 
 Does lldb-server need to be compiled in a certain way to add
 support for attach wait? 
 On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
> Try enabling logging with:
> 
> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
> 
> And the try the attach. It might be a lldb-server issue?
> 
>> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev > d...@lists.llvm.org> wrote:>> 
>> I am attempting to use: process attach --name "" --waitfor>> 
>> The problem is that it immediately returns error: attach failed:
>> lost connection.>> 
>> Is this something I can troubleshoot further? Or is this not
>> supported on Linux?>> 
>> -- 
>> Ryan Lovelett
>> ___
>> 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 37683] New: Register commands fail to retrieve all registers on Windows

[via lldb-dev]

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

Bug ID: 37683
   Summary: Register commands fail to retrieve all registers on
Windows
   Product: lldb
   Version: 6.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: sti...@microsoft.com
CC: llvm-b...@lists.llvm.org

This is true even for frame 0. The tests covered by TestRegisters.py all fail
except for test_register_commands which only tests very basic register
information.

Any of the commands that try to retrieve eax, for example, fail to do so.

For example, register read -a should retrieve registers such as eax, but this
is what we get during test execution:

AssertionError: False is not True : 'register read -a' returns expected result,
got 'General Purpose Registers:
   rax = 0x018E33F86E60
   rbx = 0x7FF66B5E9974
   rcx = 0x0001
   rdx = 0x018E33F83370
   rdi = 0x018E33F83370
   rsi = 0x
   rbp = 0x
   rsp = 0x00297830FDF0
r8 = 0x018E33F86E60
r9 = 0x00297830FE08
   r10 = 0x4CC4
   r11 = 0x0246
   r12 = 0x
   r13 = 0x
   r14 = 0x
   r15 = 0x
   rip = 0x7FF66B541023  a.out`main + 35 at main.cpp:20
eflags =
0b00100110'

-- 
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

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

[Greg Clayton via lldb-dev]

I will be too busy this week to get to this, so please do have a stab at it.

Basically the flow that debug server does is:
1 - get a list of all processes whose basename matches and remember those pids 
so we don't try to attach to them since we are waiting for a new process to 
show up
2 - poll the OS for the process list and wait for a new pid to show up with the 
basename and attach to the first one that matches whose pid isn't i the list 
from step #1

On MacOSX we don't have a way to be notified of new processes are spawned, not 
sure on other unix variants. If it is possible, we would want change to:
1 - sign up to be notified about new processes
2 - as each process gets launched, check for a match and attach as quickly as 
possible

Hope this helps and I look forward to seeing your patch!

Greg

> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
> 
> Greg,
> 
> Is there anything I can do to help you implement or test this feature? 
> Obviously I'm willing to roll-up my sleeves and work on this myself too if 
> you've become more busy than you expected. That happens to us all and I 
> completely understand.
> 
> Not being able to debug in this manner is blocking me from adding Linux 
> support to a Swift program. As you might imagine, I'm a little antsy to get 
> past this so I can start writing some code. 
> 
> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
>> 
>> 
>>> On May 31, 2018, at 12:40 PM, Ryan Lovelett >> > wrote:
>>> 
>>> Well at least there is a little good news. I understood way more of those 
>>> logs than I thought I did.
>>> 
 So two issues here:
 1 - we need a better error message when vAttachWait returns unsupported
 2 - fix lldb-server to support vAttachWait
>>> 
>>> A few questions.
>>> 
>>> What is the protocol here? Can/should I report the issues at 
>>> https://bugs.llvm.org/  ? Or is that something that 
>>> a project member needs to do? Assuming that I can, would this be two 
>>> seperate issues or one "large" issue?
>>> 
>>> Barring that this is not something someone else might implement 
>>> better/faster than me. Considering I have zero LLDB development experience 
>>> is this something that I could tackle?
>> 
>> I didn't realize this functionality was missing in lldb-server. I can take a 
>> stab at implementing it and see what I can do. Stay tuned.
>> 
>>> 
>>> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
 lldb-server claims it doesn't support it:
 
 lldb <  48> send packet: 
 $vAttachWait;6c616e677365727665722d7377696674#d6
 lldb <   4> read packet: $#00
 
 
 Returning the empty packet ("$#00") means it is not supported, but we 
 really should give a better error message than this. 
 
 It isn't that hard to implement. It would be easy to copy the code that is 
 in debugserver in DNB.cpp in the DNBProcessAttachWait function. Most of it 
 is probably posix style stuff. 
 
 So two issues here:
 1 - we need a better error message when vAttachWait returns unsupported
 2 - fix lldb-server to support vAttachWait
 
 Greg
 
 
> On May 31, 2018, at 11:04 AM, Ryan Lovelett  > wrote:
> 
>> It might be a lldb-server issue?
> 
> How would one go about determining this?
> 
> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
> (lldb) process attach --name "" --waitfor
> error: attach failed: lost connection
> 
> Attached the log output. Maybe it'll make more sense to you than me.
> 
> That escalated quickly. So I've read through that log. I found something 
> that says $qVAttachOrWaitSupported#38 with the following response being 
> $#00. Perhaps I'm reading too much but is it that it's reporting that it 
> is not supported?
> 
> Does lldb-server need to be compiled in a certain way to add support for 
> attach wait?
> 
> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
>> Try enabling logging with:
>> 
>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
>> 
>> And the try the attach. It might be a lldb-server issue?
>> 
>>> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> I am attempting to use: process attach --name "" --waitfor
>>> 
>>> The problem is that it immediately returns error: attach failed: lost 
>>> connection.
>>> 
>>> Is this something I can troubleshoot further? Or is this not supported 
>>> on Linux?
>>> 
>>> -- 
>>> Ryan Lovelett
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> 
> 

_

[lldb-dev] June LLVM bay-area social is this Thursday!

[George Burgess IV via lldb-dev]

We'll be at Tied House as usual, starting on Thursday the 7th at 7pm!

If you can, help us plan and RSVP here:
https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyxjbkb/

See everyone there!

(Aside: please note that we *do* plan on having a social at the regular
time next month, despite it falling on the day after 4-Jul. If you're in
the area, as always, feel free to stop by and say hi :) )
___
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]

So I've found a capability on Linux to be notified about new processes.
I have an example of listening for these new processes running on my
machine now [1] and I can see when my desired user process spawns.
Though documentation on the API is scarce. It also requires that the
executable or user have the CAP_NET_ADMIN capability to run.
It's possible that the addition of this requirement is a non-starter.
Though I'm not 100% sure. Do you have any thoughts before I pursue
this further?
[1] http://bazaar.launchpad.net/~kees/+junk/cn_proc/files/3

On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> I will be too busy this week to get to this, so please do have a
> stab at it.> 
> Basically the flow that debug server does is:
> 1 - get a list of all processes whose basename matches and remember
> those pids so we don't try to attach to them since we are waiting for
> a new process to show up> 2 - poll the OS for the process list and wait for a 
> new pid to show up
> with the basename and attach to the first one that matches whose pid
> isn't i the list from step #1> 
> On MacOSX we don't have a way to be notified of new processes are
> spawned, not sure on other unix variants. If it is possible, we would
> want change to:> 1 - sign up to be notified about new processes
> 2 - as each process gets launched, check for a match and attach as
> quickly as possible> 
> Hope this helps and I look forward to seeing your patch!
> 
> Greg
> 
>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
>> 
>> Greg,
>> 
>> Is there anything I can do to help you implement or test this
>> feature? Obviously I'm willing to roll-up my sleeves and work on this
>> myself too if you've become more busy than you expected. That happens
>> to us all and I completely understand.>> 
>> Not being able to debug in this manner is blocking me from adding
>> Linux support to a Swift program. As you might imagine, I'm a little
>> antsy to get past this so I can start writing some code.>> 
>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
>>> 
>>> 
 On May 31, 2018, at 12:40 PM, Ryan Lovelett 
 wrote: 
 Well at least there is a little good news. I understood way more of
 those logs than I thought I did. 
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait
 
 A few questions.
 
 What is the protocol here? Can/should I report the issues at
 https://bugs.llvm.org/ ? Or is that something that a project member
 needs to do? Assuming that I can, would this be two seperate issues
 or one "large" issue? 
 Barring that this is not something someone else might implement
 better/faster than me. Considering I have zero LLDB development
 experience is this something that I could tackle?>>> 
>>> I didn't realize this functionality was missing in lldb-server. I
>>> can take a stab at implementing it and see what I can do. Stay
>>> tuned.>>> 
 
 On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
> lldb-server claims it doesn't support it:
> 
> lldb <  48> send packet:
> $vAttachWait;6c616e677365727665722d7377696674#d6> lldb <  
>  4> read packet: $#00
> 
> 
> Returning the empty packet ("$#00") means it is not supported, but
> we really should give a better error message than this.> 
> It isn't that hard to implement. It would be easy to copy the code
> that is in debugserver in DNB.cpp in the DNBProcessAttachWait
> function. Most of it is probably posix style stuff.> 
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait
> 
> Greg
> 
> 
>> On May 31, 2018, at 11:04 AM, Ryan Lovelett 
>> wrote:>> 
>>> It might be a lldb-server issue?
>> 
>> How would one go about determining this?
>> 
>> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
>> (lldb) process attach --name "" --waitfor
>> error: attach failed: lost connection
>> 
>> Attached the log output. Maybe it'll make more sense to you than
>> me.>> 
>> That escalated quickly. So I've read through that log. I found
>> something that says $qVAttachOrWaitSupported#38 with the
>> following response being $#00. Perhaps I'm reading too much but
>> is it that it's reporting that it is not supported?>> 
>> Does lldb-server need to be compiled in a certain way to add
>> support for attach wait?>> 
>> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
>>> Try enabling logging with:
>>> 
>>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
>>> 
>>> And the try the attach. It might be a lldb-server issue?
>>> 
 On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev >>> d...@lists.llvm.org

[lldb-dev] LLVM-C

[Giannis Zamanis via lldb-dev]

Hello,

I am writing a compiler using llvm-c api and  i want to have
variable-length arrays as arguments in functions.I have tried using
zero-sized type array as the typical parameter in the function definition,
but when i call the function with a normal-sized array as argument it
throws error due to mismatch in types. I can't find a workaround for this.
Example:
define i32 @ha([0 x i32]*)
%funccall = call i32 @ha([20 x i32]* %only_l)

Thank you for your time,
John
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev