Ximin Luo: > HW42: >> Ximin Luo: >>> [..] >>> >>> 1. Patch GCC to set debug-prefix-map to "$pwd=." by default (and the >>> analogue for other languages / tools). >>> >>> This behaviour is concretely different from the current situation: >>> during recursive-make scenarios, the gcc in subdirectories will have >>> different values for debug-prefix-map. Our current situtation OTOH is >>> that dpkg-buildflags is called once at the top-level directory, and >>> this value persists for all gcc subchildren for the whole build >>> (unless the upstream buildscripts do something weird to CFLAGS). >>> >>> If the behaviour were not different, I would strongly suggest "let's >>> just do this". But it's different, and I'm not sure what consequences >>> that would have. I'm looking for your comments on this. >> >> I think this breaks the mapping to the source file, for example in gdb. >> So I think this is not a good solution. >> > > Yeah, this is what I was worried about, but my background knowledge > here isn't good enough to be sure. Do you know where I could read up > on how this all works?
Sorry I have currently no link handy. But the process for C is not very complex: When loading a file gdb tries to load the debug symbols from the binary itself or else from a well known location (/usr/lib/debug/.build-id/...) Without them gdb can't resolve symbols. (Output shortened) $ gdb apt Reading symbols from apt...(no debugging symbols found)...done. (gdb) p main No symbol table is loaded. Use the "file" command. After installing the debug symbols gdb will load the debug symbols and can resolve symbols. The debug symbols contain a reference (file path and line number) to the source. When printing the source gdb search for this file based on the working directory (and those passed by --directory). So without installed soure it prints an error message. $ sudo apt-get install apt-dbgsym $ gdb apt Reading symbols from apt...Reading symbols from /usr/lib/debug/.build-id/63/7ee005a89714dd26a13f950028c6febd13c28f.debug...done. done. (gdb) p main $1 = {int (int, const char **)} 0x1680 <main(int, char const**)> (gdb) l main 94 ./cmdline/apt.cc: Datei oder Verzeichnis nicht gefunden. When you now put the source (or at least some text file ;P) in the right path, gdb will print it for you. $ apt-get source apt && cd apt-*/ $ gdb apt (gdb) l main 96 } 97 /*}}}*/ 98 int main(int argc, const char *argv[]) /*{{{*/ 99 { 100 CommandLine CmdL; 101 auto const Cmds = ParseCommandLine(CmdL, APT_CMD::APT, &_config, &_system, argc, argv, &ShowHelp, &GetCommands); >>> Note that for languages that define "the path is the namespace" like >>> golang or java, this does not really matter. So in these cases I >>> strongly suggest patching the tool itself, instead of adding extra >>> command-line flags. >> >> Could you clarify what you mean? I don't think the namespace and the >> path are the same in golang or in Java (sure, the namespace is the >> suffix of the path but including java.nio.file.Path into the binary >> doesn't break any of our assumptions). >> > > What I meant more specifically is that, either there is only one > source root (GOPATH) or different source roots are not generally > expected to be children of each other (in the directory tree of a > source repo written in that language). For example one never sees a > Java project with src/com/google and src/com/google/org/apache, but > it's fairly common to see C/C++ projects with src/a/*.c treating src/a > as the include-root, but with src/a/1/*.c treating src/a/1 as the > include-root, yet with src/a/2/*.c treating src/a as the include-root. > > With the former, it's fairly easy for a debugger to see that src/ is > the source root. And I'm guessing the latter case is what would mess > with gdb's source-file mappings if we went with (1). But it would be > good to have someone explain this in more detail. Ah I now get your point. Yes for those cases we don't need an extra SOURCE_ROOT (or w/e). In go $GOPATH/src and in java -sourcepath, etc. can be used as base for source paths.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds