Re: [lldb-dev] Where "thread until " should set breakpoints?

[Ramana via lldb-dev]

On Thu, Aug 2, 2018 at 3:32 AM, Jim Ingham  wrote:

>
>
> > On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > On the subject line, the ToT lldb (see code around
> CommandObjectThread.cpp:1230) sets the breakpoint on the first exact
> matching line of 'line-number' or the closest line number > 'line-number'
> i.e. the best match.
> >
> > And along with that, starting from the above exact/best matching line
> number index in the line table, the breakpoints are also being set on every
> other line number available in the line table in the current function
> scope. This latter part, I believe, is incorrect.
>
> Why do you think this is incorrect?
>
> The requirements for "thread until " are:
>
> a) If any code contributed by  is executed before leaving the
> function, stop
> b) If you end up leaving the function w/o triggering (a), then stop
>

Understood and no concerns on this.


> Correct or incorrect should be determined by how well the implementation
> fits those requirements.
>
> There isn't currently a reliable indication from the debug information or
> line tables that "line N will always be entered starting with the block at
> 0x123".  So you can't tell without doing control flow analysis, which if
> any of the separate entries in the line table for the same line will get
> hit in the course of executing the function.  So the safest thing to do is
> to set breakpoints on them all.


>From the above, I understand that we have to do this when the debug line
table has more than one entry for a particular source line. And this is
what I referred to as "machine code for one single source line is scattered
across" in my previous mail. Thanks for sharing why we had to do that.

Besides setting a few more breakpoints - which should be pretty cheap - I
> don't see much downside to the way it is currently implemented.
>
> Anyway, why did this bother you?
>
> Jim
>

However, I am concerned about the below 'thread until' behaviour. For the
attached test case (kernels.cpp - OpenCL code), following is the debug line
table generated by the compiler.

File nameLine numberStarting address
./kernels.cpp:[++]
kernels.cpp9   0xacc74d00
kernels.cpp   12
0xacc74d00
kernels.cpp   14  0xacc74d40
kernels.cpp   13  0xacc74dc0
kernels.cpp   14  0xacc74e00
kernels.cpp   25  0xacc74e80
kernels.cpp   25  0xacc74ec0
kernels.cpp   26  0xacc74f00
kernels.cpp   26  0xacc74f40
kernels.cpp   26  0xacc74f80
kernels.cpp   17  0xacc74fc0
kernels.cpp   18  0xacc75000
kernels.cpp   18  0xacc75040
kernels.cpp   19  0xacc75080
kernels.cpp   27  0xacc750c0
kernels.cpp   27  0xacc75140
kernels.cpp   28  0xacc75180
kernels.cpp   28  0xacc751c0
kernels.cpp   29  0xacc75200
kernels.cpp   29  0xacc75240
kernels.cpp   30  0xacc75280

With the ToT lldb, when I am at line 12 (0xacc74d00), if I say 'thread
until 18', the lldb log gives me the following w.r.t breakpoints.

GDBRemoteCommunicationClient::SendGDBStoppointTypePacket() add at addr =
0xacc75280
Thread::PushPlan(0x0xa48b38f0): "Stepping from address 0xacc74d00 until we
reach one of:
0xacc75000 (bp: -4)
0xacc75040 (bp: -5)
0xacc75080 (bp: -6)
0xacc750c0 (bp: -7)
0xacc75140 (bp: -8)
0xacc75180 (bp: -9)
0xacc751c0 (bp: -10)
0xacc75200 (bp: -11)
0xacc75240 (bp: -12)
0xacc75280 (bp: -13)

Setting two breakpoints for line number 18 i.e. at 0xacc75000 and
0xacc75040 is understandable from your above reasoning and since we are
anyway setting a breakpoint at the end of the function (line 30 -
0xacc75280), is it necessary to set the breakpoints on line numbers 19, 27,
28, 29 as well i.e. at 0xacc75080 (line 19), 0xacc750c0 (line 27),
0xacc75140 (line 27), 0xacc75180 (line 28), 0xacc751c0 (line 28),
0xacc75200 (line 29), 0xacc75240 (line 29)?

The latter part i.e. setting breakpoints on 19, 27, 28, 29 as well is what
I think is incorrect. Am I missing s

[lldb-dev] Where "thread until " should set breakpoints?

[Ramana via lldb-dev]

On the subject line, the ToT lldb (see code around
CommandObjectThread.cpp:1230) sets the breakpoint on the first exact
matching line of 'line-number' or the closest line number > 'line-number'
i.e. the best match.

And along with that, starting from the above exact/best matching line
number index in the line table, the breakpoints are also being set on every
other line number available in the line table in the current function
scope. This latter part, I believe, is incorrect.

What, I think, should happen is we just set only one breakpoint on the
first exact/best match for the given 'line-number' and another on the
return address from the current frame. And this leaves us with one special
case where the machine code for one single source line is scattered across
(aka scheduled across) and I do not know what is the expected behaviour in
this case.

If I my above understanding is correct and after discussing here on how to
handle the scattered code scenario, I will submit a patch.

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

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

[Ramana via lldb-dev]

On Thu, Mar 29, 2018 at 11:17 PM, Jim Ingham <jing...@apple.com> wrote:

> The breakpoints aren't a structural problem.  If you can figure out a
> non-code modifying way to handle breakpoints, that would be a very surgical
> change.  And as Fred points out, out of place execution in the target would
> be really handy for other things, like offloading breakpoint conditions
> into the target, and only stopping if the condition is true.  So this is a
> well motivated project.
>
> And our model for handling both expression evaluation and execution
> control are already thread-centric.  It would be pretty straight-forward to
> treat "still running" threads the same way as threads with no interesting
> stop reasons, for instance.
>
> I think the real difficulty will come at the higher layers.  First off, we
> gate a lot of Command & SB API operations on "is the process running" and
> that will have to get much more fine-grained.  Figuring out a good model
> for this will be important.
>
> Then you're going to have to figure out what exactly to do when somebody
> is in the middle of say running a long expression on thread A when thread B
> stops.  What's a useful way to present this information?  If lldb is
> sharing the terminal with the process, you can't just dump output in the
> middle of command output, but you don't want to delay too long...
>
> Also, the IOHandlers are currently a stack, but that model won't work when
> the process IOHandler is going to have to be live (at least the output part
> of it) while the CommandInterpreter IOHandler is also live.  That's going
> to take reworking.
>
> On the event and operations side, I think the fact that we have the
> separation between the private and public states will make this a lot
> easier.  We can use the event transition from private to public state to
> serialize the activity that's going on under the covers so that it appears
> coherent to the user.  The fact that lldb goes through separate channels
> for process I/O and command I/O and we very seldom just dump stuff to
> stdout will also make solving the problem of competing demands for the
> user's attention more possible.
>

Thanks Jim for the elaborate view on the non-stop mode support.

BTW my understanding on public vs private states is that the public state
is as known by the user and all the process state changes will be first
tracked with private state which then will be made public, i.e. public
state will be updated, should the user need to know about that process
state change. Is there anything else I am missing on public vs private
states?


> And I think we can't do any of this till we have a robust "ProcessMock"
> plugin that we can use to emulate end-to-end through the debugger all the
> corner cases that non-stop debugging will bring up.  Otherwise there will
> be no way to reliably test any of this stuff, and it won't ever be stable.
>
> I don't think any of this will be impossible, but it's going to be a lot
> of work.
>
> Jim
>
>
> > On Mar 29, 2018, at 9:27 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> >
> >> On Mar 29, 2018, at 9:10 AM, Frédéric Riss <fr...@apple.com> wrote:
> >>
> >>
> >>
> >>> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>
> >>>
> >>>
> >>>> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> It appears that the lldb-server, as of v5.0, did not implement the
> GDB RSPs non-stop mode (https://sourceware.org/gdb/
> onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop). Am I wrong?
> >>>>
> >>>> If the support is actually not there, what needs to be changed to
> enable the same in lldb-server?
> >>>
> >>> As Pavel said, adding support into lldb-server will be easy. Adding
> support to LLDB will be harder. One downside of enabling this mode will be
> a performance loss in the GDB remote packet transfer. Why? IIRC this mode
> requires a read thread where one thread is always reading packets and
> putting them into a packet buffer. Threads that want to send a packet an
> get a reply must not send the packet then use a condition variable + mutex
> to wait for the response. This threading overhead really slows down the
> packet transfers. Currently we have a mutex on the GDB remote communication
> where each thread that needs to send a packet will take the mutex and then
> send the packet and wait for the response on the same t

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

[Ramana via lldb-dev]

On Thu, Mar 29, 2018 at 11:58 PM, Greg Clayton <clayb...@gmail.com> wrote:

>
>
> On Mar 29, 2018, at 11:07 AM, Jim Ingham <jing...@apple.com> wrote:
>
>
>
> On Mar 29, 2018, at 10:40 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> On Mar 29, 2018, at 10:36 AM, Frédéric Riss <fr...@apple.com> wrote:
>
>
>
> On Mar 29, 2018, at 9:27 AM, Greg Clayton <clayb...@gmail.com> wrote:
>
>
>
> On Mar 29, 2018, at 9:10 AM, Frédéric Riss <fr...@apple.com> wrote:
>
>
>
> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org>
> wrote:
>
> Hi,
>
> It appears that the lldb-server, as of v5.0, did not implement the GDB
> RSPs non-stop mode (https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_
> 002dStop.html#Remote-Non_002dStop). Am I wrong?
>
> If the support is actually not there, what needs to be changed to enable
> the same in lldb-server?
>
>
> As Pavel said, adding support into lldb-server will be easy. Adding
> support to LLDB will be harder. One downside of enabling this mode will be
> a performance loss in the GDB remote packet transfer. Why? IIRC this mode
> requires a read thread where one thread is always reading packets and
> putting them into a packet buffer. Threads that want to send a packet an
> get a reply must not send the packet then use a condition variable + mutex
> to wait for the response. This threading overhead really slows down the
> packet transfers. Currently we have a mutex on the GDB remote communication
> where each thread that needs to send a packet will take the mutex and then
> send the packet and wait for the response on the same thread. I know the
> performance differences are large on MacOS, not sure how they are on other
> systems. If you do end up enabling this, please run the "process plugin
> packet speed-test" command which is available only when debugging with
> ProcessGDBRemote. It will send an receive various packets of various sizes
> and report speed statistics back to you.
>
>
> Also, in lldb at least I see some code relevant to non-stop mode, but is
> non-stop mode fully implemented in lldb or there is only partial support?
>
>
> Everything in LLDB right now assumes a process centric debugging model
> where when one thread stops all threads are stopped. There will be quite a
> large amount of changes needed for a thread centric model. The biggest
> issue I know about is breakpoints. Any time you need to step over a
> breakpoint, you must stop all threads, disable the breakpoint, single step
> the thread and re-enable the breakpoint, then start all threads again. So
> even the thread centric model would need to start and stop all threads many
> times.
>
>
> If we work on this, that’s not the way we should approach breakpoints in
> non-stop mode (and it’s not how GDB does it). I’m not sure why Ramana is
> interested in it, but I think one of the main motivations to add it to GDB
> was systems where stopping all some threads for even a small amount of time
> would just break things. You want a way to step over breakpoints without
> disrupting the other threads.
>
> Instead of removing the breakpoint, you can just teach the debugger to
> execute the code that has been patched in a different context. You can
> either move the code someplace else and execute it there or emulate it.
> Sometimes you’ll need to patch it if it is PC-relative. IIRC, GDB calls
> this displaced stepping. It’s relatively simple and works great.
>
>
> This indeed is one of the changes we would need to do for non-stop mode.
> We have the EmulateInstruction class in LLDB that is designed just for this
> kind of thing. You can give the emulator function a read/write memory and
> read/write register callbacks and a baton and it can execute the
> instruction and read/write memory and regisrters as needed through the
> context. It would be very easy to have the read register callback know to
> take the PC of the original instruction and return it if the PC is
> requested.
>
> We always got push back in the past about adding full instruction
> emulation support as Chris Lattner wanted it to exist in LLVM in the
> tablegen tables, but no one ever got around to doing that part. So we added
> prologue instruction parsing and any instructions that can modify the PC
> (for single stepping) to the supported emulated instructions.
>
> So yes, emulating instructions without removing them from the code is one
> of the things required for this feature. Not impossible, just very time
> consuming to be able t

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

[Ramana via lldb-dev]

On Thu, Mar 29, 2018 at 11:37 PM, Jim Ingham <jing...@apple.com> wrote:

>
>
> > On Mar 29, 2018, at 10:40 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> >
> >> On Mar 29, 2018, at 10:36 AM, Frédéric Riss <fr...@apple.com> wrote:
> >>
> >>
> >>
> >>> On Mar 29, 2018, at 9:27 AM, Greg Clayton <clayb...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>> On Mar 29, 2018, at 9:10 AM, Frédéric Riss <fr...@apple.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> It appears that the lldb-server, as of v5.0, did not implement the
> GDB RSPs non-stop mode (https://sourceware.org/gdb/
> onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop). Am I wrong?
> >>>>>>
> >>>>>> If the support is actually not there, what needs to be changed to
> enable the same in lldb-server?
> >>>>>
> >>>>> As Pavel said, adding support into lldb-server will be easy. Adding
> support to LLDB will be harder. One downside of enabling this mode will be
> a performance loss in the GDB remote packet transfer. Why? IIRC this mode
> requires a read thread where one thread is always reading packets and
> putting them into a packet buffer. Threads that want to send a packet an
> get a reply must not send the packet then use a condition variable + mutex
> to wait for the response. This threading overhead really slows down the
> packet transfers. Currently we have a mutex on the GDB remote communication
> where each thread that needs to send a packet will take the mutex and then
> send the packet and wait for the response on the same thread. I know the
> performance differences are large on MacOS, not sure how they are on other
> systems. If you do end up enabling this, please run the "process plugin
> packet speed-test" command which is available only when debugging with
> ProcessGDBRemote. It will send an receive various packets of various sizes
> and report speed statistics back to you.
> >>>>>>
> >>>>>> Also, in lldb at least I see some code relevant to non-stop mode,
> but is non-stop mode fully implemented in lldb or there is only partial
> support?
> >>>>>
> >>>>> Everything in LLDB right now assumes a process centric debugging
> model where when one thread stops all threads are stopped. There will be
> quite a large amount of changes needed for a thread centric model. The
> biggest issue I know about is breakpoints. Any time you need to step over a
> breakpoint, you must stop all threads, disable the breakpoint, single step
> the thread and re-enable the breakpoint, then start all threads again. So
> even the thread centric model would need to start and stop all threads many
> times.
> >>>>
> >>>> If we work on this, that’s not the way we should approach breakpoints
> in non-stop mode (and it’s not how GDB does it). I’m not sure why Ramana is
> interested in it, but I think one of the main motivations to add it to GDB
> was systems where stopping all some threads for even a small amount of time
> would just break things. You want a way to step over breakpoints without
> disrupting the other threads.
> >>>>
> >>>> Instead of removing the breakpoint, you can just teach the debugger
> to execute the code that has been patched in a different context. You can
> either move the code someplace else and execute it there or emulate it.
> Sometimes you’ll need to patch it if it is PC-relative. IIRC, GDB calls
> this displaced stepping. It’s relatively simple and works great.
> >>>
> >>> This indeed is one of the changes we would need to do for non-stop
> mode. We have the EmulateInstruction class in LLDB that is designed just
> for this kind of thing. You can give the emulator function a read/write
> memory and read/write register callbacks and a baton and it can execute the
> instruction and read/write memory and regisrters as needed through the
> context. It would be very easy to have the read register callback know to
> take the PC of the original instruction and return it if the PC is
> requested.
> >>>
&

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

[Ramana via lldb-dev]

On Thu, Mar 29, 2018 at 11:17 PM, Jim Ingham <jing...@apple.com> wrote:

> The breakpoints aren't a structural problem.  If you can figure out a
> non-code modifying way to handle breakpoints, that would be a very surgical
> change.  And as Fred points out, out of place execution in the target would
> be really handy for other things, like offloading breakpoint conditions
> into the target, and only stopping if the condition is true.  So this is a
> well motivated project.
>
> And our model for handling both expression evaluation and execution
> control are already thread-centric.  It would be pretty straight-forward to
> treat "still running" threads the same way as threads with no interesting
> stop reasons, for instance.
>
> I think the real difficulty will come at the higher layers.  First off, we
> gate a lot of Command & SB API operations on "is the process running" and
> that will have to get much more fine-grained.  Figuring out a good model
> for this will be important.
>
> Then you're going to have to figure out what exactly to do when somebody
> is in the middle of say running a long expression on thread A when thread B
> stops.  What's a useful way to present this information?  If lldb is
> sharing the terminal with the process, you can't just dump output in the
> middle of command output, but you don't want to delay too long...
>
> Also, the IOHandlers are currently a stack, but that model won't work when
> the process IOHandler is going to have to be live (at least the output part
> of it) while the CommandInterpreter IOHandler is also live.  That's going
> to take reworking.
>
> On the event and operations side, I think the fact that we have the
> separation between the private and public states will make this a lot
> easier.  We can use the event transition from private to public state to
> serialize the activity that's going on under the covers so that it appears
> coherent to the user.  The fact that lldb goes through separate channels
> for process I/O and command I/O and we very seldom just dump stuff to
> stdout will also make solving the problem of competing demands for the
> user's attention more possible.
>
> And I think we can't do any of this till we have a robust "ProcessMock"
> plugin that we can use to emulate end-to-end through the debugger all the
> corner cases that non-stop debugging will bring up.  Otherwise there will
> be no way to reliably test any of this stuff, and it won't ever be stable.
>
> I don't think any of this will be impossible, but it's going to be a lot
> of work.
>
> Jim
>

Thanks Jim for the comments. Being new to lldb, that's a lot of food for
thought for me. Will get back here after doing some homework on what all
this means.


>
>
> > On Mar 29, 2018, at 9:27 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> >
> >> On Mar 29, 2018, at 9:10 AM, Frédéric Riss <fr...@apple.com> wrote:
> >>
> >>
> >>
> >>> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>
> >>>
> >>>
> >>>> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> It appears that the lldb-server, as of v5.0, did not implement the
> GDB RSPs non-stop mode (https://sourceware.org/gdb/
> onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop). Am I wrong?
> >>>>
> >>>> If the support is actually not there, what needs to be changed to
> enable the same in lldb-server?
> >>>
> >>> As Pavel said, adding support into lldb-server will be easy. Adding
> support to LLDB will be harder. One downside of enabling this mode will be
> a performance loss in the GDB remote packet transfer. Why? IIRC this mode
> requires a read thread where one thread is always reading packets and
> putting them into a packet buffer. Threads that want to send a packet an
> get a reply must not send the packet then use a condition variable + mutex
> to wait for the response. This threading overhead really slows down the
> packet transfers. Currently we have a mutex on the GDB remote communication
> where each thread that needs to send a packet will take the mutex and then
> send the packet and wait for the response on the same thread. I know the
> performance differences are large on MacOS, not sure how they are on other
> systems. If you do end up enabling this, please run the "process plugin
> packet speed-test" command which is available only when debugging with
> ProcessGDBRem

Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

[Ramana via lldb-dev]

On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton <clayb...@gmail.com> wrote:

>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org>
> wrote:
>
> Hi,
>
> It appears that the lldb-server, as of v5.0, did not implement the GDB
> RSPs non-stop mode (https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_
> 002dStop.html#Remote-Non_002dStop). Am I wrong?
>
> If the support is actually not there, what needs to be changed to enable
> the same in lldb-server?
>
>
> As Pavel said, adding support into lldb-server will be easy. Adding
> support to LLDB will be harder. One downside of enabling this mode will be
> a performance loss in the GDB remote packet transfer. Why? IIRC this mode
> requires a read thread where one thread is always reading packets and
> putting them into a packet buffer. Threads that want to send a packet an
> get a reply must not send the packet then use a condition variable + mutex
> to wait for the response. This threading overhead really slows down the
> packet transfers. Currently we have a mutex on the GDB remote communication
> where each thread that needs to send a packet will take the mutex and then
> send the packet and wait for the response on the same thread. I know the
> performance differences are large on MacOS, not sure how they are on other
> systems. If you do end up enabling this, please run the "process plugin
> packet speed-test" command which is available only when debugging with
> ProcessGDBRemote. It will send an receive various packets of various sizes
> and report speed statistics back to you.
>

So, in non-stop mode, though we can have threads running asynchronously
(some running, some stopped), the GDB remote packet transfer will be
synchronous i.e. will get queued? And this is because the packet responses
should be matched appropriately as there typically will be a single
connection to the remote target and hence this queueing cannot be avoided?

>
> Also, in lldb at least I see some code relevant to non-stop mode, but is
> non-stop mode fully implemented in lldb or there is only partial support?
>
>
> Everything in LLDB right now assumes a process centric debugging model
> where when one thread stops all threads are stopped. There will be quite a
> large amount of changes needed for a thread centric model. The biggest
> issue I know about is breakpoints. Any time you need to step over a
> breakpoint, you must stop all threads, disable the breakpoint, single step
> the thread and re-enable the breakpoint, then start all threads again. So
> even the thread centric model would need to start and stop all threads many
> times.
>

Greg, what if, while stepping over a breakpoint, the remaining threads can
still continue and no need to disable the breakpoint? What else do I need
to take care of?


>
> Be sure to speak with myself, Jim Ingham and Pavel in depth before
> undertaking this task as there will be many changes required.
>
> Greg
>
>
> Thanks,
> Ramana
>
>
> ___
> 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] GDB RSPs non-stop mode capability in v5.0

[Ramana via lldb-dev]

> Be sure to speak with myself, Jim Ingham and Pavel in depth before
undertaking this task as there will be many changes required.

Definitely.

Thank you all for the responses. Will get back after digesting all the
responses here.

Regards,
Ramana

On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton <clayb...@gmail.com> wrote:

>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org>
> wrote:
>
> Hi,
>
> It appears that the lldb-server, as of v5.0, did not implement the GDB
> RSPs non-stop mode (https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_
> 002dStop.html#Remote-Non_002dStop). Am I wrong?
>
> If the support is actually not there, what needs to be changed to enable
> the same in lldb-server?
>
>
> As Pavel said, adding support into lldb-server will be easy. Adding
> support to LLDB will be harder. One downside of enabling this mode will be
> a performance loss in the GDB remote packet transfer. Why? IIRC this mode
> requires a read thread where one thread is always reading packets and
> putting them into a packet buffer. Threads that want to send a packet an
> get a reply must not send the packet then use a condition variable + mutex
> to wait for the response. This threading overhead really slows down the
> packet transfers. Currently we have a mutex on the GDB remote communication
> where each thread that needs to send a packet will take the mutex and then
> send the packet and wait for the response on the same thread. I know the
> performance differences are large on MacOS, not sure how they are on other
> systems. If you do end up enabling this, please run the "process plugin
> packet speed-test" command which is available only when debugging with
> ProcessGDBRemote. It will send an receive various packets of various sizes
> and report speed statistics back to you.
>
>
> Also, in lldb at least I see some code relevant to non-stop mode, but is
> non-stop mode fully implemented in lldb or there is only partial support?
>
>
> Everything in LLDB right now assumes a process centric debugging model
> where when one thread stops all threads are stopped. There will be quite a
> large amount of changes needed for a thread centric model. The biggest
> issue I know about is breakpoints. Any time you need to step over a
> breakpoint, you must stop all threads, disable the breakpoint, single step
> the thread and re-enable the breakpoint, then start all threads again. So
> even the thread centric model would need to start and stop all threads many
> times.
>
> Be sure to speak with myself, Jim Ingham and Pavel in depth before
> undertaking this task as there will be many changes required.
>
> Greg
>
>
> Thanks,
> Ramana
>
>
> ___
> 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] GDB RSPs non-stop mode capability in v5.0

[Ramana via lldb-dev]

> I’m not sure why Ramana is interested in it

Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html is
what I am trying to implement in lldb which has been discussed in little
more details here
http://lists.llvm.org/pipermail/lldb-dev/2017-September/012815.html.

On Thu, Mar 29, 2018 at 9:40 PM, Frédéric Riss <fr...@apple.com> wrote:


> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org>
> wrote:
>
> Hi,
>
> It appears that the lldb-server, as of v5.0, did not implement the GDB
> RSPs non-stop mode (https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_
> 002dStop.html#Remote-Non_002dStop). Am I wrong?
>
> If the support is actually not there, what needs to be changed to enable
> the same in lldb-server?
>
>
> As Pavel said, adding support into lldb-server will be easy. Adding
> support to LLDB will be harder. One downside of enabling this mode will be
> a performance loss in the GDB remote packet transfer. Why? IIRC this mode
> requires a read thread where one thread is always reading packets and
> putting them into a packet buffer. Threads that want to send a packet an
> get a reply must not send the packet then use a condition variable + mutex
> to wait for the response. This threading overhead really slows down the
> packet transfers. Currently we have a mutex on the GDB remote communication
> where each thread that needs to send a packet will take the mutex and then
> send the packet and wait for the response on the same thread. I know the
> performance differences are large on MacOS, not sure how they are on other
> systems. If you do end up enabling this, please run the "process plugin
> packet speed-test" command which is available only when debugging with
> ProcessGDBRemote. It will send an receive various packets of various sizes
> and report speed statistics back to you.
>
>
> Also, in lldb at least I see some code relevant to non-stop mode, but is
> non-stop mode fully implemented in lldb or there is only partial support?
>
>
> Everything in LLDB right now assumes a process centric debugging model
> where when one thread stops all threads are stopped. There will be quite a
> large amount of changes needed for a thread centric model. The biggest
> issue I know about is breakpoints. Any time you need to step over a
> breakpoint, you must stop all threads, disable the breakpoint, single step
> the thread and re-enable the breakpoint, then start all threads again. So
> even the thread centric model would need to start and stop all threads many
> times.
>
>
> If we work on this, that’s not the way we should approach breakpoints in
> non-stop mode (and it’s not how GDB does it). I’m not sure why Ramana is
> interested in it, but I think one of the main motivations to add it to GDB
> was systems where stopping all some threads for even a small amount of time
> would just break things. You want a way to step over breakpoints without
> disrupting the other threads.
>
> Instead of removing the breakpoint, you can just teach the debugger to
> execute the code that has been patched in a different context. You can
> either move the code someplace else and execute it there or emulate it.
> Sometimes you’ll need to patch it if it is PC-relative. IIRC, GDB calls
> this displaced stepping. It’s relatively simple and works great.
>
> I’ve been interested in displaced stepping for different reasons. If we
> had that capability, it would become much easier to patch code. I’d love to
> use this to have breakpoint conditions injected and evaluated without round
> tripping to the debugger when the condition returns false.
>
> Fred
>
> Be sure to speak with myself, Jim Ingham and Pavel in depth before
> undertaking this task as there will be many changes required.
>
> Greg
>
>
> Thanks,
> Ramana
>
>
> ___
> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] did anyone konw LLDB support lldb + openocd to run dotest.py in bare board like ARM or other non-x86 architecture?

[Ramana via lldb-dev]

These sort of issues I have faced in the past and in my case the
reason was I used the incorrect host triple while building LLDB (LLVM
etc).

Example:
   Assuming you are using GCC/G++ compiler to build LLVM+LLDB, I would
set the LLVM_HOST_TRIPLE to the one used in the library path and not
essentially that of the 'Target' in 'gcc -v'.

$ gcc -v

Target: i686-linux-gnu
...
$ ldd /usr/bin/gcc

libc.so.6 => /lib/i386-linux-gnu/libc.so.6
..

Now, I would set LLVM_HOST_TRIPLE to i386-linux-gnu but not i686-linux-gnu.

See if that works for you.

- Ramana

> Hi

> You mean should use “platform select remote-linux” ? I use it but also report 
> error: unable to launch a GDB server on 'debian-armhf.""'

> in-addition, you said gdb-server is “GNU GDB server” or just lldb-server 
> services ?

> Best Regards
> —cuibixiong
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ramana via lldb-dev]

 at 8:46 PM, Greg Clayton <clayb...@gmail.com>
>> >> wrote:
>> >> >>
>> >> >> When supporting a new architecture, our preferred route is to
>> >> >> modify lldb-server (a GDB server binary that supports native
>> >> >> debugging) to support your architecture. Why? Because this gets
>> >> >> you remote debugging for free. If you go this route, then you will
>> >> >> subclass a lldb_private::NativeRegisterContext and that will get
>> >> >> used by lldb-server (along with
>> >> >> lldb_private::NativeProcessProtocol and
>> >> >> lldb_private::NativeThreadProtocol). If you are adding a new
>> >> >> architecture to Linux, then you will likely just need to subclass
>> >> NativeRegisterContext.
>> >> >>
>> >> >> The other way to go is to subclass lldb_private::Process,
>> >> >> lldb_private::Thread and lldb_private::RegisterContext.
>> >> >>
>> >> >> The nice thing about the lldb_private::Native* subclasses is that
>> >> >> you only need to worry about native support. You can use #ifdef
>> >> >> and use system header files, where as the non native route, those
>> >> >> classes need to be able to debug remotely and you can't rely on
>> >> >> system headers (lldb_private::Process, lldb_private::Thread and
>> >> >> lldb_private::RegisterContext) since they can be compiled on any
>> >> >> system for possibly local debugging (if current arch/vendor/os
>> >> >> matches the current system) and remote (if you use lldb-server or
>> >> >> another
>> >> form for RPC).
>> >> >>
>> >> >> I would highly suggest getting going the lldb-server route as then
>> >> >> you can use system header files that contain the definitions of
>> >> >> the registers and you only need to worry about the native architecture.
>> >> >> Linux uses ptrace and has much the the common code filtered out
>> >> >> into correct classes (posix ptrace, linux specifics, and more.
>> >> >>
>> >> >> What architecture and os are you looking to support?
>> >> >>
>> >> >> Greg Clayton
>> >> >>
>> >> >> On Sep 16, 2017, at 6:28 AM, Ramana <ramana.venka...@gmail.com>
>> >> wrote:
>> >> >>
>> >> >> Thank you Greg for the detailed response.
>> >> >>
>> >> >> Can you please also shed some light on the NativeRegisterContext.
>> >> >> When do we need to subclass NativeRegisterContext and (how) are
>> >> >> they related to RegisterContext_> >> >> architectures having RegisterContext_ have sub classed
>> >> >> NativeRegisterContext.
>> >> >>
>> >> >> Regards,
>> >> >> Ramana
>> >> >>
>> >> >> On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton <clayb...@gmail.com>
>> >> wrote:
>> >> >>
>> >> >> Seems like this class was added for testing. RegisterInfoInterface
>> >> >> is a class that creates a common API for getting
>> >> >> lldb_private::RegisterInfo structures.
>> >> >>
>> >> >> A RegisterContext_ class uses one of these to be able to
>> >> >> create a buffer large enough to store all registers defined in the
>> >> >> RegisterInfoInterface and will actually read/write there registers
>> >> >> to/from the debugged process. RegisterContext also caches
>> >> >> registers values so they don't get read multiple times when the
>> >> >> process hasn't resumed. A RegisterContext subclass is needed for
>> >> >> each architecture so we can dynamically tell LLDB what the
>> >> >> registers look like for a given
>> >> architecture.
>> >> >> It also provides abstractions by letting each register define its
>> >> >> registers numbers for Compilers, DWARF, and generic register
>> >> >> numbers like PC, SP, FP, return address, and flags registers. This
>> >> >> allows the generic part of LLDB to say "I need you to give me the
>> >> >> PC register for this thread" and we don't need to know that the 
>> >> >> register is
>> "eip"
>> >> >> on x86, "rip" on x86_64, "r15" on ARM. RegisterContext classes can
>> >> >> also determine how registers are
>> >> >> read/written: one at a time, or "get all general purpose regs" and
>> >> >> "get all FPU regs". So if someone asks a RegisterContext to read
>> >> >> the PC, it might go read all GPR regs and then mark them all as
>> >> >> valid in the register context buffer cache, so if someone
>> >> >> subsequently asks for SP, it will be already cached.
>> >> >>
>> >> >> So RegisterInfoInterface defines a common way that many
>> >> >> RegisterContext classes can inherit from in order to give out the
>> >> >> lldb_private::RegisterInfo (which is required by all subclasses of
>> >> >> RegisterContext) info for a register context, and RegisterContext
>> >> >> is the one that actually will interface with the debugged process
>> >> >> in order to read/write and cache those registers as efficiently as
>> >> >> possible for
>> >> the current program being debugged.
>> >> >>
>> >> >> On Sep 12, 2017, at 10:59 PM, Ramana via lldb-dev
>> >> >> <lldb-dev@lists.llvm.org>
>> >> >> wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> When deriving RegisterContext_, why some platforms
>> >> >> (Arch+OS) are deriving it from lldb_private::RegisterContext while
>> >> >> others are deriving from lldb_private::RegisterInfoInterface or in
>> >> >> other words how to decide on the base class to derive from between
>> >> >> those two and what are the implications?
>> >> >>
>> >> >> Thanks,
>> >> >> Ramana
>> >> >> ___
>> >> >> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ramana via lldb-dev]

If you are adding a new architecture to
>>> Linux, then you will likely just need to subclass NativeRegisterContext.
>>>
>>> The other way to go is to subclass lldb_private::Process,
>>> lldb_private::Thread and lldb_private::RegisterContext.
>>>
>>> The nice thing about the lldb_private::Native* subclasses is that you only
>>> need to worry about native support. You can use #ifdef and use system header
>>> files, where as the non native route, those classes need to be able to debug
>>> remotely and you can't rely on system headers (lldb_private::Process,
>>> lldb_private::Thread and lldb_private::RegisterContext) since they can be
>>> compiled on any system for possibly local debugging (if current
>>> arch/vendor/os matches the current system) and remote (if you use
>>> lldb-server or another form for RPC).
>>>
>>> I would highly suggest getting going the lldb-server route as then you can
>>> use system header files that contain the definitions of the registers and
>>> you only need to worry about the native architecture. Linux uses ptrace and
>>> has much the the common code filtered out into correct classes (posix
>>> ptrace, linux specifics, and more.
>>>
>>> What architecture and os are you looking to support?
>>>
>>> Greg Clayton
>>>
>>> On Sep 16, 2017, at 6:28 AM, Ramana <ramana.venka...@gmail.com> wrote:
>>>
>>> Thank you Greg for the detailed response.
>>>
>>> Can you please also shed some light on the NativeRegisterContext. When
>>> do we need to subclass NativeRegisterContext and (how) are they
>>> related to RegisterContext_>> It appears that not all architectures having
>>> RegisterContext_ have sub classed NativeRegisterContext.
>>>
>>> Regards,
>>> Ramana
>>>
>>> On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton <clayb...@gmail.com> wrote:
>>>
>>> Seems like this class was added for testing. RegisterInfoInterface is a
>>> class that creates a common API for getting lldb_private::RegisterInfo
>>> structures.
>>>
>>> A RegisterContext_ class uses one of these to be able to create a
>>> buffer large enough to store all registers defined in the
>>> RegisterInfoInterface and will actually read/write there registers to/from
>>> the debugged process. RegisterContext also caches registers values so they
>>> don't get read multiple times when the process hasn't resumed. A
>>> RegisterContext subclass is needed for each architecture so we can
>>> dynamically tell LLDB what the registers look like for a given architecture.
>>> It also provides abstractions by letting each register define its registers
>>> numbers for Compilers, DWARF, and generic register numbers like PC, SP, FP,
>>> return address, and flags registers. This allows the generic part of LLDB to
>>> say "I need you to give me the PC register for this thread" and we don't
>>> need to know that the register is "eip" on x86, "rip" on x86_64, "r15" on
>>> ARM. RegisterContext classes can also determine how registers are
>>> read/written: one at a time, or "get all general purpose regs" and "get all
>>> FPU regs". So if someone asks a RegisterContext to read the PC, it might go
>>> read all GPR regs and then mark them all as valid in the register context
>>> buffer cache, so if someone subsequently asks for SP, it will be already
>>> cached.
>>>
>>> So RegisterInfoInterface defines a common way that many RegisterContext
>>> classes can inherit from in order to give out the lldb_private::RegisterInfo
>>> (which is required by all subclasses of RegisterContext) info for a register
>>> context, and RegisterContext is the one that actually will interface with
>>> the debugged process in order to read/write and cache those registers as
>>> efficiently as possible for the current program being debugged.
>>>
>>> On Sep 12, 2017, at 10:59 PM, Ramana via lldb-dev <lldb-dev@lists.llvm.org>
>>> wrote:
>>>
>>> Hi,
>>>
>>> When deriving RegisterContext_, why some platforms (Arch+OS)
>>> are deriving it from lldb_private::RegisterContext while others are
>>> deriving from lldb_private::RegisterInfoInterface or in other words
>>> how to decide on the base class to derive from between those two and
>>> what are the implications?
>>>
>>> Thanks,
>>> Ramana
>>> ___
>>> 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_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ramana via lldb-dev]

Thank you so much Greg for your comments.

> What architecture and os are you looking to support?

The OS is Linux and the primary use scenario is remote debugging.
Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html
is what I am trying to achieve and unfortunately that query did not
get much attention of the members.

Thanks,
Ramana

On Mon, Sep 18, 2017 at 8:46 PM, Greg Clayton <clayb...@gmail.com> wrote:
> When supporting a new architecture, our preferred route is to modify 
> lldb-server (a GDB server binary that supports native debugging) to support 
> your architecture. Why? Because this gets you remote debugging for free. If 
> you go this route, then you will subclass a 
> lldb_private::NativeRegisterContext and that will get used by lldb-server 
> (along with lldb_private::NativeProcessProtocol and 
> lldb_private::NativeThreadProtocol). If you are adding a new architecture to 
> Linux, then you will likely just need to subclass NativeRegisterContext.
>
> The other way to go is to subclass lldb_private::Process, 
> lldb_private::Thread and lldb_private::RegisterContext.
>
> The nice thing about the lldb_private::Native* subclasses is that you only 
> need to worry about native support. You can use #ifdef and use system header 
> files, where as the non native route, those classes need to be able to debug 
> remotely and you can't rely on system headers (lldb_private::Process, 
> lldb_private::Thread and lldb_private::RegisterContext) since they can be 
> compiled on any system for possibly local debugging (if current 
> arch/vendor/os matches the current system) and remote (if you use lldb-server 
> or another form for RPC).
>
> I would highly suggest getting going the lldb-server route as then you can 
> use system header files that contain the definitions of the registers and you 
> only need to worry about the native architecture. Linux uses ptrace and has 
> much the the common code filtered out into correct classes (posix ptrace, 
> linux specifics, and more.
>
> What architecture and os are you looking to support?
>
> Greg Clayton
>
>> On Sep 16, 2017, at 6:28 AM, Ramana <ramana.venka...@gmail.com> wrote:
>>
>> Thank you Greg for the detailed response.
>>
>> Can you please also shed some light on the NativeRegisterContext. When
>> do we need to subclass NativeRegisterContext and (how) are they
>> related to RegisterContext_> It appears that not all architectures having
>> RegisterContext_ have sub classed NativeRegisterContext.
>>
>> Regards,
>> Ramana
>>
>> On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton <clayb...@gmail.com> wrote:
>>> Seems like this class was added for testing. RegisterInfoInterface is a 
>>> class that creates a common API for getting lldb_private::RegisterInfo 
>>> structures.
>>>
>>> A RegisterContext_ class uses one of these to be able to create a 
>>> buffer large enough to store all registers defined in the 
>>> RegisterInfoInterface and will actually read/write there registers to/from 
>>> the debugged process. RegisterContext also caches registers values so they 
>>> don't get read multiple times when the process hasn't resumed. A 
>>> RegisterContext subclass is needed for each architecture so we can 
>>> dynamically tell LLDB what the registers look like for a given 
>>> architecture. It also provides abstractions by letting each register define 
>>> its registers numbers for Compilers, DWARF, and generic register numbers 
>>> like PC, SP, FP, return address, and flags registers. This allows the 
>>> generic part of LLDB to say "I need you to give me the PC register for this 
>>> thread" and we don't need to know that the register is "eip" on x86, "rip" 
>>> on x86_64, "r15" on ARM. RegisterContext classes can also determine how 
>>> registers are read/written: one at a time, or "get all general purpose 
>>> regs" and "get all FPU regs". So if someone asks a RegisterContext to read 
>>> the PC, it might go read all GPR regs and then mark them all as valid in 
>>> the register context buffer cache, so if someone subsequently asks for SP, 
>>> it will be already cached.
>>>
>>> So RegisterInfoInterface defines a common way that many RegisterContext 
>>> classes can inherit from in order to give out the 
>>> lldb_private::RegisterInfo (which is required by all subclasses of 
>>> RegisterContext) info for a register context, and RegisterContext is the 
>>> one that actually will interface with the debugged process in order to 
>>> read/

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ramana via lldb-dev]

Context classes can also determine how
>> registers are read/written: one at a time, or "get all general purpose regs" 
>> and
>> "get all FPU regs". So if someone asks a RegisterContext to read the PC, it
>> might go read all GPR regs and then mark them all as valid in the register
>> context buffer cache, so if someone subsequently asks for SP, it will be 
>> already
>> cached.
>> >>
>> >> So RegisterInfoInterface defines a common way that many RegisterContext
>> classes can inherit from in order to give out the lldb_private::RegisterInfo
>> (which is required by all subclasses of RegisterContext) info for a register
>> context, and RegisterContext is the one that actually will interface with the
>> debugged process in order to read/write and cache those registers as
>> efficiently as possible for the current program being debugged.
>> >>
>> >>> On Sep 12, 2017, at 10:59 PM, Ramana via lldb-dev > d...@lists.llvm.org> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> When deriving RegisterContext_, why some platforms
>> >>> (Arch+OS) are deriving it from lldb_private::RegisterContext while
>> >>> others are deriving from lldb_private::RegisterInfoInterface or in
>> >>> other words how to decide on the base class to derive from between
>> >>> those two and what are the implications?
>> >>>
>> >>> Thanks,
>> >>> Ramana
>> >>> ___
>> >>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ramana via lldb-dev]

Thank you Greg for the detailed response.

Can you please also shed some light on the NativeRegisterContext. When
do we need to subclass NativeRegisterContext and (how) are they
related to RegisterContext_?
It appears that not all architectures having
RegisterContext_ have sub classed NativeRegisterContext.

Regards,
Ramana

On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton <clayb...@gmail.com> wrote:
> Seems like this class was added for testing. RegisterInfoInterface is a class 
> that creates a common API for getting lldb_private::RegisterInfo structures.
>
> A RegisterContext_ class uses one of these to be able to create a 
> buffer large enough to store all registers defined in the 
> RegisterInfoInterface and will actually read/write there registers to/from 
> the debugged process. RegisterContext also caches registers values so they 
> don't get read multiple times when the process hasn't resumed. A 
> RegisterContext subclass is needed for each architecture so we can 
> dynamically tell LLDB what the registers look like for a given architecture. 
> It also provides abstractions by letting each register define its registers 
> numbers for Compilers, DWARF, and generic register numbers like PC, SP, FP, 
> return address, and flags registers. This allows the generic part of LLDB to 
> say "I need you to give me the PC register for this thread" and we don't need 
> to know that the register is "eip" on x86, "rip" on x86_64, "r15" on ARM. 
> RegisterContext classes can also determine how registers are read/written: 
> one at a time, or "get all general purpose regs" and "get all FPU regs". So 
> if someone asks a RegisterContext to read the PC, it might go read all GPR 
> regs and then mark them all as valid in the register context buffer cache, so 
> if someone subsequently asks for SP, it will be already cached.
>
> So RegisterInfoInterface defines a common way that many RegisterContext 
> classes can inherit from in order to give out the lldb_private::RegisterInfo 
> (which is required by all subclasses of RegisterContext) info for a register 
> context, and RegisterContext is the one that actually will interface with the 
> debugged process in order to read/write and cache those registers as 
> efficiently as possible for the current program being debugged.
>
>> On Sep 12, 2017, at 10:59 PM, Ramana via lldb-dev <lldb-dev@lists.llvm.org> 
>> wrote:
>>
>> Hi,
>>
>> When deriving RegisterContext_, why some platforms (Arch+OS)
>> are deriving it from lldb_private::RegisterContext while others are
>> deriving from lldb_private::RegisterInfoInterface or in other words
>> how to decide on the base class to derive from between those two and
>> what are the implications?
>>
>> Thanks,
>> Ramana
>> ___
>> 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_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ramana via lldb-dev]

Thank you.

On Wed, Sep 13, 2017 at 6:10 PM, Tatyana Krasnukha
<tatyana.krasnu...@synopsys.com> wrote:
> Hi Ramana,
>
> Looks like just a naming issue - classes derived from RegisterInfoInterface 
> should be named as RegisterInfo_, because they just implement a 
> common interface to access targets's register info structures. Whereas 
> RegisterContext relates to certain execution context and concrete frame, and 
> implements process-specific functions, for example restoring registers state 
> after expression evaluation.
>
> Please, correct me anyone, if I'm wrong.
>
> Tatyana
>
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Ramana 
> via lldb-dev
> Sent: Wednesday, 13 September, 2017 9:00 AM
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] lldb_private::RegisterContext vs 
> lldb_private::RegisterInfoInterface
>
> Hi,
>
> When deriving RegisterContext_, why some platforms (Arch+OS) are 
> deriving it from lldb_private::RegisterContext while others are deriving from 
> lldb_private::RegisterInfoInterface or in other words how to decide on the 
> base class to derive from between those two and what are the implications?
>
> Thanks,
> Ramana
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=DwIGaQ=DPL6_X_6JkXFx7AXWqB0tg=8NZfjV_ZLY_S7gZyQMq8mj7tiN4vlymPiSt0Wl0jegw=YZ3Zmbvj4mvkuTSfZ9-gC0Gi1rMMrrPaSTL8YBCytAM=55CKoDxnRsC-dUPbL7T3sQ2HL74C2foFRhvssSATbbw=
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-5.0 on linux not finding lldb-server-5.0.0

[Ramana via lldb-dev]

At least I did not encounter the below issue on Ubuntu 16.04 (with x86
i.e 32bit) machine with lldb v5.0.

FYI, I have built the tool chain from the RELEASE_500/final tag source.

> Somebody on stack overflow is reporting:

> https://stackoverflow.com/questions/46164427/lldb-is-not-starting-an-application

> that they got the 5.0 tools on an Ubuntu system, and lldb is saying:

> error: process launch failed: unable to locate lldb-server-5.0.0

> when he tries to run a process.  The reporter says there's an lldb-server in 
> the package he got, but not an lldb-server-5.0.0.

> Did his install just go bad or is this something other folks are seeing?  I 
> don't have an Ubuntu system handy to check this out.

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

[lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ramana via lldb-dev]

Hi,

When deriving RegisterContext_, why some platforms (Arch+OS)
are deriving it from lldb_private::RegisterContext while others are
deriving from lldb_private::RegisterInfoInterface or in other words
how to decide on the base class to derive from between those two and
what are the implications?

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

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

The patch works for x86 remote debugging as well.

$ ../binaries/x86_debug/bin/lldb --version
lldb version 6.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
revision 312008)
  clang revision 312008
  llvm revision 312008

On Tue, Aug 29, 2017 at 10:51 PM, Ramana <ramana.venka...@gmail.com> wrote:
> Thanks Chris. The patch woks for ARM remote debugging for my case. I
> am yet to check x86 remote debugging. Need to build the tool chain, so
> will update you tomorrow.
>
> ~# /mnt/var/arm_debug/bin/lldb --version
> lldb version 6.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
> revision 312008)
>   clang revision 312008
>   llvm revision 312008
>
> "gdb-remote process" log of lldb-server says
>
>GDBRemoteCommunication::StartDebugserverProcess() debugserver
> listens 55874 port
>
> ~/Ramana# ps af -w
>   PID TTY  STAT   TIME COMMAND
>  8314 pts/0S+ 0:00  \_ /mnt/var/arm_debug/bin/lldb-server p
> --log-file Ramana/remote.log --log-channels gdb-remote process
> --server --listen *:1400
>  8421 pts/0Sl+0:01  \_ /mnt/var/arm_debug/bin/lldb-server
> p --log-file Ramana/remote.log --log-channels gdb-remote process
> --server --listen *:1400
>  8477 pts/0S+ 0:00  \_
> /mnt/var/arm_debug/bin/lldb-server gdbserver tcp://10.10.12.3:0
> --native-regs --pipe 7
>  8514 pts/0t  0:00  \_ /home/root/arm_main
>
>
>
> ~/work_root/ToT_lldb/tests$ ../binaries/x86_debug/bin/lldb
> (lldb) platform select remote-linux
>   Platform: remote-linux
>  Connected: no
> (lldb) platform connect connect://10.10.2.1:1400
>   Platform: remote-linux
> Triple: arm-*-linux-gnueabihf
> OS Version: 4.1.33 (4.1.33-ltsi-altera)
> Kernel: #1 SMP Tue May 2 08:13:11 MYT 2017
>   Hostname: arria5
>  Connected: yes
> WorkingDir: /home/root
> (lldb) file arm_main
> Current executable set to 'arm_main' (arm).
> (lldb) b main
> Breakpoint 1: where = arm_main`main + 4 at main.c:4, address = 0x000104a0
> (lldb) run
> Process 8514 launched: '/home/ramanan/work_root/ToT_lldb/tests/arm_main' (arm)
> Process 8514 stopped
> * thread #1, name = 'arm_main', stop reason = breakpoint 1.1
> frame #0: 0x000104a0 arm_main`main at main.c:4
>1#include 
>2
>3int main() {
> -> 4printf("Hello World\n");
>5}
> (lldb) n
> Hello World
> Process 8514 stopped
> * thread #1, name = 'arm_main', stop reason = step over
> frame #0: 0x000104ae arm_main`main at main.c:5
>2
>3int main() {
>4printf("Hello World\n");
> -> 5}
>
>
>
> Regards,
> Ramana
>
> On Tue, Aug 29, 2017 at 9:49 PM, Chris Bieneman <cbiene...@apple.com> wrote:
>> I committed a fix in r312008. Please test it to verify that it resolves your 
>> issue.
>>
>> Thanks,
>> -Chris
>>
>>> On Aug 28, 2017, at 8:41 PM, Ramana <ramana.venka...@gmail.com> wrote:
>>>
>>> Thank you, Chris. Looking forward to the patch.
>>>
>>> On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman <cbiene...@apple.com> wrote:
>>>> I had a chance to look into this more, and I found a bug in the listen 
>>>> behavior. I'm testing a solution to it now. Will post it if it resolves 
>>>> the issue.
>>>>
>>>> -Chris
>>>>
>>>>> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>>>>> <lldb-dev@lists.llvm.org> wrote:
>>>>>
>>>>> Maybe we can make it open only an IPv4 socket for lldb-server for now as 
>>>>> a work around?
>>>>>
>>>>>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman <cbiene...@apple.com> wrote:
>>>>>>
>>>>>> Since lldb-server only supports running on a limited set of host 
>>>>>> operating systems it is hard for me to diagnose the issue completely, 
>>>>>> but I suspect the problem is caused by the fact that the new listening 
>>>>>> code can open more than one socket, and TCPSocket::GetLocalPortNumber() 
>>>>>> may be misbehaving.
>>>>>>
>>>>>> I'm unlikely to have time to investigate further until next week, but it 
>>>>>> should be possible to craft a unit test that verifies that 
>>>>>> GetLocalPortNumber() returns non-zero on a socket that is listening 
>>>>>> before a connection is established. That might reproduce the issue in a 
>>>>>> more easy to debug environment.
>>>>>>
>>>>>> -Chris
>>&g

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

Thanks Chris. The patch woks for ARM remote debugging for my case. I
am yet to check x86 remote debugging. Need to build the tool chain, so
will update you tomorrow.

~# /mnt/var/arm_debug/bin/lldb --version
lldb version 6.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
revision 312008)
  clang revision 312008
  llvm revision 312008

"gdb-remote process" log of lldb-server says

   GDBRemoteCommunication::StartDebugserverProcess() debugserver
listens 55874 port

~/Ramana# ps af -w
  PID TTY  STAT   TIME COMMAND
 8314 pts/0S+ 0:00  \_ /mnt/var/arm_debug/bin/lldb-server p
--log-file Ramana/remote.log --log-channels gdb-remote process
--server --listen *:1400
 8421 pts/0Sl+0:01  \_ /mnt/var/arm_debug/bin/lldb-server
p --log-file Ramana/remote.log --log-channels gdb-remote process
--server --listen *:1400
 8477 pts/0S+ 0:00  \_
/mnt/var/arm_debug/bin/lldb-server gdbserver tcp://10.10.12.3:0
--native-regs --pipe 7
 8514 pts/0t  0:00  \_ /home/root/arm_main



~/work_root/ToT_lldb/tests$ ../binaries/x86_debug/bin/lldb
(lldb) platform select remote-linux
  Platform: remote-linux
 Connected: no
(lldb) platform connect connect://10.10.2.1:1400
  Platform: remote-linux
Triple: arm-*-linux-gnueabihf
OS Version: 4.1.33 (4.1.33-ltsi-altera)
Kernel: #1 SMP Tue May 2 08:13:11 MYT 2017
  Hostname: arria5
 Connected: yes
WorkingDir: /home/root
(lldb) file arm_main
Current executable set to 'arm_main' (arm).
(lldb) b main
Breakpoint 1: where = arm_main`main + 4 at main.c:4, address = 0x000104a0
(lldb) run
Process 8514 launched: '/home/ramanan/work_root/ToT_lldb/tests/arm_main' (arm)
Process 8514 stopped
* thread #1, name = 'arm_main', stop reason = breakpoint 1.1
frame #0: 0x000104a0 arm_main`main at main.c:4
   1#include 
   2
   3int main() {
-> 4printf("Hello World\n");
   5}
(lldb) n
Hello World
Process 8514 stopped
* thread #1, name = 'arm_main', stop reason = step over
frame #0: 0x000104ae arm_main`main at main.c:5
   2
   3int main() {
   4printf("Hello World\n");
-> 5}



Regards,
Ramana

On Tue, Aug 29, 2017 at 9:49 PM, Chris Bieneman <cbiene...@apple.com> wrote:
> I committed a fix in r312008. Please test it to verify that it resolves your 
> issue.
>
> Thanks,
> -Chris
>
>> On Aug 28, 2017, at 8:41 PM, Ramana <ramana.venka...@gmail.com> wrote:
>>
>> Thank you, Chris. Looking forward to the patch.
>>
>> On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman <cbiene...@apple.com> wrote:
>>> I had a chance to look into this more, and I found a bug in the listen 
>>> behavior. I'm testing a solution to it now. Will post it if it resolves the 
>>> issue.
>>>
>>> -Chris
>>>
>>>> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>>>> <lldb-dev@lists.llvm.org> wrote:
>>>>
>>>> Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
>>>> work around?
>>>>
>>>>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman <cbiene...@apple.com> wrote:
>>>>>
>>>>> Since lldb-server only supports running on a limited set of host 
>>>>> operating systems it is hard for me to diagnose the issue completely, but 
>>>>> I suspect the problem is caused by the fact that the new listening code 
>>>>> can open more than one socket, and TCPSocket::GetLocalPortNumber() may be 
>>>>> misbehaving.
>>>>>
>>>>> I'm unlikely to have time to investigate further until next week, but it 
>>>>> should be possible to craft a unit test that verifies that 
>>>>> GetLocalPortNumber() returns non-zero on a socket that is listening 
>>>>> before a connection is established. That might reproduce the issue in a 
>>>>> more easy to debug environment.
>>>>>
>>>>> -Chris
>>>>>
>>>>>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev 
>>>>>> <lldb-dev@lists.llvm.org> wrote:
>>>>>>
>>>>>> Ted, Greg,
>>>>>>
>>>>>> I have built lldb tools @r300578 and the lldb-server is returning the
>>>>>> proper port number to lldb client and the remote debugging is working.
>>>>>> I have given the lldb-server log at the bottom of my reply.
>>>>>>
>>>>>> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
>>>>>> support IPv6 over TCP) is causing the issue.
>>>>>>
>>>>>>> Ramana, can you stick in a log mes

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

Thank you, Chris. Looking forward to the patch.

On Tue, Aug 29, 2017 at 1:28 AM, Chris Bieneman <cbiene...@apple.com> wrote:
> I had a chance to look into this more, and I found a bug in the listen 
> behavior. I'm testing a solution to it now. Will post it if it resolves the 
> issue.
>
> -Chris
>
>> On Aug 25, 2017, at 10:36 AM, Greg Clayton via lldb-dev 
>> <lldb-dev@lists.llvm.org> wrote:
>>
>> Maybe we can make it open only an IPv4 socket for lldb-server for now as a 
>> work around?
>>
>>> On Aug 25, 2017, at 8:47 AM, Chris Bieneman <cbiene...@apple.com> wrote:
>>>
>>> Since lldb-server only supports running on a limited set of host operating 
>>> systems it is hard for me to diagnose the issue completely, but I suspect 
>>> the problem is caused by the fact that the new listening code can open more 
>>> than one socket, and TCPSocket::GetLocalPortNumber() may be misbehaving.
>>>
>>> I'm unlikely to have time to investigate further until next week, but it 
>>> should be possible to craft a unit test that verifies that 
>>> GetLocalPortNumber() returns non-zero on a socket that is listening before 
>>> a connection is established. That might reproduce the issue in a more easy 
>>> to debug environment.
>>>
>>> -Chris
>>>
>>>> On Aug 25, 2017, at 7:38 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org> 
>>>> wrote:
>>>>
>>>> Ted, Greg,
>>>>
>>>> I have built lldb tools @r300578 and the lldb-server is returning the
>>>> proper port number to lldb client and the remote debugging is working.
>>>> I have given the lldb-server log at the bottom of my reply.
>>>>
>>>> So, it looks https://reviews.llvm.org/rL300579 (Update LLDB Host to
>>>> support IPv6 over TCP) is causing the issue.
>>>>
>>>>> Ramana, can you stick in a log message to print port_cstr? I suspect it's 
>>>>> actually getting 0 back from lldb-server, which would tell us the error 
>>>>> is in the server code, not the client code.
>>>>
>>>> Ted, I did that and actually the pipe read is returning zero port
>>>> number. So definitely the issue is on the server side.
>>>>
>>>>   GDBRemoteCommunication::StartDebugserverProcess() port_cstr
>>>> before socket pipe read
>>>>   GDBRemoteCommunication::StartDebugserverProcess() port_cstr after
>>>> socket pipe read
>>>>
>>>>
>>>>> Ted's comments are correct and I am guessing we will find the 
>>>>> "lldb-server gdb-server" is not doing the right thing and it isn't 
>>>>> returning the correctly bound port.
>>>>>
>>>>> When we are doing remote stuff we must use TCP so there should be 
>>>>> lldb-server should be opening a TCP socket, binding, listening and 
>>>>> accepting a connection from the remote LLDB.
>>>>>
>>>>> Greg
>>>>
>>>> Greg, thanks for the comments. Are you saying I should check what is
>>>> happening on the TCP socket side? How do I do it other than walking
>>>> through the code?
>>>>
>>>>
>>>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb-server platform
>>>> --log-file Ramana/remote.log --log-channels "gdb-remote process"
>>>> --server --listen *:1400
>>>> Connection established.
>>>> error: lost connection
>>>> lldb-server exiting...
>>>> ^C
>>>> root@arria5:~# /mnt/var/patch_bins/binaries/bin/lldb --version
>>>> lldb version 5.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk
>>>> revision 300578)
>>>> clang revision 300578
>>>> llvm revision 300578
>>>> root@arria5:~# cat Ramana/remote.log
>>>> GDBRemoteCommunication::StartDebugserverProcess(url=tcp://10.10.12.3:0, 
>>>> port=0)
>>>> GDBRemoteCommunication::StartDebugserverProcess() found gdb-remote
>>>> stub exe '/mnt/var/patch_bins/binaries/bin/lldb-server'
>>>> launch info for gdb-remote stub:
>>>> Executable: lldb-server
>>>> Triple: *-*-*
>>>> Arguments:
>>>> argv[0]="/mnt/var/patch_bins/binaries/bin/lldb-server"
>>>> argv[1]="gdbserver"
>>>> argv[2]="tcp://10.10.12.3:0"
>>>> argv[3]="--native-regs"
>>>> argv[4]="--pipe"
>>&

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

env[15]="XDG_RUNTIME_DIR=/run/user/0"
env[16]="_=/mnt/var/binaries/arm_v5.0_orig/bin/lldb-server"
env[17]=NULL

GDBRemoteCommunication::StartDebugserverProcess() debugserver listens 0 port


Thanks,
Ramana

> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
>> Clayton via lldb-dev
>> Sent: Wednesday, August 23, 2017 12:45 PM
>> To: Hans Wennborg <h...@chromium.org>
>> Cc: Ramana <ramana.venka...@gmail.com>; LLDB Dev > d...@lists.llvm.org>
>> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
>>
>> Port zero should never be returned as a valid port. We do bind to port zero 
>> just
>> so we don't try and pick a port at random just to find it is being used. 
>> When we
>> bind to port 9, we must find the actual port we bound to and return that. 
>> Seems
>> something has gone wrong with the code that discovers the port that was
>> actually bound and is not reporting that back correctly.
>>
>>
>> Should be straight forward to do by debugging the function
>> GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer(...) in
>> GDBRemoteCommunicationServerPlatform.cpp and see what is going on and
>> why it is returning 0 as the port.
>>
>> Greg
>>
>> > On Aug 23, 2017, at 9:44 AM, Hans Wennborg via lldb-dev > d...@lists.llvm.org> wrote:
>> >
>> > This was marked as an lldb 5.0.0 release blocker since it's a
>> > regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183
>> >
>> > lldb-dev: Is there any interest in fixing this bug?
>> >
>> > On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev
>> > <lldb-dev@lists.llvm.org> wrote:
>> >> Hi,
>> >>
>> >> I am trying to remote debug ARM (linux) target from x86 (linux) host
>> >> and I am getting the following error while trying to launch a process.
>> >> The local debugging on ARM works.
>> >>
>> >> error: connect remote failed (invalid host:port specification:
>> >> '10.10.2.3')
>> >> error: process launch failed: invalid host:port specification: '10.10.2.3'
>> >>
>> >> It appears the above error is because the gdb-remote is returning the
>> >> communication port as zero.
>> >>
>> >> <  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
>> >> <  19> read packet: $pid:298;port:0;#bf
>> >>
>> >> What are the possible reasons for the above behavior from gdb-remote
>> >> and how I could resolve this?
>> >>
>> >> If it helps, below is the full log.
>> >>
>> >> (lldb) log enable lldb comm
>> >> (lldb) log enable gdb-remote packets
>> >> (lldb) platform select remote-linux
>> >>  Platform: remote-linux
>> >> Connected: no
>> >> (lldb) platform connect connect://10.10.2.3:500
>> >> 0x915bd78 Communication::Communication (name = gdb-remote.client)
>> >> 0x915bd78 Communication::Disconnect ()
>> >> 0x915bd78 Communication::Disconnect ()
>> >> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
>> >> Socket::TcpConnect (host/port = 10.10.2.3:500) TCPSocket::Connect
>> >> (host/port = 10.10.2.3:500)
>> >> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
>> >> connection = 0x915f578
>> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
>> >> flags = 0) => 1 (error = (null))
>> >> <   1> send packet: +
>> >> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
>> >> us, connection = 0x0915F578
>> >> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
>> >> connection = 0x915f578
>> >> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
>> >> flags = 0) => 19 (error = (null))
>> >> history[1] tid=0x7cbf <   1> send packet: +
>> >> <  19> send packet: $QStartNoAckMode#b0 this = 0x0915BD78, dst =
>> >> 0xBFCB51AC, dst_len = 8192, timeout = 600 us, connection =
>> >> 0x0915F578
>> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
>> >> flags = 0) => 7 (error = (null))
>> >> <   1> read 

[lldb-dev] Remote debugging ARM target from x86 host

[Ramana via lldb-dev]

Hi,

I am trying to remote debug ARM (linux) target from x86 (linux) host
and I am getting the following error while trying to launch a process.
The local debugging on ARM works.

error: connect remote failed (invalid host:port specification: '10.10.2.3')
error: process launch failed: invalid host:port specification: '10.10.2.3'

It appears the above error is because the gdb-remote is returning the
communication port as zero.

<  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
<  19> read packet: $pid:298;port:0;#bf

What are the possible reasons for the above behavior from gdb-remote
and how I could resolve this?

If it helps, below is the full log.

(lldb) log enable lldb comm
(lldb) log enable gdb-remote packets
(lldb) platform select remote-linux
  Platform: remote-linux
 Connected: no
(lldb) platform connect connect://10.10.2.3:500
0x915bd78 Communication::Communication (name = gdb-remote.client)
0x915bd78 Communication::Disconnect ()
0x915bd78 Communication::Disconnect ()
0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
Socket::TcpConnect (host/port = 10.10.2.3:500)
TCPSocket::Connect (host/port = 10.10.2.3:500)
0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
flags = 0) => 1 (error = (null))
<   1> send packet: +
this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
us, connection = 0x0915F578
0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
flags = 0) => 19 (error = (null))
history[1] tid=0x7cbf <   1> send packet: +
<  19> send packet: $QStartNoAckMode#b0
this = 0x0915BD78, dst = 0xBFCB51AC, dst_len = 8192, timeout = 600
us, connection = 0x0915F578
0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
flags = 0) => 7 (error = (null))
<   1> read packet: +
<   6> read packet: $OK#9a
0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1,
flags = 0) => 1 (error = (null))
<   1> send packet: +
0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13,
flags = 0) => 13 (error = (null))
<  13> send packet: $qHostInfo#9b
this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout = 100
us, connection = 0x0915F578
0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len = 316,
flags = 0) => 316 (error = (null))
< 316> read packet:
$triple:61726d2d2d6c696e75782d676e75656162696866;ptrsize:4;watchpoint_exceptions_received:before;endian:little;os_version:3.10.31;os_build:332e31302e33312d6c7473692d30323836312d6738303161343066;os_kernel:233520534d5020467269204d61792031332031353a35383a3232204953542032303136;hostname:736f
63667067615f617272696135;#0a
0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 18)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 18,
flags = 0) => 18 (error = (null))
<  18> send packet: $qGetWorkingDir#91
this = 0x0915BD78, dst = 0xBFCB50FC, dst_len = 8192, timeout = 100
us, connection = 0x0915F578
0x915f608 Socket::Read() (socket = 7, src = 0xbfcb50fc, src_len = 24,
flags = 0) => 24 (error = (null))
<  24> read packet: $2f686f6d652f726f6f74#4b
0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 19)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 19,
flags = 0) => 19 (error = (null))
<  19> send packet: $qQueryGDBServer#cb
this = 0x0915BD78, dst = 0xBFCB531C, dst_len = 8192, timeout = 100
us, connection = 0x0915F578
0x915f608 Socket::Read() (socket = 7, src = 0xbfcb531c, src_len = 7,
flags = 0) => 7 (error = (null))
<   7> read packet: $E04#a9
  Platform: remote-linux
Triple: arm-*-linux-gnueabihf
OS Version: 3.10.31 (3.10.31-ltsi-02861-g801a40f)
Kernel: #5 SMP Fri May 13 15:58:22 IST 2016
  Hostname: socfpga_arria5
 Connected: yes
WorkingDir: /home/root
(lldb) file main
0x915bd78 Communication::Write (src = 0x91638fc, src_len = 137)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 0x91638fc, src_len = 137,
flags = 0) => 137 (error = (null))
< 137> send packet:
$qModuleInfo:2f686f6d652f72616d616e616e2f776f726b5f726f6f742f546f545f6c6c64622f74657374732f6d61696e;61726d2d2d6c696e75782d656162696866#f1
this = 0x0915BD78, dst = 0xBFCB172C, dst_len = 8192, timeout = 100
us, connection = 0x0915F578
0x915f608 Socket::Read() (socket = 7, src = 0xbfcb172c, src_len = 7,
flags = 0) => 7 (error = (null))
<   7> read packet: $E03#a8
Current executable set to 'main' (arm).
(lldb) b main
Breakpoint 1: where = main`main + 4 at main.c:4, address = 0x000104a0
(lldb) run
0x915bd78 Communication::Write (src = 0x917bae4, src_len = 36)
connection = 0x915f578
0x915f608 Socket::Write() (socket = 7, src = 

Re: [lldb-dev] Current status of simultaneous multiple target debugging in LLDB

[Ramana via lldb-dev]

Hi,

Could someone please help me on the below?

Thanks,
Ramana

On Mon, Jun 12, 2017 at 11:58 AM, Ramana  wrote:

> Hi,
>
> I have to implement a debugger for our HW which comprises of CPU+GPU where
> the GPU is coded in OpenCL and is accelerated through OpenVX API in C++
> application which runs on CPU. Our requirement is we should be able to
> debug the code running on both CPU and GPU simultaneously with in the same
> LLDB debug session.
>
> Looking at the mailing list archive I see that there were discussions
> about this feature in LLDB here http://lists.llvm.org/
> pipermail/lldb-dev/2014-August/005074.html.
>
> What is the present status i.e. what works today and what is to be
> improved of simultaneous multiple target debugging support in LLDB? Were
> the changes contributed to LLDB mainstream?
>
> How can I access the material for http://llvm.org/devmtg/2014-10/#bof5
> (Future directions and features for LLDB)
>
> Appreciate any help/guidance provided on the same.
>
> Thanks,
> Ramana
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Current status of simultaneous multiple target debugging in LLDB

[Ramana via lldb-dev]

Hi,

I have to implement a debugger for our HW which comprises of CPU+GPU where
the GPU is coded in OpenCL and is accelerated through OpenVX API in C++
application which runs on CPU. Our requirement is we should be able to
debug the code running on both CPU and GPU simultaneously with in the same
LLDB debug session.

Looking at the mailing list archive I see that there were discussions about
this feature in LLDB here
http://lists.llvm.org/pipermail/lldb-dev/2014-August/005074.html.

What is the present status i.e. what works today and what is to be improved
of simultaneous multiple target debugging support in LLDB? Were the changes
contributed to LLDB mainstream?

How can I access the material for http://llvm.org/devmtg/2014-10/#bof5
(Future directions and features for LLDB)

Appreciate any help/guidance provided on the same.

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

Re: [lldb-dev] Debugging ELF relocatable files using LLDB

[Ramana via lldb-dev]

On Thu, Feb 16, 2017 at 10:26 PM, Greg Clayton <gclay...@apple.com> wrote:
>
> On Feb 16, 2017, at 3:51 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org>
> wrote:
>
> It looks like LLDB doesn't like ELF relocatable files for debugging
> and asserts with the following message when tried
>
> /lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2228:
> unsigned int ObjectFileELF::RelocateSection(.):  Assertion `false
> && "unexpected relocation type"' failed.
>
> Are we not supposed to debug ELF relocatable files on LLDB or am I
> missing something?
>
> If we cannot debug the relocatable files, is it _simply_ because those
> files lack program headers (program memory map) and relocations are
> yet to be processed (for debug info) or there are other reasons?
>
> For our target, the assembler output itself is a self contained ELF
> and hence will not have external references (both code and data). I am
> wondering if I can debug these ELF files on LLDB with minimal changes
> which does not require a full (or proper) linking step and would
> appreciate any pointers on that.
>
> Thanks,
> Ramana
>
>
> Looks like you just need to add support for the 32 bit relocations:
>
>
> if (hdr->Is32Bit()) {
>   switch (reloc_type(rel)) {
>   case R_386_32:
>   case R_386_PC32:
>   default:
> assert(false && "unexpected relocation type");
>   }
> } else {
>   switch (reloc_type(rel)) {
>   case R_X86_64_64: {
> symbol = symtab->FindSymbolByID(reloc_symbol(rel));
> if (symbol) {
>   addr_t value = symbol->GetAddressRef().GetFileAddress();
>   DataBufferSP _buffer_sp = debug_data.GetSharedDataBuffer();
>   uint64_t *dst = reinterpret_cast(
>   data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +
>   ELFRelocation::RelocOffset64(rel));
>   *dst = value + ELFRelocation::RelocAddend64(rel);
> }
> break;
>   }
>   case R_X86_64_32:
>   case R_X86_64_32S: {
> symbol = symtab->FindSymbolByID(reloc_symbol(rel));
> if (symbol) {
>   addr_t value = symbol->GetAddressRef().GetFileAddress();
>   value += ELFRelocation::RelocAddend32(rel);
>   assert(
>   (reloc_type(rel) == R_X86_64_32 && (value <= UINT32_MAX)) ||
>   (reloc_type(rel) == R_X86_64_32S &&
>((int64_t)value <= INT32_MAX && (int64_t)value >=
> INT32_MIN)));
>   uint32_t truncated_addr = (value & 0x);
>   DataBufferSP _buffer_sp = debug_data.GetSharedDataBuffer();
>   uint32_t *dst = reinterpret_cast(
>   data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +
>   ELFRelocation::RelocOffset32(rel));
>   *dst = truncated_addr;
> }
> break;
>   }
>   case R_X86_64_PC32:
>   default:
> assert(false && "unexpected relocation type");
>   }
> }
>
>
> I am guessing you will do something similar to the x86-64 stuff.

I tried to mimic the x86_64 relocations handling for our target but
getting segmentation fault while trying to write to the 'dst'
location.

In fact, the x86_64 also segfaults while trying to write to 'dst'
location. I just tried to debug the following simple program for
x86_64.

main.c:
int main () {
   return 0;
}

$ clang main.c -o main_64b.o --target=x86_64 -c -g
$  lldb main_64b.o
(lldb) target create "main_64b.o"
Current executable set to 'main_64b.o' (x86_64).
(lldb) source list
Segmentation fault (core dumped)

Am I doing something wrong or support for debugging the x86_64 ELF
relocatable files using LLDB is broken?

BTW, I am using LLVM v3.6 and LLDB v3.6.

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

[lldb-dev] Debugging ELF relocatable files using LLDB

[Ramana via lldb-dev]

It looks like LLDB doesn't like ELF relocatable files for debugging
and asserts with the following message when tried

 /lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2228:
unsigned int ObjectFileELF::RelocateSection(.):  Assertion `false
&& "unexpected relocation type"' failed.

Are we not supposed to debug ELF relocatable files on LLDB or am I
missing something?

If we cannot debug the relocatable files, is it _simply_ because those
files lack program headers (program memory map) and relocations are
yet to be processed (for debug info) or there are other reasons?

For our target, the assembler output itself is a self contained ELF
and hence will not have external references (both code and data). I am
wondering if I can debug these ELF files on LLDB with minimal changes
which does not require a full (or proper) linking step and would
appreciate any pointers on that.

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

[lldb-dev] A typo on the "Testing LLDB" tutorial page?

[Ramana via lldb-dev]

On the "Testing LLDB" tutorial page, in the description under "RUNNING
TESTS -> Running the full test suite" section, should this

> cmake -DLLDB_TEST_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja
> ninja check-lldb

be

> cmake -DLLDB_TEST_USER_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja
> ninja check-lldb

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