From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5804 invoked by alias); 11 Feb 2015 12:24:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 5676 invoked by uid 48); 11 Feb 2015 12:24:01 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65015] LTO produces randomly ordered debug information Date: Wed, 11 Feb 2015 12:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 4.9.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg01164.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65015 --- Comment #4 from Richard Biener --- (In reply to conchur from comment #2) > Created attachment 34724 [details] > Mini Testcases >=20 > Current results (the -COMPILE things are just out of curiosity): >=20 > SIMPLE-COMPILE: OK > SIMPLE-LINK: OK > LTO-COMPILE: FAIL that's expected to fail > LTO-LINK: FAIL > LTO-OBJDUMP: OK > LTO-EXTERNAL-DEBUG: FAIL > LTO-STRIP-LINK: FAIL > LTO-STRIP-EXTERNAL-DEBUG: FAIL > LTO-BUILDID-LINK: FAIL > LTO-SAVETEMPS-LINK: OK > LTO-SAVETEMPS-EXTERNAL-DEBUG: OK >=20 > The -save-temps was a suggestion by J=C3=A9r=C3=A9my Bobbio and shows tha= t there is > still a problem with the random file names when trying to use LTO to crea= te > reproducible builds. At least for the simple one file case -save-temps makes some of the names non-random. I still expect that the pa= tch I just committed plus Index: gcc/dwarf2out.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gcc/dwarf2out.c (revision 220613) +++ gcc/dwarf2out.c (working copy) @@ -24521,8 +24521,11 @@ dwarf2out_finish (const char *filename) gen_remaining_tmpl_value_param_die_attribute (); /* Add the name for the main input file now. We delayed this from - dwarf2out_init to avoid complications with PCH. */ - add_name_attribute (comp_unit_die (), remap_debug_filename (filename)); + dwarf2out_init to avoid complications with PCH. + Avoid doing this for LTO produced units as it adds random + tempfile names. */ + if (!in_lto_p) + add_name_attribute (comp_unit_die (), remap_debug_filename (filename)); if (!IS_ABSOLUTE_PATH (filename) || targetm.force_at_comp_dir) add_comp_dir_attribute (comp_unit_die ()); else if (get_AT (comp_unit_die (), DW_AT_comp_dir) =3D=3D NULL) will fix all cases. Indeed: > ./t.sh=20 SIMPLE-COMPILE: OK SIMPLE-LINK: OK LTO-COMPILE: FAIL LTO-LINK: OK LTO-OBJDUMP: OK LTO-EXTERNAL-DEBUG: OK LTO-STRIP-LINK: OK LTO-STRIP-EXTERNAL-DEBUG: OK LTO-BUILDID-LINK: OK LTO-SAVETEMPS-LINK: OK LTO-SAVETEMPS-EXTERNAL-DEBUG: OK as expected. >>From gcc-bugs-return-476832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 11 12:26:18 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 9229 invoked by alias); 11 Feb 2015 12:26:18 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 9188 invoked by uid 48); 11 Feb 2015 12:26:14 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/65018] Use secure_getenv when available Date: Wed, 11 Feb 2015 12:26:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg01165.txt.bz2 Content-length: 861 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65018 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think LC_ALL/LANG/ and the other LC_* vars are ok as is, at least glibc normally doesn't consider them as unsecvars. But e.g. LOCPATH is considered problematic for suid/sgid. Locales and translations should be picked up by default from directories normal users don't have access to, and localization of suid/sgid is desirable. The main problem is if some env var lets e.g. the program write some file, or significantly change behavior from the behavior that has been tested, etc.