[Dwarf-Discuss] Register kinds

John DelSignore John.DelSignore at roguewave.com
Mon Nov 1 09:49:30 PDT 2010


Michael Eager wrote:
> Relph, Richard wrote:
> 
>>     This is an abstraction of the capabilities of AMD GPUs. The IL is 
>> itself compiled to machine code by a shader compiler (a version of which 
>> is also used for OpenGL and Direct X.) We’re defining the debug layer at 
>> the IL stage to support multiple different GPU architectures. 
> 
> 
>>     It’s the theoretically unbounded nature of the IL GPRs that is 
>> giving me fits at the moment.
> 
> If registers in the IL are subsequently mapped to
> actual hardware registers, these are the ones that
> should be listed in the DWARF data.  How do you
> plan to relate the IL registers to the hardware
> registers?
> 
> DWARF is intended to provide a description of the
> mapping between the source and the executable code
> which runs on the hardware.  If you are planning on
> using DWARF to describe the mapping between source
> and an intermediate language, you are heading off
> into unexplored territory.

Though I wouldn't say completely "unexplored territory"...

I've seen platforms that encode an IL register as a number that is actually a string. For example, the IL names the register something like "%r1", and encodes that as a register number using the ASCII character values of the string, for example, '%'==0x25, 'r'==0x72, '1'==0x31 shows up as DWARF register 0x257231. The debugger is supposed to take the number, convert it back to a string, and pass the string and the PC of the thread into a debugging API function that converts them into a hardware register number. Funky, but it works.

The key here is that the debugger must use a runtime mapping from the register number "cookie" that's dropped into the DWARF to the real hardware register number. In fact, at runtime, the cookie might map to a hardware register, a memory address, or nowhere, depending on the thread's PC value and the type of hardware installed in the system.

Cheers, John D.


>  I suspect that there are
> many areas where DWARF does not provide sufficient
> information to describe an intermediate language
> which is later translated into machine language.
> 



More information about the Dwarf-Discuss mailing list