I added those maps to work around what turned out to be a deficiency in
elftoolchain libdwarf which manifested in addr2line's use of
dwarf_srclines(3). This change fixes the deficiency and removes the
Basically, each CU contains a table of file names (mostly headers)
referenced in the associated line number information. Each entry in the
file name table references an entry in the directory table;
concatenating the directory and file strings may give an absolute path
or a relative path. The CU also contains a DW_AT_comp_dir attribute,
the compilation directory.
Consider an autogenerated header, vnode_if.h, referenced by a CU.
Without the debug map for ".", there exists a file table entry,
"vnode_if.h", which references "." since that was the include path used
to find vnode_if.h. Thus, libdwarf internally caches "./vnode_if.h",
and if any PCs map to lines in that file, addr2line prints
"./vnode_if.h". Binutils addr2line on the other hand prints
"$OBJDIR/./vnode_if.h". That is, it prepends the compilation directory
to a relative path in the directory table, which I think is a reasonable
thing to do. The change just implements this logic.