dwarf from nvcc

I've add some support of DWARF debug info from nvidia nvcc to my dwarfdump. As everyone knows dwarf is over-complicated, fat and just disgusting - however, nvidia was able to take his nausea to a new level

relocs

their cuda-gdb does not contains reloc_howto_type for CUDA relocs - it's special kind of bare minimal open-source when they publish as little code as possible. So my implementation highly likely incomplete and wrong

locations

stored in section .debug_loc - that's ok, although the last time gсс used them was somewhere around the time of version 4. Also nvidia introduced new attribute DW_AT_address_class for addresses in different segments. Cool, but for example for ADDR_const_space you can't get in which constant bank those address was placed

register names

this is main nightmare
They stored in location lists names of PTX registers - and even not as string - as ULEB128 number

Then they have special section .nv_debug_info_reg_sass to remap them in physical SASS registers. See details in cuda/cuda-regmap.c:

The PTX to SASS register map table is made of a series of entries, one per function. Each function entry is made of a list of register mappings, from a PTX register to a SASS register. The table size is saved in the first 32 bits.

     | fct name | number of entries |
       | idx | ptx_reg | sass_reg | start | end |
       | idx | ptx_reg | sass_reg | start | end |
       ...
       | idx | ptx_reg | sass_reg | start | end |
     | fct name | number of entries |
       | idx | ptx_reg | sass_reg | start | end |
       ...
     ...

Let's say it as slowly as possible, syllable by syllable:

1. location list already has range of addresses for PTX register
2. then you must find in .nv_debug_info_reg_sass right function by name
3. then name of ptx_reg
4. there may be arbitrary number of ranges
5. and they may not intersect with the range from location in any way
   

At this point I gave up 

PS: there is also undocumented section .nv_debug_info_reg_type