On Wed, 26 Mar 2014, Jonas Maebe wrote:
On 26/03/14 17:23, Michael Van Canneyt wrote:
At the very least I think that we should be consistent and use the same
filenames in link script and debug info ?
How directories are stored in the debug info is generally defined by the
debug info format itself. E.g. the DWARF standard explicitly mentions that
search directories for source files can be either relative or absolute to the
current working directory (there's even an attribute to specify a default
CWD, so that the files can be easily found on the compilation system itself
even when the program is started from another location). Specifying the
directories in a relative way means that you can easily copy over a debug
binary and all related source code from one system to another (or move things
around) without breaking anything. For that reason, we explicitly add
relative directory names to the DWARF debug info rather than absolute ones.
As I wrote to Tomas:
This assumes that the directory structure on the other system is identical.
An assumption that doesn't hold between e.g. 64-bit debian and fedora.
But I am not asking to change the way things are done unconditionally,
I understand your reasoning.
For linking, we use absolute paths in link.res to ensure that the parameters
given by the programmer to the compiler (such as -Fl and -XR) are taken into
account when linking, and that the linker doesn't accidentally link in some
other library with the same name that it found in its default search path.
I don't see what the advantage of being "consistent" between the generation
of debug info and linker scripts would be. Making the paths in the debug info
absolute would make things less flexible without increasing usability (I've
never seen bug reports about problems with the wrong source files being
found). Making the paths in the linker script relative would add a lot of
complexity (the compiler first searches for the library files on the files
system, and then it would have to make the paths relative to the CWD for no
gain) and special cases (when linking on a remote system, the compiler has no
clue about what the relative position of e.g. /usr/lib will be compared to
the CWD, so then you would still have to use absolute paths).
The problem is easy to reproduce, as Mattias demonstrated.
During debugging, Lazarus consistently opens a file twice (or doesn't find it at all)
when symlinks are used in the path to the project file, because there is a mismatch
between the relative path as lazarus sees it (logical), and the relative path as FPC
sees it (physical), and lazarus uses the debug info to open the file.
That's what started this whole thread.
Specifying source files in the debug info using full paths would solve the
issue.
I'm not advocating to always do this, I understand your reasoning for having
the current behaviour.
I'm advocating to make this behaviour configurable:
Most people do not copy the files to another system to debug, for them the
current exercise is pointless.
I suspect much more people use symlinks, for them it would be a convenience to
have everything absolute.
It would avoid problems. You have the names in absolute form available anyway
(for the linker), so it should
not be a major problem to make the behaviour configurable.
The alternative is that Lazarus also resolves the directory of the project, as
FPC does.
(It probably needs to resolve all other files in the process, which is a big effort,
but that is conjecture on my part)
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
