[Dwarf-discuss] Referring to the stdin 'file' in .debug_macinfo sections

[Michael Eager]

Ron 603-884-2088 wrote:
> Matthew.Gretton-Dann at arm.com wrote:
> 
>>Section 6.3.2 of the DWARF3 standard states:
>>
>>      ...If the base source file for a compilation is submitted to the
>>       compiler via some means other than via a named disk file (e.g.
>>       via the standard input stream on a UNIX system) the the compiler
>>       should still produce this matched pair of DW_MACINFO_start_file
>>       and DW_MACINFO_end_file entries for the base source file,
>>       however, the file name indicated (indirectly) by the
>>       DW_MACINFO_start_file entry of the pair should designate a line
>>       number information file name entry consisting of a null string.
>>
>>What does the DWARF standard mean by the phrase 'a null string'?
>>
>>My initial interpretation is that this means a string of length zero. 
>>However, section 6.2.4 item 11 (file_names) indicates that
>>for the table of files:
>>       
>>       ...The last entry is followed by a single byte.
>>
>>This means that my interpretation of 'a null string' means that the
>>file_names entry will get misinterpreted as the end of the file_names
>>array and confuse the .debug_line state machine.
>>
>>If my understanding is correct above then there are three options open
>>to us:
>>
>>    1. Use File ID 0 as a 'special' ID representing stdin
>>    2. Use File ID (last + 1) as a 'special' ID representing stdin
>>    3. Use DW_LNE_define_file to define a file with a zero-length null
>>       name.
>>
>>Of these the third option is (the only?) one which meets with the
>>current specification's requirements.
>>
>>Have I interpreted the standard correctly?  If so should option 1 or 2
>>be made legal (I would suggest not)?  In any event does the standard
>>need some clarification?
> 
> 
> I believe you have interpreted the standard correctly.
> 
> I have confirmed that GEM-based compilers on Alpha Linux do fall into
> the trap of generating a null file name that gets misinterpreted as the
> end of list marker.
> 
> It would be interesting to hear how other implementations handle this.
> 
> Recommending use of DW_LNE_define_file feels like a very heavyweight
> solution. But I don't have a good alternative to suggest at the moment.
> A not so good alternative is
> 
>       4. Specify that a null byte that is not the last byte of the
>          prologue according to the length field at the beginning of
> 	 the prologue is a null file name rather than an end-of-list
> 	 marker. [Probably makes it very hard to ever extend the
> 	 contents of the prologue...]
> 
> Hmmm, mumble, grumble...

Yucka.  How about a dummy file name to represent stdin?  Like "-"?
Requires changes to both compilers and debuggers to recognize this,
but they were likely not handling it correctly before. :-)


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