The DWARF information that fpc generates (.debug_line) does not encode the file
and directory names correctly as defined by the DWARF spec.  This confuses
consumers like a debugger, and confuses the debugedit program that is used in
rpm builds.

The DW_AT_comp_dir attribute is being used entirely incorrectly.
It's sometimes "" and otherwise a relative directory name in fpc's output.
The spec says that this must be the current directory that the compiler runs in,
i.e. what it gets for getcwd().  Relative names in the directory and file table
refer to this to produce the complete name.

The directory table as produced has a few problems.
DWARF specifies that the table lists exactly all the directories that are
searched for included source files, i.e. for the analog of #include "file". 
This includes the directories specified with the equivalent of cc's -Idir, as
well as system-default directories analogous to C's /usr/include et al.  If a
directory name is relative it's resolved relative to DW_AT_comp_dir.
I can't tell, but it looks like maybe the first of these is going into
DW_AT_comp_dir in some cases.  Anyway, it's not clear the right list is here.
Secondly, the directory names in the table have a trailing slash; this is not a
violation of the DWARF spec, but it's not the way it's usually done, and
debugedit canonicalizes the names to remove it anyway.  You really should avoid
putting a trailing / or a leading ./ on directory names, unless the user really
specified it that way.