On Mon, 2017-07-17 at 17:28 +0000, Sasha Da Rocha Pinheiro wrote:
> I understand your argument. Since I was doing:
>    
>    dwarf_getsrclines(&cuDIE, &lineBuffer, &lineCount)
>    dwarf_getsrcfiles(&cuDIE, &files, &filecount)
> 
> I knew they were related because I used the same DIE. But someone
> trying to use a function which returns only the index could be
> confusing about what Dwarf_Files it came from. 
> 
> But, with
> 
> extern int *
> dwarf_line_files (Dwarf_Line *line, Dwarf_Files **files, size_t *idx);
> 
> they would know what Dwarf_Files the line is related to. For me,
> though, I could pass NULL for files, since I already knew what it is.

I would always double check your assumption that the Dwarf_Files match
with what you expect. And I am still not really convinced storing the
index as a proxy for the actual file name/path associated with a
Dwarf_Line is really a good idea.

But I was working on adding support for DWARF5 .debug_lines and since
files (and directories) can have arbitrary attributes in that version it
makes sense to go from Dwarf_Line to the associated Dwarf_Files/index.
Instead of duplicating the accessor functions (like we now have both
dwarf_filesrc and dwarf_linesrc).

Note that I changed the name to dwarf_line_file. (Dropping the s.)

This does show that we might want to change how we internally store the
Dwarf_Files though. Currently we resolve the whole file path immediately
and don't keep track of the original file name and directory name/path.
You can only get the full file path (through dwarf_filesrc) but not the
associated directory. I am cleaning that up while adding the DWARF5
support. And will add a more generic interface for access file and
directory properties.

Cheers,

Mark