[Reproducible-builds] Minimising work needed for this build-path issue

[HW42]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 825 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160905/a1e9b3d5/attachment.sig>