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

[Chris Quenelle]

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.  :-)
I'm not trying to be flippant here, I think I'm suggesting a much better 
design
that will be easier to implement and maintain over time.

--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
> 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/f3f80fd6/attachment.htm>