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

Relph, Richard Richard.Relph@amd.com
Tue Jan 4 00:41:51 GMT 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20110103/762191c5/attachment.htm>



More information about the Dwarf-discuss mailing list