[lldb-dev] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

[Pavel Labath via lldb-dev]

Moving the discussion to lldb-dev.

On 21 October 2016 at 18:55, Dmitry Mikulin  wrote:
> Thanks Pavel! I'll start working on it. Do you know when lldb-server Linux 
> changes were committed? I want to use those patches as a template, but it's 
> hard to locate them digging through thousands of commit log entries...

The original remote debug support for linux came as a long series of
patches in February 2015, between r227909  and r227933. However, it
has gone through quite a bit of rewrite since then, so I'd be wary of
using it as an inspiration. I think you'd be better off using the
current state of the linux support instead. You can also find r240543
interesting as well, which removes the old local debug path. That can
be useful to figure out how to setup lldb to launch lldb-server for
debugging (generally, it boils down to returning "true" from
PlatformXXX::CanDebugProcess()).

On 21 October 2016 at 20:12, Kamil Rytarowski  wrote:
> krytarowski added a comment.
>
> I just scrolled the discussion so it's not really started. Thanks.
>
> My plan is to work on ptrace(2) for about a month.
>
> Then I will take the FreeBSD code as it is and port to NetBSD trying to make 
> it functional. This is difficult part as there is everywhere OS specific 
> interfaces and behavior. I hope to get it to some usable point after a month.
>
> Then ,I will start working on remote debugging, as my previous patch for 
> process tracing (it was buggy) was rejected without this property. I planned 
> to merge my previous work with master as I was forced to keep catching up 
> after the project changes and it was time expensive, and move my focus on 
> proper platform support.

It's not my place to tell you how to work, but I'd recommend a
different approach to this. If you base your work on the current
FreeBSD in-process plugin, then when you get around to actually
implementing remote support, you will find that you will have to
rewrite most of what you have already done to work with lldb-server,
as it uses completely different class hierarchies and everything. I'd
recommend starting with lldb-server right away. It's going to be a bit
more work as (I assume) freebsd implementation is closer to what you
need than linux, but I think it will save you time in the long run. I
can help you with factoring out any linux-specific code that you
encounter.

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

Re: [lldb-dev] Returning multiple values in Python API function

[Pavel Labath via lldb-dev]

On 22 October 2016 at 00:17, Francis Ricci via lldb-dev
 wrote:
> On Fri, Oct 21, 2016 at 3:30 PM, Greg Clayton  wrote:
>>
>>> On Oct 21, 2016, at 1:03 PM, Francis Ricci via lldb-dev 
>>>  wrote:
>>>
>>> Hi all,
>>>
>>> I'm looking to add Platform::LaunchGDBServer() to the SBPlatform API,
>>> but it requires two return values - an lldb::pid_t and a string url.
>>> Internally, we just pass by reference, but we can't do that in the
>>> API. Any suggestions on how to do this, since we can't pass primitives
>>> by reference from Python?
>>>
>>> My current thinking was to use the pid_t as the return value, and then
>>> figure out a way to communicate the string information as an "out"
>>> function parameter. Ideas there included using an SBStream&, as the
>>> GetDescription() functions do, but that doesn't seem optimal.
>>>
>>> In standard Python, we'd just use a tuple return value, but I don't
>>> see any way to do that using the swig interface.
>>>
>>> The reasoning behind adding this API function is to prevent the
>>> platform-mode GdbRemote tests from launching the gdbserver using an
>>> 'A' packet instead of the standard 'qLaunchGDBServer' packet.
>>
>> I am still unclear as to why you want this? An lldb-server that is launched 
>> in platform mode shouldn't use the 'A' packet at all.
>
> Right. The problem is that our test suite (specifically the
> lldb-server tests) uses the 'A' packet to spawn the inferior for
> lldb-server's which are launched in platform mode.
>
>> Can you elaborate on why you need this more? Why do we need to prevent it 
>> from using an 'A' packet in the first place? What is leading to this 
>> happening?
>
> gdbremote_testcase.py, in launch_debug_monitor, calls
> self.spawnSubprocess() on the lldb-server exe.
>
> This in turn calls _RemoteProcess.launch() in lldbtest.py, which calls
> lldb.remote_platform.Launch(), which will use the 'A' packet, with the
> path to the lldb-server.
>
> I think this is broken, and the qLaunchGDBServer packet should be used
> instead. The problem is that there currently isn't a good way to use
> this packet from the Python API.
>
> It is somewhat odd to me that the platform-mode lldb-server even
> accepts the 'A' packet, but it appears to, given that the `Handle_A`
> method is contained in `GDBRemoteCommunicationServerCommon` and not
> `GDBRemoteCommunicationServerLLGS`.

Yes, but then it calls into virtual
GDBRemoteCommunicationServerCommon::LaunchProcess, which is
implemented differently in the platform and gdb-remote instance.

What is the actual problem you are trying to solve here? It it's just
the fact that we use the A packet to launch non-debuggable processes,
then I think you should just change which packet is used by
PlatformRemoteGDBServer::LaunchProcess. I don't see the need for a new
API.

Is there any issue that arises from launching the server instance via
A packet instead of qLaunchGDBServer? The way I understand these
tests, they're supposed to test the capabilities of LLGS in isolation.
The way you start the LLGS instance is peripheral. In fact it may be
even better to isolate the launching process from whatever magic
qLaunchGDBServer is doing. Also, giving the tests more control over
how you start the LLGS instance means you can test starting it in a
way that it would not be started by qLaunchGDBServer. (e.g. I don't
think you can convince that packet to run LLGS in the
"inferior-supplied-on-the-command-line mode" (lldb-server g --
./a.out), which is still a valid mode of using the tool and needs to
be tested).

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

Re: [lldb-dev] Returning multiple values in Python API function

[Greg Clayton via lldb-dev]

The 'A' packet is for launching a process that is to be debugged only, it isn't 
supposed to be used just to launch a process that should just run. If the 'A' 
packet is being used in lldb-server in platform mode, then it is just wrong. We 
should probably pull it out of the server, or return an error if it gets used 
in platform mode.

Greg

> On Oct 24, 2016, at 3:48 AM, Pavel Labath  wrote:
> 
> On 22 October 2016 at 00:17, Francis Ricci via lldb-dev
>  wrote:
>> On Fri, Oct 21, 2016 at 3:30 PM, Greg Clayton  wrote:
>>> 
 On Oct 21, 2016, at 1:03 PM, Francis Ricci via lldb-dev 
  wrote:
 
 Hi all,
 
 I'm looking to add Platform::LaunchGDBServer() to the SBPlatform API,
 but it requires two return values - an lldb::pid_t and a string url.
 Internally, we just pass by reference, but we can't do that in the
 API. Any suggestions on how to do this, since we can't pass primitives
 by reference from Python?
 
 My current thinking was to use the pid_t as the return value, and then
 figure out a way to communicate the string information as an "out"
 function parameter. Ideas there included using an SBStream&, as the
 GetDescription() functions do, but that doesn't seem optimal.
 
 In standard Python, we'd just use a tuple return value, but I don't
 see any way to do that using the swig interface.
 
 The reasoning behind adding this API function is to prevent the
 platform-mode GdbRemote tests from launching the gdbserver using an
 'A' packet instead of the standard 'qLaunchGDBServer' packet.
>>> 
>>> I am still unclear as to why you want this? An lldb-server that is launched 
>>> in platform mode shouldn't use the 'A' packet at all.
>> 
>> Right. The problem is that our test suite (specifically the
>> lldb-server tests) uses the 'A' packet to spawn the inferior for
>> lldb-server's which are launched in platform mode.
>> 
>>> Can you elaborate on why you need this more? Why do we need to prevent it 
>>> from using an 'A' packet in the first place? What is leading to this 
>>> happening?
>> 
>> gdbremote_testcase.py, in launch_debug_monitor, calls
>> self.spawnSubprocess() on the lldb-server exe.
>> 
>> This in turn calls _RemoteProcess.launch() in lldbtest.py, which calls
>> lldb.remote_platform.Launch(), which will use the 'A' packet, with the
>> path to the lldb-server.
>> 
>> I think this is broken, and the qLaunchGDBServer packet should be used
>> instead. The problem is that there currently isn't a good way to use
>> this packet from the Python API.
>> 
>> It is somewhat odd to me that the platform-mode lldb-server even
>> accepts the 'A' packet, but it appears to, given that the `Handle_A`
>> method is contained in `GDBRemoteCommunicationServerCommon` and not
>> `GDBRemoteCommunicationServerLLGS`.
> 
> Yes, but then it calls into virtual
> GDBRemoteCommunicationServerCommon::LaunchProcess, which is
> implemented differently in the platform and gdb-remote instance.
> 
> What is the actual problem you are trying to solve here? It it's just
> the fact that we use the A packet to launch non-debuggable processes,
> then I think you should just change which packet is used by
> PlatformRemoteGDBServer::LaunchProcess. I don't see the need for a new
> API.
> 
> Is there any issue that arises from launching the server instance via
> A packet instead of qLaunchGDBServer? The way I understand these
> tests, they're supposed to test the capabilities of LLGS in isolation.
> The way you start the LLGS instance is peripheral. In fact it may be
> even better to isolate the launching process from whatever magic
> qLaunchGDBServer is doing. Also, giving the tests more control over
> how you start the LLGS instance means you can test starting it in a
> way that it would not be started by qLaunchGDBServer. (e.g. I don't
> think you can convince that packet to run LLGS in the
> "inferior-supplied-on-the-command-line mode" (lldb-server g --
> ./a.out), which is still a valid mode of using the tool and needs to
> be tested).
> 
> pl

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

Re: [lldb-dev] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

[Ed Maste via lldb-dev]

On 24 October 2016 at 06:26, Pavel Labath  wrote:
>
> It's not my place to tell you how to work, but I'd recommend a
> different approach to this. If you base your work on the current
> FreeBSD in-process plugin, then when you get around to actually
> implementing remote support, you will find that you will have to
> rewrite most of what you have already done to work with lldb-server,
> as it uses completely different class hierarchies and everything. I'd
> recommend starting with lldb-server right away. It's going to be a bit
> more work as (I assume) freebsd implementation is closer to what you
> need than linux, but I think it will save you time in the long run. I
> can help you with factoring out any linux-specific code that you
> encounter.

I definitely second the approach Pavel suggests here, and am happy to
work with others on refactoring the Linux lldb-server so that we can
get it to support both FreeBSD and NetBSD at the same time.

A direct port of the current FreeBSD support probably would result in
a basic level of support running sooner, but that work would be
largely thrown away in a future migration to lldb-server.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

[Kamil Rytarowski via lldb-dev]

On 24.10.2016 20:38, Ed Maste wrote:
> On 24 October 2016 at 06:26, Pavel Labath  wrote:
>>
>> It's not my place to tell you how to work, but I'd recommend a
>> different approach to this. If you base your work on the current
>> FreeBSD in-process plugin, then when you get around to actually
>> implementing remote support, you will find that you will have to
>> rewrite most of what you have already done to work with lldb-server,
>> as it uses completely different class hierarchies and everything. I'd
>> recommend starting with lldb-server right away. It's going to be a bit
>> more work as (I assume) freebsd implementation is closer to what you
>> need than linux, but I think it will save you time in the long run. I
>> can help you with factoring out any linux-specific code that you
>> encounter.
> 
> I definitely second the approach Pavel suggests here, and am happy to
> work with others on refactoring the Linux lldb-server so that we can
> get it to support both FreeBSD and NetBSD at the same time.
> 
> A direct port of the current FreeBSD support probably would result in
> a basic level of support running sooner, but that work would be
> largely thrown away in a future migration to lldb-server.
> 

I will take your recommended path as it will lead to the same goal.

I will try to shorten my initial work on ptrace(2) leaving additional
features+tests for later and jump to lldb-server as soon as possible.

For start, before switching to process plugin stage is to extend NetBSD
ptrace(2) with the following features:

 - PT_LWPINFO extend struct ptrace_lwpinfo with additional fields used
in LLDB in the current FreeBSD process code (pl_flags, pl_child_pid,
pl_siginfo),

 - PT_GETNUMLWPS - number of kernel threads associated with the traced
process,

 - PT_GETLWPLIST - get the current thread list,

 - PT_SUSPEND - suspend the specified thread,

 - PT_RESUME - resume the specified thread.

I need to add basic tests for new ptrace(2) calls in our automated test
infrastructure in order to get this code accepted.

I will reschedule debug registers and additional ptrace(2) calls for the
end, if time will permit.

I will also add support in LLDB for handling NetBSD Real-Time signals
(SIGRTMIN..SIGRTMAX) as it was already implemented during the latest
GSoC for NetBSD (thanks Google!).

I might need some guidance from LLDB developers (I prefer via IRC and
the dedicated LLDB channel) and maybe proof reading of patches and
debugging issues. I consider that the difficult part is not adapting
FreBSD or Linux specific implementation for NetBSD, but taking
everything to work.

My ultimate deadline for the overall LLDB work is February 28th, 2017 -
as I'm switching to Swift port for NetBSD *.



This work is sponsored by The NetBSD Foundation. If you like it, please
consider supporting it by making a donation.

* http://blog.netbsd.org/tnf/entry/funded_contract_2016_2017



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

[Saleem Abdulrasool via lldb-dev]

On Mon, Oct 24, 2016 at 11:38 AM, Ed Maste via lldb-commits <
lldb-comm...@lists.llvm.org> wrote:

> On 24 October 2016 at 06:26, Pavel Labath  wrote:
> >
> > It's not my place to tell you how to work, but I'd recommend a
> > different approach to this. If you base your work on the current
> > FreeBSD in-process plugin, then when you get around to actually
> > implementing remote support, you will find that you will have to
> > rewrite most of what you have already done to work with lldb-server,
> > as it uses completely different class hierarchies and everything. I'd
> > recommend starting with lldb-server right away. It's going to be a bit
> > more work as (I assume) freebsd implementation is closer to what you
> > need than linux, but I think it will save you time in the long run. I
> > can help you with factoring out any linux-specific code that you
> > encounter.
>
> I definitely second the approach Pavel suggests here, and am happy to
> work with others on refactoring the Linux lldb-server so that we can
> get it to support both FreeBSD and NetBSD at the same time.
>
> A direct port of the current FreeBSD support probably would result in
> a basic level of support running sooner, but that work would be
> largely thrown away in a future migration to lldb-server.
>

Just to throw out another option: DS2 (DebugServer2) at
http://github.com/facebook/ds2 may be another option to getting remote
debugging working.  It already has basic BSD support, so adding NetBSD
support shouldn't be too difficult.


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

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] LLGS for Free/NetBSD

[Kamil Rytarowski via lldb-dev]

On 25.10.2016 01:43, Saleem Abdulrasool via lldb-dev wrote:
> On Mon, Oct 24, 2016 at 11:38 AM, Ed Maste via lldb-commits
> mailto:lldb-comm...@lists.llvm.org>> wrote:
> 
> On 24 October 2016 at 06:26, Pavel Labath  > wrote:
> >
> > It's not my place to tell you how to work, but I'd recommend a
> > different approach to this. If you base your work on the current
> > FreeBSD in-process plugin, then when you get around to actually
> > implementing remote support, you will find that you will have to
> > rewrite most of what you have already done to work with lldb-server,
> > as it uses completely different class hierarchies and everything. I'd
> > recommend starting with lldb-server right away. It's going to be a bit
> > more work as (I assume) freebsd implementation is closer to what you
> > need than linux, but I think it will save you time in the long run. I
> > can help you with factoring out any linux-specific code that you
> > encounter.
> 
> I definitely second the approach Pavel suggests here, and am happy to
> work with others on refactoring the Linux lldb-server so that we can
> get it to support both FreeBSD and NetBSD at the same time.
> 
> A direct port of the current FreeBSD support probably would result in
> a basic level of support running sooner, but that work would be
> largely thrown away in a future migration to lldb-server.
> 
> 
> Just to throw out another option: DS2 (DebugServer2) at
> http://github.com/facebook/ds2 may be another option to getting remote
> debugging working.  It already has basic BSD support, so adding NetBSD
> support shouldn't be too difficult.
>  


It's an interesting program, but for now I would leave it for later as
it's out of LLDB.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev