Re: -file-list-exec-source-files

[Jason Molenda <jmolenda@apple.com>]

Hi Elena,


On Mar 5, 2004, at 2:31 PM, Elena Zannoni wrote:

>> @@ -1254,6 +1255,8 @@
>>  				  objfile->global_psymbols.next,
>>  				  objfile->static_psymbols.next);
>>
>> +      pst->dirname = xstrdup ( comp_unit_die.dirname );
>> +
>>        pst->read_symtab_private = (char *)
>>  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct 
>> dwarf2_pinfo));
>>        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
>> @@ -4326,6 +4329,10 @@
>>  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
>>  	  if (part_die->name == NULL)
>>  	    part_die->name = DW_STRING (&attr);
>> +	  break;
>> +	case DW_AT_comp_dir:
>> +	  if (part_die->dirname == NULL)
>> +	    part_die->dirname = DW_STRING (&attr);
>
> The dwarf2 specs say that the name is in the form ":pathname" or
> "hostname:pathname". Should we worry about the hostname? Does gcc emit
> that?  I have looked at a few executables and didn't see the hostname
> part.


Oh that the DWARF spec were this cut-and-dried. :-)  DWARF3 draft 8 says


A DW_AT_comp_dir attribute whose value is a null-terminated string 
containing the current working directory of the compilation command 
that produced this compilation unit in whatever form makes sense for 
the host system.

The suggested form for the value of DW_AT_comp_dir attribute on UNIX 
systems is "hostname:pathname".  If no hostname is available, the 
suggested form is ":pathname".


gcc puts the output of getpwd() into DW_AT_comp_dir.  Obviously the 
spec allows this.  I suppose a consumer must be prepared to handle any 
one of

   /path/to/file
   :/path/to/file
   hostname:/path/to/file
   C:/path/to/file
   hostname:C:/path/to/file

And I wonder what should be done if one of the directory names contains 
a ":".  /path/to:haha/file is clearly ambiguous -- a producer could 
disambiguate by always prepending a ":", but the consumer has no way of 
knowing what it might be receiving.  Quite a sticky wicket.


J