<div dir="ltr">I don't understand the use case and reasons to blame PTXAS compiler here.<div><span style="font-size:12.8px"><br></span></div><div><i><span style="font-size:12.8px">>>a) Supports DWARF-2 only.</span><br></i></div><div><b>What would you like to achieve with DWARF-3+ that you cannot do with DWARF2?</b></div><div><br></div><div><i>>><span style="font-size:12.8px"> </span><span style="font-size:12.8px">b) Labels are allowed only in code section (only in functions).</span></i></div><div><b>What is the use case here which needs labels outside functions?</b></div><div><br></div><div><i>>>><span style="font-size:12.8px">c) Does not support label arithmetic in DWARF sections.</span></i></div><div><span style="font-size:12.8px"><b>Same. Please explain use case.</b></span></div><div><span style="font-size:12.8px"><br></span></div><div><div><i><span style="font-size:12.8px">d) Debug info must point to the sections, not to labels inside these </span><span style="font-size:12.8px">sections.</span><span style="font-size:12.8px"><br></span></i></div><div><i><span style="font-size:12.8px">e) Sections itself must be </span>enclosed into<span style="font-size:12.8px"> braces</span><br></i></div></div><span style="font-size:12.8px"><i>> “.section .debug_info {…}”</i></span><div><span style="font-size:12.8px"><i><br></i></span></div><div><span style="font-size:12.8px"><b>Again, why is this a limitation?</b></span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div><i><span style="font-size:12.8px">>>></span><span style="font-size:12.8px">> i) .debug_frame section is emitted by txas compiler.</span></i></div><i><span style="font-size:12.8px">> DW_AT_frame_base must be set to dwarf::DW_FORM_data1</span><br style="font-size:12.8px"><span style="font-size:12.8px">> dwarf::DW_OP_call_frame_cfa value.</span><br style="font-size:12.8px"><span style="font-size:12.8px">I doubt that's a problem.</span></i><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><b>Why is this a problem?</b></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 7, 2017 at 1:33 AM, Alexey Bataev via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">06.11.2017 14:56, Robinson, Paul пишет:<br>
<div><div class="h5">>> Hi everybody,<br>
>> As you know, Cuda/NVPTX target has very limited support of the debug<br>
>> info in Clang/LLVM. Currently, LLVM supports only emission of the line<br>
>> numbers debug info.<br>
>> This is caused by limitations of the Cuda/NVPTX codegen. Clang/LLVM<br>
>> translates the source code to LLVM IR, which is then lowered to PTX<br>
>> (parallel thread execution) intermediate file. This PTX file represents<br>
>> special kind of the assembler code in text format, which contains the<br>
>> code itself + (possibly) debug info. Then this PTX file is compiled by<br>
>> ptxas tool into the CUDA binary representation.<br>
>><br>
>> Debug info representation in PTX file.<br>
>> ========================<br>
>> According to PTX Writer's Guide to Interoperability, Debug information<br>
>> (<a href="http://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/index.html#debug-information" rel="noreferrer" target="_blank">http://docs.nvidia.com/cuda/<wbr>ptx-writers-guide-to-<wbr>interoperability/index.html#<wbr>debug-information</a>)<br>
>> , debug information must be encoded in DWARF (Debug With Arbitrary<br>
>> Record Format). The responsibility for generating debug information is<br>
>> split between the PTX producer and the PTX-to-SASS backend. The PTX<br>
>> producer is responsible for emitting binary DWARF into the PTX file,<br>
>> using the .section and .b8-.b16-.b32-and-.b64 directives in PTX. This<br>
>> should contain the .debug_info and .debug_abbrev sections, and possibly<br>
>> optional sections .debug_pubnames and .debug_aranges. These sections<br>
>> are standard DWARF2 sections that refer to labels and registers in the<br>
>> PTX.<br>
>><br>
>> The PTX-to-SASS backend is responsible for generating the .debug_line<br>
>> section from the .file and .loc directives in the PTX file. This<br>
>> section maps source lines to SASS addresses. The PTX-to-SASS backend<br>
>> also generates the .debug_frame section.<br>
> All this sounds like the standard division of responsibilities between<br>
> an LLVM code generator and the assembler.<br>
><br>
>> LLVM is able to emit debug info in DWARF. But ptxas compiler has some<br>
>> limitations, that make it hard to adapt LLVM for correct emission of<br>
>> the debug info in PTX files.<br>
>><br>
>> Limitations/features of the PTX format/ptxas compiler.<br>
>> ==============================<wbr>====<br>
>> a) Supports DWARF-2 only.<br>
> IIRC, Darwin had a similar restriction until recently.<br>
><br>
>> b) Labels are allowed only in code section (only in functions).<br>
> If you have static/global variables, I guess their locations would<br>
> have to be described using a section+offset expression? Normally<br>
> we emit a location attribute that is just a reference to a label<br>
> for the variable.<br>
><br>
>> c) Does not support label arithmetic in DWARF sections.<br>
>> “.b32 L1 – L2” as the size of the section is not allowed, so the<br>
>> sections sizes should be calculated explicitly.<br>
> MachO has a similar restriction, this should not be a problem if you<br>
> can do something like:<br>
> L3 = L1 - L2<br>
> .b32 L3<br>
</div></div>Nope, it is not supported<br>
<div class="HOEnZb"><div class="h5">>> d) Debug info must point to the sections, not to labels inside these<br>
>> sections.<br>
>> “.b32 .debug_abbrevs”<br>
> Offhand for DWARF-2 I can't think of a reference that couldn't be done<br>
> this way.<br>
><br>
>> e) Sections itself must be enclosed into braces<br>
>> “.section .debug_info {…}”<br>
>> f) Frame info is non-register based<br>
>> Based on function local “__local_depot” array, that represents the<br>
>> stack frame.<br>
>> g) All variables must have non-standard DW_AT_address_class attribute<br>
>> so the debuger had the info about address class of the variable -<br>
>> global or local. DWARF standard does support this attribute, but it can<br>
>> be appiled to pointer/reference types only, not variables.<br>
> For variables it would be more usual to use DW_AT_segment for this.<br>
> But that's an agreement that the compiler and debugger need to reach.<br>
><br>
>> h) The first label in the function must follow the debug location macro.<br>
>> In LLVM, it is followed by the debug location macro.<br>
> I am not 100% sure what you mean by this, but I think it has to do with<br>
> the fact that LLVM attaches locations to instructions, not labels. It<br>
> might or might not be easy to work around this; there might be an<br>
> unfortunate interaction with how emitting line-0 records works.<br>
><br>
>> i) .debug_frame section is emitted by txas compiler.<br>
>> DW_AT_frame_base must be set to dwarf::DW_FORM_data1<br>
>> dwarf::DW_OP_call_frame_cfa value.<br>
> I doubt that's a problem.<br>
><br>
>> j) Strings cannot be referenced by the labels, instead they must be<br>
>> inlined in the sections in form of array of chars.<br>
> LLVM used to do inline strings, but switched to the .debug_str section<br>
> quite a while ago. On the other hand, I spent a little time maybe a<br>
> year ago looking into whether we could emit short strings inline as a<br>
> space-saving measure, and decided it was feasible. (I didn't do it<br>
> because the space savings was really trivial.) So I think doing this<br>
> would not be terribly hard.<br>
><br>
>> Some changes in LLVM are required to support all these<br>
>> limitation/features in the output PTX files.<br>
>> Required changes in LLVM.<br>
>> ==================<br>
>> •include/llvm/CodeGen/<wbr>AsmPrinter.h.<br>
>> •Add “virtual MCSymbol *getFunctionFrameSymbol(const<br>
>> MachineFunction *MF) const” for non-register-based frame info.<br>
>> •Override “NVPTXMCAsmPrinter.cpp” to return the name of the<br>
>> “__local_depot” frame storage.<br>
>> •Add ”cuda-gdb” specific tuning.<br>
> Note that our design philosophy for "tuning" is that a tuning option<br>
> unpacks into other separate flags. Not a problem, just an observation.<br>
><br>
>> •Inlined strings must be used in sections, not string references.<br>
>> •Label arithmetic is replaced by the absolute section size<br>
>> evaluation.<br>
> This one isn't a debug-info tuning decision, it's how your assembler works<br>
> and so is a target decision.<br>
><br>
>> •Use “AsmPrinter::doInitialization(<wbr>)” instead of NVPTX-custom manual<br>
>> initialization.<br>
>> •Local variables address emitted as “__local_depot” + <var offset>.<br>
>> •Add NVPTX specific “NVPTXMCAsmStreamer” class.<br>
>> •Requires moving to includes of “MCAsmStreamer” class declaration.<br>
>> •Overrides emission of the labels (names of the section are emitted<br>
>> instead).<br>
>> •Overrides emission of the sections (emit braces)<br>
>> •Overrides string emission (as sequence of bytes, not as strings)<br>
>> •Overrides emission of files/locations debug info<br>
>> Required changes in Clang.<br>
>> =================<br>
>> •Add option “-gcuda-gdb” to driver.<br>
>> •Emit cuda-gdb compatible debug info (DWARF-2 by default + CudaGDB<br>
>> tuning).<br>
>> •Add options “-g --dont-merge-basicblocks --return-at-end” to “ptxas”<br>
>> call.<br>
>> •ptxas is able to translate debug information only if -O0<br>
>> optimization level is used. It means, that we can use optimization<br>
>> level in LLVM > O0, but still have to use O0 when calling ptxas<br>
>> compiler.<br>
>><br>
>> This approach was implemented in <a href="https://github.com/clang-ykt" rel="noreferrer" target="_blank">https://github.com/clang-ykt</a> to support<br>
>> debug info emission for NVPTX target when generating code for OpenMP<br>
>> offloading constructs. You can try to use it.<br>
> I haven't looked at your code but all the things you describe seem<br>
> reasonably feasible. Certainly the details of what you want to do<br>
> to the emitted DWARF are fine; I am less sure about the assembler<br>
> details, but if you have a worked example that makes it likely that<br>
> part is okay as well.<br>
> --paulr<br>
><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><i style="font-size:12.8px">Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this mail are of my own and my employer has no take in it. </i><br></div><div>Thank You.<br>Madhur D. Amilkanthwar<br><br></div></div></div>
</div>