<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Yeah, I've been thinking about the different streams you'd need. A
    difficult one is a call stack on a platform, with frames on
    different ABIs/Targets representing cross-architecture calls. <br>
    <br>
    If anyone here has ever used the Cell PPU/SPU gdb, which had this
    feature, I think you'll agree it's absolute gold in terms of value.<br>
    <br>
    Sadly I can't attend this years meeting, but I'll write a BOF
    proposal and send it in anyway with one of the other Codeplayers
    there to host.<br>
    <br>
    Colin<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 28/08/2014 15:00, Todd Fiala wrote:<br>
    </div>
    <blockquote
cite="mid:CAFab17Jsi462tYvK5ZvpF8hz=WW+y=th2MfnFVfXufYbbs3YRA@mail.gmail.com"
      type="cite">
      <div dir="ltr">It might be nice to mock up just the debugger
        command streams we think are needed/wanted to handle several
        common usages of the heterogeneous processor debugging scenarios
        on this thread before putting any code behind it.  That way we
        can talk through it a bit with concrete examples to further
        illuminate the kinds of changes/support we'll need. </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Wed, Aug 27, 2014 at 11:21 PM,
          Matthew Gardiner <span dir="ltr"><<a
              moz-do-not-send="true" href="mailto:mg11@csr.com"
              target="_blank">mg11@csr.com</a>></span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            Yes, a "device" abstraction seems to be the correct
            controlling entity. In fact, from an embedded debugging
            perspective it is __the__ logical entity which groups
            "debuggable opportunities" together. However, when Jim
            mentions "this coordinating entity should not be restricted
            to different devices " and alludes to control over different
            targets (which are in __some_way__ associated in the
            debugging user's mind), but may be running on different
            machines etc.; then I think that conceptually we are still
            talking about the same thing, but the name "device" then
            becomes questionable. I can only really think of something a
            tad wooly like "DebugScenario", "DebugSession" or
            "DeploymentScenario"... :-(<br>
            <br>
            Yes, the Platform should remain just being the Platform.<br>
            <br>
            Regarding "debuggable opportunities" - solely these are just
            the "Target" objects that we already have? (In fact Colin's
            original post does in fact just state "that can take
            multiple targets together and understand how they
            operate...").<br>
            <br>
            What's really tricky, I think, is how to make the
            device/scenario controlling entity look very generic on the
            outside, but within be able to coordinate very target
            specific activities. It seems that the
            debuggable_oppurtunity/target would require some way of
            communicating the kind of multi-target features it can
            support e.g.<br>
            <br>
            CanStopOthers<br>
            CanBeUnselectedAsActive<br>
            ...and so on...<br>
            <br>
            Interested to see how things pan out.<br>
            <br>
            Matt<br>
            <br>
            <br>
            <a moz-do-not-send="true" href="mailto:jingham@apple.com"
              target="_blank">jingham@apple.com</a> wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>
                <div class="h5">
                  Right, it seems to me clear that you need two
                  entities.<br>
                  <br>
                  One knows what targets can be created in a given
                  debugging scenario, and how to hook up to them.  Then
                  you need another to manage picking some subset of
                  these targets, and coordinating the processes running
                  in each of them.<br>
                  <br>
                  The Platform seemed the logical place to do the first
                  job.  However, Matthew is right that at present the
                  Platforms are homogenous, and more deal with OS
                  details.  So maybe it would be better to keep the
                  Platform more about OS details, then we could add a
                  "device" abstraction that represents composite
                  entities with multiple debuggable opportunities, and
                  then each of these "debuggable opportunities" would
                  have a Platform to represent the OS like features of
                  this opportunity (need some good word for this.)  That
                  might be a better way to go.  Note that the
                  "debuggable opportunities" are more general than just
                  different devices on a board.  For instance, you could
                  imagine debugging the kernel, and a user-space process
                  running on that OS, and coordinating those just as you
                  would a main processor and a co-processor...  To make
                  matters a little confusing, a "device" might represent
                  all the processes running on a single OS, since that's
                  not formally different from the more straightforward
                  device scenario.  So in some ways a platform IS also a
                  device in this sense.  Maybe the abstraction is more a
                  target provider, and the Platform is a homogenous
                  target provider, in addition to its OS duties, and a
                  device is a heterogenous target provider?<br>
                  <br>
                  But in either case, once you've chosen to attach to
                  several debug sockets, there's the whole business that
                  Matthew mentions of coordinating the sessions.  That
                  is clearly a whole different kettle of fish from just
                  "what can I attach to".<br>
                  <br>
                  BTW, this coordinating entity should not be restricted
                  to different devices.  At that level, of course, it is
                  really about coordinating targets & their process
                  regardless of where they come from.  For instance
                  you'd want to be able to use the same structure to
                  coordinate debugging message passing or socket
                  traffic, etc on two user space processes on the same
                  or different systems.  It would also be interesting to
                  model this coordination in a way that could also be
                  extended to threads in a single process.  Right now,
                  each thread's behavior is programmed using the
                  ThreadPlans which work only on a per thread basis and
                  don't make any attempt to coordinate threads.  But it
                  would be useful (and more so when you start doing keep
                  alive debugging) to have some way to program "when
                  thread A does X, wait for thread B to do Y..."  That
                  isn't formally different from two processes or several
                  co-processors.  Be interesting to see how much of the
                  coordination we could make very general.<br>
                  <br>
                  Jim<br>
                  <br>
                  <br>
                  <br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    On Aug 27, 2014, at 7:55 AM, Todd Fiala <<a
                      moz-do-not-send="true"
                      href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>>
                    wrote:<br>
                    <br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      Greg and Jim both mentioned using the Platform
                      class as the place to implement this kind of
                      thing.<br>
                    </blockquote>
                    I think Jim later mentioned a higher-level concept
                    is needed to do some of the orchestration that we'd
                    want to enable, IIRC.<br>
                    <br>
                    <br>
                    On Tue, Aug 26, 2014 at 11:18 PM, Matthew Gardiner
                    <<a moz-do-not-send="true"
                      href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>>
                    wrote:<br>
                    Hi Colin,<br>
                    <br>
                    Multiple target debugging is a massive interest to
                    us at CSR. We design chips with various processor
                    types (e.g. kalimba, XAP, 8051, ARM etc) and on
                    several of our chips we have multiple-processors.
                    There are lots of combinations of setups that we
                    have either already done, or are actively
                    experimenting on. Generally, we have heterogenous
                    setups (e.g. XAP+8051, or 4*XAP+kalimba+8051) etc.<br>
                    <br>
                    I see that lldb already supports the concept of a
                    target list, an active target and manual switching
                    between current targets. However, as Colin alludes,
                    there are several features associated with
                    multiple-target which require control from a
                    higher-level.<br>
                    <br>
                    What we currently have in our existing debuggers is
                    options of the form, "I'm debugging targets A and B,
                    if A stops do I want B stop as well?". The answer to
                    that question is very much specific to that user's
                    current debug scenario. Of course, getting B to stop
                    if A does, is best implemented in the hardware, and
                    typically a register will be available as a
                    mechanism to configure this feature. In our (CSRs)
                    world probably one of the processors will have
                    access to the associated hardware block, and our
                    debugger will talk to this target to access the
                    feature.<br>
                    <br>
                    So, of course, if non-active target(s) stops whilst
                    stepping/running the active one, some notification
                    needs to be passed up, informing the debug session
                    controller of this, and determining whether or not
                    to switch active target.<br>
                    <br>
                    Greg and Jim both mentioned using the Platform class
                    as the place to implement this kind of thing.
                    However, does the Platform not only deal in
                    homogenous entities? Is it correct to use this
                    concept to control different processor families.
                    With my limited lldb architectural knowledge, I
                    would have thought that the most likely candidate to
                    control this is the Debugger object itself.<br>
                    <br>
                    Matt<br>
                    <br>
                    <br>
                    <br>
                    Colin Riley wrote:<br>
                    Has anybody done any work on integrating features
                    into LLDB to allow for 'meaningful' simultaneous
                    multiple target debugging? There are various
                    scenarios in which this is a very valuable feature:<br>
                    <br>
                    1) coprocessor debugging, in single-process systems
                    (i.e, embedded DSP alongside say a host CPU core)<br>
                    2) graphical debugging, e.g. games: ideally you want
                    to be able to debug the CPU code alongside any GPU
                    workgroups, and have a single interface to any
                    shared resources such as memory.<br>
                    <br>
                    We've done work like this in the past to LLDB, it's
                    not been contributed back because we couldn't do so
                    for commercial reasons (and it's not in a state to
                    contribute back, either). However in the future I
                    think this will become a 'killer app' feature for
                    LLDB and we should be planning to support it.<br>
                    <br>
                    At the moment we can have multiple targets,
                    processes etc running in an LLDB session. However I
                    am failing to see any system for communication and
                    interpretation of multiple targets as a whole. If we
                    take the DSP/CPU situation, I may be watching a CPU
                    memory location whilst at the same time
                    single-stepping through the DSP. It's currently
                    undefined and a bit unknown as to how this situation
                    would work in LLDB as stands. From what I can see,
                    it's quite hard to use the current independent
                    target framework to achieve a meaningful debugging
                    session.<br>
                    <br>
                    It's as though we'd want some sort of session
                    object, that can take multiple targets together and
                    understand how they operate as to achieve some sort
                    of well-defined behaviour in how it's debugged. I.e,
                    in the DSP/CPU scenario, the session object would
                    understand the DSP has access to the CPU memory, and
                    as such, if we're currently on the DSP single
                    stepping, it would allow a CPU watchpoint event
                    through to the DSP session, with an ability to
                    switch target.<br>
                    <br>
                    There are many more items we'd need to allow
                    communication between. A quick example, we have an
                    LLDB version here that supports non-stop mode
                    debugging (see <a moz-do-not-send="true"
href="https://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html"
                      target="_blank">https://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html</a>
                    - and we _will_ contribute this back). At the moment
                    stepping through one thread and a breakpoint happens
                    in another is a bit nasty: LLDB simply switches to
                    whatever thread id is greater. When this sort of
                    usability issue exists in a single-target fashion,
                    we may need to look at extracting this out into some
                    sort of policy system that targets (and, these
                    theoretical session objects) can use to decide how
                    to handle certain event situations.<br>
                    <br>
                    Apologies if this is a bit of a brain dump. It's
                    quite a complex concept, which is why I think
                    dialogue needs to start now as it's something as
                    I've mentioned we are actively doing at Codeplay,
                    but when the time comes to push upstream, want to do
                    so in a way the community thinks is valuable. There
                    may be other viewpoints, like 'super debugservers'
                    that can manage multiple targets and spoof a single
                    target to LLDB, for example.<br>
                    <br>
                    Any other opinions or thoughts out there? :)<br>
                    <br>
                    Colin<br>
                    <br>
                    <br>
                    <br>
                    <br>
                    Member of the CSR plc group of companies. CSR plc
                    registered in England and Wales, registered number
                    4187346, registered office Churchill House,
                    Cambridge Business Park, Cowley Road, Cambridge, CB4
                    0WZ, United Kingdom<br>
                    More information can be found at <a
                      moz-do-not-send="true" href="http://www.csr.com"
                      target="_blank">www.csr.com</a>. Keep up to date
                    with CSR on our technical blog, <a
                      moz-do-not-send="true"
                      href="http://www.csr.com/blog" target="_blank">www.csr.com/blog</a>,
                    CSR people blog, <a moz-do-not-send="true"
                      href="http://www.csr.com/people" target="_blank">www.csr.com/people</a>,
                    YouTube, <a moz-do-not-send="true"
                      href="http://www.youtube.com/user/CSRplc"
                      target="_blank">www.youtube.com/user/CSRplc</a>,
                    Facebook, <a moz-do-not-send="true"
                      href="http://www.facebook.com/pages/CSR/191038434253534"
                      target="_blank">www.facebook.com/pages/CSR/191038434253534</a>,
                    or follow us on Twitter at <a
                      moz-do-not-send="true"
                      href="http://www.twitter.com/CSR_plc"
                      target="_blank">www.twitter.com/CSR_plc</a>.<br>
                    New for 2014, you can now access the wide range of
                    products powered by aptX at <a
                      moz-do-not-send="true" href="http://www.aptx.com"
                      target="_blank">www.aptx.com</a>.<br>
                    <br>
                    _______________________________________________<br>
                    lldb-dev mailing list<br>
                    <a moz-do-not-send="true"
                      href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
                    <a moz-do-not-send="true"
                      href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev"
                      target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
                    <br>
                    <br>
                    <br>
                    -- <br>
                    Todd Fiala |     Software Engineer |     <a
                      moz-do-not-send="true"
                      href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>
                    |     <a moz-do-not-send="true"
                      href="tel:650-943-3180" value="+16509433180"
                      target="_blank">650-943-3180</a><br>
                    <br>
                    _______________________________________________<br>
                    lldb-dev mailing list<br>
                    <a moz-do-not-send="true"
                      href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
                    <a moz-do-not-send="true"
                      href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev"
                      target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
                  </blockquote>
                  <br>
                  <br>
                </div>
              </div>
                To report this email as spam click <a
                moz-do-not-send="true"
href="https://www.mailcontrol.com/sr/7FVfGMSArIjGX2PQPOmvUq10po4Wab0lH8f98+JOKsNlI8w+ITj63RgscvXSUhTVZl0TLhIw4en5pl0FDW8fzw=="
                target="_blank">https://www.mailcontrol.com/sr/7FVfGMSArIjGX2PQPOmvUq10po4Wab0lH8f98+JOKsNlI8w+ITj63RgscvXSUhTVZl0TLhIw4en5pl0FDW8fzw==</a>
              .<br>
            </blockquote>
            <br>
            <br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr">
          <table style="color:rgb(136,136,136);font-family:'Times New
            Roman'" cellpadding="0" cellspacing="0">
            <tbody>
              <tr
                style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
                <td
style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px"
                  nowrap="nowrap">Todd Fiala |</td>
                <td
style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"
                  nowrap="nowrap"> Software Engineer |</td>
                <td
style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"
                  nowrap="nowrap"> <a moz-do-not-send="true"
                    href="mailto:tfiala@google.com"
                    style="color:rgb(17,85,204)" target="_blank"><span
                      style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial
                      initial">tfiala@google.com</span></a> |</td>
                <td
style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"
                  nowrap="nowrap"><font color="#1155cc"> <a
                      moz-do-not-send="true">650-943-3180</a></font></td>
              </tr>
            </tbody>
          </table>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
- Colin Riley
Games Technology Director

Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: <a class="moz-txt-link-freetext" href="http://www.codeplay.com">http://www.codeplay.com</a>
Twitter: <a class="moz-txt-link-freetext" href="https://twitter.com/codeplaysoft">https://twitter.com/codeplaysoft</a>

This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY </pre>
  </body>
</html>