<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 11:25 AM, Matt Arsenault <span dir="ltr"><<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 07/31/2015 10:12 AM, David Blaikie
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Fri, Jul 31, 2015 at 9:59 AM, Matt
            Arsenault <span dir="ltr"><<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF"><span>
                  <div>On 07/31/2015 06:46 AM, Robinson, Paul wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The



                        debug info generally should be mapping the
                        source to the code/data as actually generated,
                        even after optimizations shuffle things around.
                        If the original code thinks it's allocating
                        something in AS 0 but optimization puts it in AS
                        3, and the user asks the debugger to display the
                        value, how does the debugger know to look in AS
                        3?  Asking the debugger to troll around looking
                        for an instruction that it might guess is
                        loading/storing the value and assuming that
                        address is the actual location… seems like
                        asking a bit much.</span></p>
                    <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr</span></p>
                    <p class="MsoNormal"><a name="14ef4cfbe7bfa47e_14ee50e3c103ca21__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
                  </blockquote>
                </span> It seems like a single attribute for the debug
                address space isn't enough then to describe both.</div>
            </blockquote>
            <div><br>
            </div>
            <div>Why do you need to describe the original address space,
              rather than only the one where the value actually resides?
              What would the debugger use this information for? Does
              this need to be rendered to the user? For what reason?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Yes, it should be shown to the user. It's part of the variable the
    source declared, just like the type name. In OpenCL it has a lot of
    consequences for how that variable behaves w.r.t. synchronization
    issues and other things. Although this leads me to another question
    for the clang component emitting it, whether the source address
    space ID as defined by clang should be emitted for this attribute,
    or the target mapped address space ID. Since these all end up as 0
    on x86 for example, it probably should be the clang source ID in
    that case.<span class=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
              (hmm, speaking of which - perhaps this shouldn't be an
              attribute on the variable, but instead part of the DWARF
              expression describing the location of the value? If it's
              possible that optimizations would put the value in one
              location with one address space at point A, and a
              different location in a different address space at point
              B)</div>
            <div> <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    I don't know much about DWARF. I don't think there's any reason why
    a value would be duplicated into two different address spaces.<br>
    <br>
    I just checked the spec again and the description of
    DW_AT_address_class seems vague on what it is meant for. It says
    "DW_AT_address_class attribute to describe how objects having the
    given pointer or reference type ought to be dereferenced." which
    seems to not be describing what the source looks like.<br></div></blockquote><div><br></div><div>DWARF is somewhat intentionally vague.<br><br>Let's start here: Why are you implementing this? Do you have users filing bugs about sub-optimal debugging behavior? Have you observed same? Does this patch help/address that behavior?<br></div><div> </div></div><br></div></div>