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

[Michael Eager]

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.

A couple questions:

How is this ELF executable file organized?

How are these "multiple programs" represented in the executable file?

How are these "separately loaded kernels" selected and loaded?

DWARF doesn't depend on any particular program structure.  There is
no requirement to have a main() function or a single entry point.
It would seem that the DWARF data for your program, with multiple
"kernels", should describe them  correctly.  Of course, when the ELF
file is modified to strip out code, you need to make the corresponding
changes to the DWARF data as well.



-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077