[Dwarf-Discuss] How best to represent multiple programs in a single file...

[Relph, Richard]

Chris,
    Thanks for the reply. We have considered this approach, but it has thus far been rejected for various reasons. Ultimately, what you suggest ends up producing a separate ELF with DWARF for each kernel, which has the obvious advantage of being easy to prove works. But OpenCL treats a compilation of a set of kernels as a unit, so we'd have to design a mechanism to put multiple ELFs in to a single bundle, which we've so far been reluctant to do.
Richard

From: Chris Quenelle [mailto:chris.quenelle@oracle.com]
Sent: Tuesday, January 04, 2011 10:15 AM
To: Relph, Richard
Cc: DWARF
Subject: Re: [Dwarf-Discuss] How best to represent multiple programs in a single file...

My advice is to modify the compiler so it takes the name of a kernel
routine on the command line and only generates the code
that's necessary for that kernel.  Then invoke the compiler once
for each kernel routine using the same source file each time.
You didn't say if all the source is in one file. If you are combining
multiple OpenCL source files, then the modifications to the compiler
are more involved, but still easier than trying to parse, read and rewrite
dwarf information that corresponds to a subset of the original program.  :-)

--chris



On Monday January 3    4:41PM, Relph, Richard wrote:
Our platform allows the creation of a single ELF file that contains multiple 'programs' derived from the same set of source files. We're trying to figure out the best way to represent this in DWARF. We've thought about creating separate sets of DWARF sections for each 'program' (say, .debug_info_programA, etc.), but this would render most DWARF processing tools useless. Yet it isn't obvious to me how to stuff multiple program's worth of DWARF info using just the one set of standard DWARF sections.

For the technically curious, here's the details:

Our platform is a GPU. Each program is loaded on to the hardware fresh, from 'outside', by an 'external' OS, if you will. When the GPU starts executing, it starts from address 0, where we have placed a bootstrap sequence that ends up calling the real code. The real code's source language is OpenCL, which doesn't define a solitary entry point function such as main(), but rather defines a 'kernel' attribute that can be attached to any function. The host code (running on the CPU controlling the GPU) specifies which kernel function to execute at run-time.

Because our GPU doesn't have a 'real' CALL instruction, we essentially treat each 'kernel' function as a complete program in and of itself (ALL functions called by the kernel are inlined by the compiler.) So a single OpenCL source file might have (pseudo-code):

kernel foo() {
    A();
    B();
}

kernel bar() {
    B();
    C();
}

A() {...}
B() {...}
C() {...}

The compiler is invoked once for the source file, producing code and DWARF information for the entire compilation unit. If only that was the end...
But because we don't want the resources utilized by kernel bar() to interfere with resource allocation for kernel foo() (and vice-versa), we post-process this, stripping unused kernels and other dead code and data, producing separately loadable code for each kernel. Each separately loadable kernel is then stored in the ELF for execution when the host program requests it.

The question at hand is how to represent the DWARF information for each separately loadable kernel. We'd like a solution that allows libdwarf, objdump, readelf, dwarfdump, etc. to continue to work, which says we need to put multiple 'programs' worth of debug data in each DWARF section. But then how do the tools (and the debugger) differentiate between data relevant for B() in the context of kernel foo() from B() in the context of kernel bar()?

Any thoughts, comments, suggestions, proofs that it can or cannot work, would be gratefully accepted.

Thanks,
Richard





_______________________________________________

Dwarf-Discuss mailing list

Dwarf-Discuss at lists.dwarfstd.org<mailto:Dwarf-Discuss at lists.dwarfstd.org>

http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20110104/4d9e0461/attachment.htm>