Re: [PATCH] PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

Richard Biener: > On Mon, Oct 17, 2016 at 11:44 PM, Mike Stump <mikest...@comcast.net> wrote: >> On Oct 17, 2016, at 2:38 PM, Ximin Luo <infini...@pwned.gg> wrote: >>> >>> Mike Stump: >>>> On Oct 17, 2016, at 11:00 AM, Ximin Luo <infini...@

Re: [PATCH] PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

Mike Stump: > On Oct 17, 2016, at 11:00 AM, Ximin Luo <infini...@pwned.gg> wrote: >> Therefore, it is better to emit it in all circumstances, in case the reader >> needs to know what the working >> directory was at compile-time. > > I can't help but wonde

[PATCH] PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

(Please keep me on CC, I am not subscribed) In working on another patch for DW_AT_comp_dir behaviour, I tried to write a test for that other patch. This test did not work as expected - DW_AT_comp_dir was not even generated in the resulting output! But this had nothing to do with my patch so I dug

Re: [PATCH] PR77985: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

Richard Biener: > On Fri, Oct 21, 2016 at 12:56 PM, Ximin Luo <infini...@pwned.gg> wrote: >> Richard Biener: >>> On Tue, Oct 18, 2016 at 2:35 PM, Ximin Luo <infini...@pwned.gg> wrote: >>>> >>>> Thanks, I'll add the Changelog entry. My com

Re: [PATCH] PR77985: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

Richard Biener: > On Mon, Oct 24, 2016 at 12:53 PM, Ximin Luo <infini...@pwned.gg> wrote: >> Richard Biener: >>> On Fri, Oct 21, 2016 at 12:56 PM, Ximin Luo <infini...@pwned.gg> wrote: >>>> Richard Biener: >>>>> On Tue, Oct

Re: [PATCH] PR77985: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

Richard Biener: > On Tue, Oct 18, 2016 at 2:35 PM, Ximin Luo <infini...@pwned.gg> wrote: >> >> Thanks, I'll add the Changelog entry. My computer isn't very powerful, so I >> didn't bootstrap it yet, I only tested it on a stage1 compiler, on Debian >> test

Re: [PATCH] Generate reproducible output independently of the build-path

Joseph Myers: > On Wed, 2 Nov 2016, Ximin Luo wrote: > >> This patch series adds a new environment variable SOURCE_PREFIX_MAP. When >> this >> is set, GCC will treat this as an implicit "-fdebug-prefix-map=$value" >> command-line argument. This ma

Re: [PATCH] Generate reproducible output independently of the build-path

Ximin Luo: > Joseph Myers: >> On Wed, 2 Nov 2016, Ximin Luo wrote: >> >>> This patch series adds a new environment variable SOURCE_PREFIX_MAP. When >>> this >>> is set, GCC will treat this as an implicit "-fdebug-prefix-map=$value" >>&

Re: [PATCH] Generate reproducible output independently of the build-path

Ximin Luo: > Testing > === > > I've tested these patches on a Debian testing/unstable x86_64-linux-gnu > system. > So far I've only run the new tests that this patch adds, on a > disable-bootstrap > build. I will do a full bootstrap and run the full testsuite over t

Re: [PATCH] Generate reproducible output independently of the build-path

Mike Stump: > On Nov 3, 2016, at 1:01 PM, Ximin Luo <infini...@pwned.gg> wrote: >> Log snippets attached. > > Ick. You missed the utility of contrib/compare_tests. :-) > > If you say: > > contrib/compare_tests oldbuilddir newbuilddir > > You can th

[PATCH 2/4] Split prefix-map values on the last '=' character, not the first

2016-11-01 Ximin Luo <infini...@pwned.gg> * final.c: (add_debug_prefix_map): Split on the last and not first '='. * doc/invoke.texi (Environment Variables): Update SOURCE_PREFIX_MAP to describe new parsing. Index: gcc-7-2016

[PATCH 4/4] Use SOURCE_DATE_EPOCH in place of __TIMESTAMP__ if the latter is newer.

lamp-mtime). Acknowledgements Reiner Herrmann suggested the clamping behaviour. ChangeLogs -- libcpp/ChangeLog: 2016-11-01 Ximin Luo <infini...@pwned.gg> * macro.c (_cpp_builtin_macro_text): Use SOURCE_DATE_EPOCH in place of __TIMESTAMP__ if the latt

[PATCH 1/4] Use SOURCE_PREFIX_MAP envvar as an implicit debug-prefix-map

. HW42 for discussion on the details of the proposal, and for suggesting that we retain the ability to map the prefix to something other than ".". ChangeLogs -- gcc/ChangeLog: 2016-11-01 Ximin Luo <infini...@pwned.gg> * opts-global.c (add_debug_prefix_map_f

[PATCH 3/4] Use SOURCE_PREFIX_MAP envvar to transform __FILE__

geLogs -- include/ChangeLog: 2016-11-01 Ximin Luo <infini...@pwned.gg> * prefix-map.h: New file, mostly derived from /gcc/final.c. libiberty/ChangeLog: 2016-11-01 Ximin Luo <infini...@pwned.gg> * prefix-map.c: New file, mostly derived from /gcc/final.c. * M

[PATCH] Generate reproducible output independently of the build-path

(Please keep me on CC, I am not subscribed) Background == We are on a long journey to make build processes be able to reproduce the build outputs independently of which filesystem path the build is being executed from - e.g. if the executing user doesn't have root access to be able to

[PATCH 1/3] Use BUILD_PATH_PREFIX_MAP envvar for debug-prefix-map

to map the prefix to something other than ".". Other contributors to the BUILD_PATH_PREFIX_MAP specification, see https://reproducible-builds.org/specs/build-path-prefix-map/ ChangeLogs -- include/ChangeLog: 2017-04-09 Ximin Luo <infini...@pwned.gg> * prefix

[PATCH 3/3] When remapping paths, only match whole path components

with Michael Woerister and other members of the Rust compiler team on Github, and discussions with Daniel Shahaf on the rb-general@ mailing list on lists.reproducible-builds.org. ChangeLogs -- gcc/ChangeLog: 2017-04-09 Ximin Luo <infini...@pwned.gg> * doc/invoke.texi (Envir

[PATCH v2] Generate reproducible output independently of the build-path

(Please keep me on CC, I am not subscribed) Background == Previous background is here: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00182.html Upon further discussion, we decided to add support for multiple mappings and to rename the environment variable to BUILD_PATH_PREFIX_MAP. We

[PATCH 2/3] Use BUILD_PATH_PREFIX_MAP envvar to transform __FILE__

geLogs -- gcc/c-family/ChangeLog: 2017-03-27 Ximin Luo <infini...@pwned.gg> * c-common.c (cb_get_build_path_prefix_map): Define new call target. * c-common.h (cb_get_build_path_prefix_map): Declare call target. * c-lex.c (init_c_lex): Set the get_build_path_prefix_

Re: [PATCH v2] Generate reproducible output independently of the build-path

Ximin Luo: > [..] > > I will soon test this patch backported to Debian GCC-6 on > tests.reproducible-builds.org and will have results in a few days or weeks. > Some preliminary tests earlier gave good results (about +40 packages > reproducible over ~2 days) but we had to

Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path

Jeff Law: > On 07/21/2017 10:15 AM, Ximin Luo wrote: >> (Please keep me on CC, I am not subscribed) >> >> >> Proposal >> >> >> This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP. When >> this is set, GCC will treat th

Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path

Jeff Law: > On 08/02/2017 08:06 PM, Ximin Luo wrote: >> Jeff Law: >>> On 07/21/2017 10:15 AM, Ximin Luo wrote: >>>> (Please keep me on CC, I am not subscribed) >>>> >>>> >>>> Proposal >>>> >>>>

Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path

Yury Gribov: > [..] > > In general any distro provides some way to set default parameters for > every package. Adding hacks to compiler to work around limitations of > particular build system does not sound right. > > Here's a relevant discussion from binutils ML: >

Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path

Jakub Jelinek: > On Fri, Aug 04, 2017 at 08:32:33AM -0400, Matthias Klose wrote: GCC already supports a similar environment variable SOURCE_DATE_EPOCH, which was accepted about 2 years ago in a patch written by one of our GSoC students. We are not planning any more environment

Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path

Yury Gribov: > On Thu, Aug 3, 2017 at 12:45 PM, Ximin Luo <infini...@pwned.gg> wrote: >> Yury Gribov: >>> [..] >>> >>> Shouldn't -fdebug-prefix-map be updated to use the same syntax as >>> BUILD_PATH_PREFIX_MAP? >>> >> >>

[PATCH 1/3] Use BUILD_PATH_PREFIX_MAP envvar for debug-prefix-map

to map the prefix to something other than ".". Other contributors to the BUILD_PATH_PREFIX_MAP specification, see https://reproducible-builds.org/specs/build-path-prefix-map/ ChangeLogs -- include/ChangeLog: 2017-07-21 Ximin Luo <infini...@pwned.gg> * prefix

[PATCH 2/3] Use BUILD_PATH_PREFIX_MAP envvar to transform __FILE__

geLogs -- gcc/ChangeLog: 2017-07-21 Ximin Luo <infini...@pwned.gg> * doc/invoke.texi (Environment Variables): Document form and behaviour of BUILD_PATH_PREFIX_MAP. gcc/c-family/ChangeLog: 2017-07-21 Ximin Luo <infini...@pwned.gg> * c-common.c (cb_get_bui

[PATCH 3/3] When remapping paths, only match whole path components

. ChangeLogs -- libiberty/ChangeLog: 2017-07-21 Ximin Luo <infini...@pwned.gg> * prefix-map.c: When remapping paths, only match whole path components. Index: gcc-8-20170716/libiberty/prefix-map.c === --- gcc-8-20

[PING^4][PATCH v2] Generate reproducible output independently of the build-path

(Please keep me on CC, I am not subscribed) Proposal This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP. When this is set, GCC will treat this as extra implicit "-fdebug-prefix-map=$value" command-line arguments that precede any explicit ones. This makes the final

Re: [Ping ^3][PATCH v2] Generate reproducible output independently of the build-path

signed a copyright disclaimer and the FSF has this on record. X Ximin Luo: > Ximin Luo: >> Joseph Myers: >>> On Tue, 11 Apr 2017, Ximin Luo wrote: >>> >>>> Copyright disclaimer >>>> >>>> >>>>

Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path

Yury Gribov: > On 03.08.2017 3:06, Ximin Luo wrote: >> Jeff Law: >>> On 07/21/2017 10:15 AM, Ximin Luo wrote: >>>> (Please keep me on CC, I am not subscribed) >>>> >>>> >>>> Proposal >>>> >>>>

Re: [PATCH v2] Generate reproducible output independently of the build-path

Joseph Myers: > On Tue, 11 Apr 2017, Ximin Luo wrote: > >> Copyright disclaimer >> >> >> I dedicate these patches to the public domain by waiving all of my rights to >> the work worldwide under copyright law, including all related and

Re: [PATCH v2] Generate reproducible output independently of the build-path

Ximin Luo: > Joseph Myers: >> On Tue, 11 Apr 2017, Ximin Luo wrote: >> >>> Copyright disclaimer >>> >>> >>> I dedicate these patches to the public domain by waiving all of my rights to >>> the work worldwide und

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

.com/rust-lang/rust/issues/41555#issuecomment-321078174 ChangeLogs -- gcc/ChangeLog: 2017-12-19 Ximin Luo <infini...@pwned.gg> PR other/70268 * file-prefix-map.c (add_prefix_map): Support reading old prefix from the environment. Split old and new parts by

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Hello, I see Boris' patch was accepted with some further changes. Any chance my additions for reproducible builds can be included as well? They are described below. It should still apply on top, minus the strchr -> strrchr change which was folded into Boris' accepted version. Ximin Ximin

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Boris Kolpackov: > Ximin Luo <infini...@pwned.gg> writes: >> Boris Kolpackov: >> >>> This does feel like we are trying to fix the issue in the wrong place. >>> Also, won't such broken packages normally store all options (including >>>

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Boris Kolpackov: > Ximin Luo <infini...@pwned.gg> writes: > >> Higher-level build scripts sometimes like to save CFLAGS etc into the build >> output, making the overall build output unreproducible even if GCC is >> playing >> nicely. Rather than ad

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Boris Kolpackov: > Ximin Luo <infini...@pwned.gg> writes: > >> -I to an absolute path is not that common for system / distro-built >> stuff. > > Ok, thanks for clarifying. > > >> In the cases that it occurs, indeed it could and should be fixed >&g