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

Jason Molenda
2004-03-05T23:02:35Z

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