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.
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).
Jonas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
