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

[Ron 603-884-2088]

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...

Ron