From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104100 invoked by alias); 29 Apr 2019 16:29:48 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 104019 invoked by uid 48); 29 Apr 2019 16:29:44 -0000 From: "nfxjfg at googlemail dot com" To: glibc-bugs@sourceware.org Subject: [Bug stdio/24466] Feature request: provide special printf formats for intXX_t Date: Mon, 29 Apr 2019 16:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: nfxjfg at googlemail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00216.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24466 --- Comment #4 from nfxjfg at googlemail dot com --- > And I also > tend to see this should be the focus on improving for a more generic > solution, instead of adding more type specifiers to printf/scanf. Such as? > One advantage of the PRI macros is they are composable: with C99 specifyi= ng > that both uint64_t and long long are no longer compiler extension, > printf/scanf should also support the types. It simplifies compiler and > runtime implementation. A truly generic solution would not require hardcoding libc implementation details in the compiler. Using macros is just a workaround exactly because = you still need to use the builtin compiler checker. If that weren't the case I could just implement my own printf-like function, instead of trying to comp= el all target libcs or the C standard to include it. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45346-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Apr 29 16:37:15 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 111017 invoked by alias); 29 Apr 2019 16:37:15 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 110943 invoked by uid 48); 29 Apr 2019 16:37:11 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug stdio/24466] Feature request: provide special printf formats for intXX_t Date: Mon, 29 Apr 2019 16:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00217.txt.bz2 Content-length: 1976 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24466 --- Comment #5 from Adhemerval Zanella --- (In reply to nfxjfg from comment #4) > > And I also > > tend to see this should be the focus on improving for a more generic > > solution, instead of adding more type specifiers to printf/scanf. >=20 > Such as? The very suggestion you are aiming with this bug report. They will be alias= es to current already supported type, which would require additional support f= rom compiler to enable both warning and attribute supports and additional suppo= rt from programs to check and use the correct support (if they aim to support different libcs, since at least initially MS and glibc one would usee diffe= rent identifiers). >=20 > > One advantage of the PRI macros is they are composable: with C99 specif= ying > > that both uint64_t and long long are no longer compiler extension, > > printf/scanf should also support the types. It simplifies compiler and > > runtime implementation. >=20 > A truly generic solution would not require hardcoding libc implementation > details in the compiler. Using macros is just a workaround exactly because > you still need to use the builtin compiler checker. If that weren't the c= ase > I could just implement my own printf-like function, instead of trying to > compel all target libcs or the C standard to include it. The generic solution already exists, they are the inttypes types. The compi= ler supports is not to enable the support, but rather to improve warning support for mismatched/invalid types either through warning flags or attribute((format)). The question is: should we add *another* printf alias as GNU specific extension? Or would be better to try and raise on C standard to add as a generic identifier? Again, I still think the best course of action is to discuss it on libc-alp= ha maillist. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45347-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 01:26:55 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 99250 invoked by alias); 30 Apr 2019 01:26:55 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 99172 invoked by uid 55); 30 Apr 2019 01:26:49 -0000 From: "cvs-commit at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug build/19444] build failures with -O1 due to -Wmaybe-uninitialized Date: Tue, 30 Apr 2019 01:26:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: build X-Bugzilla-Version: 2.23 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00218.txt.bz2 Content-length: 5534 https://sourceware.org/bugzilla/show_bug.cgi?id=3D19444 --- Comment #15 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Maciej W. Rozycki : https://sourceware.org/git/gitweb.cgi?p=3Dglibc.git;h=3D87c266d758d29e52bfb= 717f90025ef1fe2663d38 commit 87c266d758d29e52bfb717f90025ef1fe2663d38 Author: Maciej W. Rozycki Date: Tue Apr 30 02:24:49 2019 +0100 Fix -O1 compilation errors with `__ddivl' and `__fdivl' [BZ #19444] Complementing commit 4a06ceea33ec ("sysdeps/ieee754/soft-fp: ignore maybe-uninitialized with -O [BZ #19444]") and commit 27c5e756a2a8 ("sysdeps/ieee754: prevent maybe-uninitialized errors with -O [BZ #19444]") also fix compilation errors observed at -O1 in `__ddivl' and `__fdivl' with GCC 9 and RISC-V targets: In file included from ../soft-fp/soft-fp.h:318, from ../sysdeps/ieee754/soft-fp/s_fdivl.c:27: ../sysdeps/ieee754/soft-fp/s_fdivl.c: In function '__fdivl': ../soft-fp/op-2.h:108:9: error: 'R_f1' may be used uninitialized in this function [-Werror=3Dmaybe-uninitialized] 108 | : (X##_f1 << (2*_FP_W_TYPE_SIZE - (N)))) \ | ^ ../sysdeps/ieee754/soft-fp/s_fdivl.c:37:14: note: 'R_f1' was declared h= ere 37 | FP_DECL_Q (R); | ^ ../soft-fp/op-common.h:39:3: note: in expansion of macro '_FP_FRAC_DECL= _2' 39 | _FP_FRAC_DECL_##wc (X) | ^~~~~~~~~~~~~~ ../soft-fp/quad.h:226:24: note: in expansion of macro '_FP_DECL' 226 | # define FP_DECL_Q(X) _FP_DECL (2, X) | ^~~~~~~~ ../sysdeps/ieee754/soft-fp/s_fdivl.c:37:3: note: in expansion of macro 'FP_DECL_Q' 37 | FP_DECL_Q (R); | ^~~~~~~~~ ../soft-fp/op-2.h:109:8: error: 'R_f0' may be used uninitialized in this function [-Werror=3Dmaybe-uninitialized] 109 | | X##_f0) !=3D 0)); \ | ^ ../sysdeps/ieee754/soft-fp/s_fdivl.c:37:14: note: 'R_f0' was declared h= ere 37 | FP_DECL_Q (R); | ^ ../soft-fp/op-common.h:39:3: note: in expansion of macro '_FP_FRAC_DECL= _2' 39 | _FP_FRAC_DECL_##wc (X) | ^~~~~~~~~~~~~~ ../soft-fp/quad.h:226:24: note: in expansion of macro '_FP_DECL' 226 | # define FP_DECL_Q(X) _FP_DECL (2, X) | ^~~~~~~~ ../sysdeps/ieee754/soft-fp/s_fdivl.c:37:3: note: in expansion of macro 'FP_DECL_Q' 37 | FP_DECL_Q (R); | ^~~~~~~~~ In file included from ../soft-fp/soft-fp.h:318, from ../sysdeps/ieee754/soft-fp/s_ddivl.c:31: ../sysdeps/ieee754/soft-fp/s_ddivl.c: In function '__ddivl': ../soft-fp/op-2.h:98:25: error: 'R_f1' may be used uninitialized in this function [-Werror=3Dmaybe-uninitialized] 98 | X##_f0 =3D (X##_f1 << (_FP_W_TYPE_SIZE - (N)) | X##_f0 >= > (N) \ | ^~ ../sysdeps/ieee754/soft-fp/s_ddivl.c:41:14: note: 'R_f1' was declared h= ere 41 | FP_DECL_Q (R); | ^ ../soft-fp/op-2.h:37:36: note: in definition of macro '_FP_FRAC_DECL_2' 37 | _FP_W_TYPE X##_f0 _FP_ZERO_INIT, X##_f1 _FP_ZERO_INIT | ^ ../soft-fp/quad.h:226:24: note: in expansion of macro '_FP_DECL' 226 | # define FP_DECL_Q(X) _FP_DECL (2, X) | ^~~~~~~~ ../sysdeps/ieee754/soft-fp/s_ddivl.c:41:3: note: in expansion of macro 'FP_DECL_Q' 41 | FP_DECL_Q (R); | ^~~~~~~~~ ../soft-fp/op-2.h:101:17: error: 'R_f0' may be used uninitialized in th= is function [-Werror=3Dmaybe-uninitialized] 101 | : (X##_f0 << (_FP_W_TYPE_SIZE - (N))) !=3D 0)); \ | ^~ ../sysdeps/ieee754/soft-fp/s_ddivl.c:41:14: note: 'R_f0' was declared h= ere 41 | FP_DECL_Q (R); | ^ ../soft-fp/op-2.h:37:14: note: in definition of macro '_FP_FRAC_DECL_2' 37 | _FP_W_TYPE X##_f0 _FP_ZERO_INIT, X##_f1 _FP_ZERO_INIT | ^ ../soft-fp/quad.h:226:24: note: in expansion of macro '_FP_DECL' 226 | # define FP_DECL_Q(X) _FP_DECL (2, X) | ^~~~~~~~ ../sysdeps/ieee754/soft-fp/s_ddivl.c:41:3: note: in expansion of macro 'FP_DECL_Q' 41 | FP_DECL_Q (R); | ^~~~~~~~~ cc1: all warnings being treated as errors make[2]: *** [.../sysd-rules:587: .../math/s_fdivl.o] Error 1 make[2]: *** Waiting for unfinished jobs.... cc1: all warnings being treated as errors make[2]: *** [.../sysd-rules:587: .../math/s_ddivl.o] Error 1 This comes from cases in _FP_DIV that return a result described as FP_CLS_ZERO or FP_CLS_INF and do not initialize the fractional part, which is then operated on unconditionally in FP_TRUNC_COOKED before being ignored by _FP_PACK_CANONICAL. Clearly at this optimization level GCC cannot guarantee to be able to determine that the fractional part is ultimately unused, so ignore the error as with the earlier commits referred, letting compilation proceed. [BZ #19444] * sysdeps/ieee754/soft-fp/s_ddivl.c (__ddivl): Ignore errors from `-Wmaybe-uninitialized'. * sysdeps/ieee754/soft-fp/s_fdivl.c (__fdivl): Likewise. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45348-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 09:47:30 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 123582 invoked by alias); 30 Apr 2019 09:47:30 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 123551 invoked by uid 48); 30 Apr 2019 09:47:27 -0000 From: "schwab@linux-m68k.org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24484] RISC-V libraries can have read-write .dynamic sections, but ld.so loads them as read-only Date: Tue, 30 Apr 2019 09:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.29 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: schwab@linux-m68k.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.30 X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00219.txt.bz2 Content-length: 225 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24484 --- Comment #2 from Andreas Schwab --- Isn't that an ABI break? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45349-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 16:25:59 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 35855 invoked by alias); 30 Apr 2019 16:25:59 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 35821 invoked by uid 48); 30 Apr 2019 16:25:56 -0000 From: "hjl.tools at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] New: FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 16:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hjl.tools at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone cf_gcctarget Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00220.txt.bz2 Content-length: 754 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 Bug ID: 24506 Summary: FAIL: elf/tst-pldd Product: glibc Version: 2.30 Status: NEW Severity: normal Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86-64 On x86-64, I got [hjl@gnu-cfl-1 build-x86_64-linux]$ elf/tst-pldd Timed out: killed the child process Termination time: 2019-04-30T16:25:33.161492 Last write to standard output: 2019-04-30T16:25:12.633579 [hjl@gnu-cfl-1 build-x86_64-linux]$ --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45350-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 16:40:11 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 77682 invoked by alias); 30 Apr 2019 16:40:11 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 75810 invoked by uid 48); 30 Apr 2019 16:40:08 -0000 From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 16:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00221.txt.bz2 Content-length: 676 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 Florian Weimer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fweimer at redhat dot com Flags| |security- --- Comment #1 from Florian Weimer --- I believe this is because the test runs against the installed (system) pldd= .=20 You can run the test directly this way, even though it does not fail. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45351-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 16:42:35 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 109413 invoked by alias); 30 Apr 2019 16:42:35 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 109386 invoked by uid 48); 30 Apr 2019 16:42:32 -0000 From: "hjl.tools at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 16:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hjl.tools at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00222.txt.bz2 Content-length: 440 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 --- Comment #2 from H.J. Lu --- (In reply to Florian Weimer from comment #1) > I believe this is because the test runs against the installed (system) pl= dd. > You can run the test directly this way, even though it does not fail. Isn't it wrong to test the installed pldd? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45352-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 16:46:35 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 116595 invoked by alias); 30 Apr 2019 16:46:35 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 116540 invoked by uid 48); 30 Apr 2019 16:46:32 -0000 From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 16:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00223.txt.bz2 Content-length: 878 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 --- Comment #3 from Florian Weimer --- (In reply to H.J. Lu from comment #2) > (In reply to Florian Weimer from comment #1) > > I believe this is because the test runs against the installed (system) = pldd. > > You can run the test directly this way, even though it does not fail. >=20 > Isn't it wrong to test the installed pldd? Yes, like with any other test (which in a default build would attempt to run against the installed glibc, if not statically linked). The makefiles run = the test in such a way that the correct (in-tree) binary is tested. Do you configure with --enable-hardcoded-path-in-tests? It's not effective here. But that's also true for tests that require certain environment variables. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45353-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 16:48:56 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 802 invoked by alias); 30 Apr 2019 16:48:56 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 131001 invoked by uid 48); 30 Apr 2019 16:48:52 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 16:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00224.txt.bz2 Content-length: 1383 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carlos at redhat dot com --- Comment #4 from Carlos O'Donell --- (In reply to Florian Weimer from comment #3) > (In reply to H.J. Lu from comment #2) > > (In reply to Florian Weimer from comment #1) > > > I believe this is because the test runs against the installed (system= ) pldd. > > > You can run the test directly this way, even though it does not fail. > >=20 > > Isn't it wrong to test the installed pldd? >=20 > Yes, like with any other test (which in a default build would attempt to = run > against the installed glibc, if not statically linked). The makefiles run > the test in such a way that the correct (in-tree) binary is tested. >=20 > Do you configure with --enable-hardcoded-path-in-tests? It's not effecti= ve > here. But that's also true for tests that require certain environment > variables. Right, --enable-hardcoded-path-in-tests is not enough to make all tests wor= k, some tests require more setup e.g. env vars, containers (chroot), special arguments. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45354-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 16:52:08 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 26529 invoked by alias); 30 Apr 2019 16:52:08 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 26484 invoked by uid 48); 30 Apr 2019 16:52:05 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 16:52:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00225.txt.bz2 Content-length: 1650 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 Adhemerval Zanella changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adhemerval.zanella at lina= ro dot o | |rg --- Comment #5 from Adhemerval Zanella --- (In reply to Carlos O'Donell from comment #4) > (In reply to Florian Weimer from comment #3) > > (In reply to H.J. Lu from comment #2) > > > (In reply to Florian Weimer from comment #1) > > > > I believe this is because the test runs against the installed (syst= em) pldd. > > > > You can run the test directly this way, even though it does not fai= l. > > >=20 > > > Isn't it wrong to test the installed pldd? > >=20 > > Yes, like with any other test (which in a default build would attempt t= o run > > against the installed glibc, if not statically linked). The makefiles = run > > the test in such a way that the correct (in-tree) binary is tested. > >=20 > > Do you configure with --enable-hardcoded-path-in-tests? It's not effec= tive > > here. But that's also true for tests that require certain environment > > variables. >=20 > Right, --enable-hardcoded-path-in-tests is not enough to make all tests > work, some tests require more setup e.g. env vars, containers (chroot), > special arguments. Maybe we should disable such tests if --enable-hardcoded-path-in-tests is u= sed? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45355-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 16:57:48 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 47794 invoked by alias); 30 Apr 2019 16:57:48 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 45769 invoked by uid 48); 30 Apr 2019 16:57:45 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 16:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00226.txt.bz2 Content-length: 1294 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 --- Comment #6 from Carlos O'Donell --- (In reply to Adhemerval Zanella from comment #5) > (In reply to Carlos O'Donell from comment #4) > > Right, --enable-hardcoded-path-in-tests is not enough to make all tests > > work, some tests require more setup e.g. env vars, containers (chroot), > > special arguments. >=20 > Maybe we should disable such tests if --enable-hardcoded-path-in-tests is > used? That would be bad for test coverage, and --enable-hardcoded-path-in-tests i= s a developer-only option, so you have to know what you're doing. The option al= lows stand-alone tests to run just fine, all other tests need special options. My current idea is as follows: - Every test we execute, we record *how* it was executed. - Provide a log at the end that can be parsed by some kind of simplistic te= st runner, and you can use that to re-run tests by # or name. The reason I want this is to be able to build a tests subpackage downstream= and use it for A/B patch testing and running the test outside of the testsuite.= I don't yet want to split the testsuite out of glibc because there is value in having it integrated. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45356-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 17:02:07 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 58138 invoked by alias); 30 Apr 2019 17:02:07 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 57661 invoked by uid 48); 30 Apr 2019 17:02:03 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 17:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00227.txt.bz2 Content-length: 1760 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 --- Comment #7 from Adhemerval Zanella --- (In reply to Carlos O'Donell from comment #6) > (In reply to Adhemerval Zanella from comment #5) > > (In reply to Carlos O'Donell from comment #4) > > > Right, --enable-hardcoded-path-in-tests is not enough to make all tes= ts > > > work, some tests require more setup e.g. env vars, containers (chroot= ), > > > special arguments. > >=20 > > Maybe we should disable such tests if --enable-hardcoded-path-in-tests = is > > used? >=20 > That would be bad for test coverage, and --enable-hardcoded-path-in-tests= is > a developer-only option, so you have to know what you're doing. The option > allows stand-alone tests to run just fine, all other tests need special > options. Since --enable-hardcoded-path-in-tests is meant for developers, we can disa= ble it with a specific error code. Since the test will fail anyway, at least it would indicate it has failed due to the configure environment rather than a real issue. >=20 > My current idea is as follows: > - Every test we execute, we record *how* it was executed. > - Provide a log at the end that can be parsed by some kind of simplistic > test runner, and you can use that to re-run tests by # or name. >=20 > The reason I want this is to be able to build a tests subpackage downstre= am > and use it for A/B patch testing and running the test outside of the > testsuite. I don't yet want to split the testsuite out of glibc because > there is value in having it integrated. That's a good addition for the test-suite, but I also think it is orthogona= l to my suggestion above. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45357-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 17:10:41 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 87451 invoked by alias); 30 Apr 2019 17:10:41 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 87386 invoked by uid 48); 30 Apr 2019 17:10:38 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 17:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00228.txt.bz2 Content-length: 765 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 --- Comment #8 from Carlos O'Donell --- (In reply to Adhemerval Zanella from comment #7) > Since --enable-hardcoded-path-in-tests is meant for developers, we can > disable it with a specific error code. Since the test will fail anyway, at > least it would indicate it has failed due to the configure environment > rather than a real issue. Do you mean the following? * Test detects it is not being run in the correct environment (within a gli= bc container chroot) * Test exits with appropriate error. Yes, we could do that, I don't know how to do that reliably, but it's somet= hing we could do. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45358-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 17:13:30 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 90274 invoked by alias); 30 Apr 2019 17:13:30 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 90185 invoked by uid 48); 30 Apr 2019 17:13:25 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 17:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00229.txt.bz2 Content-length: 1273 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #35 from Adhemerval Zanella --- (In reply to John Paul Adrian Glaubitz from comment #34) > (In reply to Adhemerval Zanella from comment #32) > > I am not against in reverting back to use SYS_getdents for getdents64, > > although it is a subpar resolution for a kernel issue. Newer architect= ures > > with mixed 32 and 64 bits support will continue to be broken without a > > proper kernel fix since they use SYS_getdents64 for getdents. >=20 > Could we revert to SYS_getdents for the time being? Currently, we cannot > update the glibc package on qemu-emulated buildds because of this particu= lar > issue. The issue is the workaround would probably be permanent, since kernel developers didn't see to be working on fixing it, and it would hide a kernel issue on compat syscalls that might continue to appear in newer 32-bit ABI since LFS is not yet enforced as the only support ABI. It would also require all the internal boilerplate to handle this syscall. My question is why is preventing buildds on qemu-emulated architectures to = use LFS interfaces instead of non-LFS one? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45359-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 17:15:44 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 92662 invoked by alias); 30 Apr 2019 17:15:39 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 92479 invoked by uid 48); 30 Apr 2019 17:15:26 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd Date: Tue, 30 Apr 2019 17:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00230.txt.bz2 Content-length: 971 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 --- Comment #9 from Adhemerval Zanella --- (In reply to Carlos O'Donell from comment #8) > (In reply to Adhemerval Zanella from comment #7) > > Since --enable-hardcoded-path-in-tests is meant for developers, we can > > disable it with a specific error code. Since the test will fail anyway,= at > > least it would indicate it has failed due to the configure environment > > rather than a real issue. >=20 > Do you mean the following? >=20 > * Test detects it is not being run in the correct environment (within a > glibc container chroot) >=20 > * Test exits with appropriate error. >=20 > Yes, we could do that, I don't know how to do that reliably, but it's > something we could do. Yes, that was my suggestion. Maybe libsupport could export an environment variable with this information. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45360-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 17:15:50 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 93116 invoked by alias); 30 Apr 2019 17:15:49 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 92899 invoked by uid 48); 30 Apr 2019 17:15:44 -0000 From: "glaubitz at physik dot fu-berlin.de" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 17:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00231.txt.bz2 Content-length: 495 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #36 from John Paul Adrian Glaubitz --- (In reply to Adhemerval Zanella from comment #35) > My question is why is preventing buildds on qemu-emulated architectures to > use LFS interfaces instead of non-LFS one? We're just using the defaults of qemu-user. Is there an option to force-ena= ble LFS in qemu? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45361-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 17:31:58 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 112619 invoked by alias); 30 Apr 2019 17:31:58 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 112554 invoked by uid 48); 30 Apr 2019 17:31:54 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 17:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00232.txt.bz2 Content-length: 1363 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #37 from Adhemerval Zanella --- (In reply to John Paul Adrian Glaubitz from comment #36) > (In reply to Adhemerval Zanella from comment #35) > > My question is why is preventing buildds on qemu-emulated architectures= to > > use LFS interfaces instead of non-LFS one? >=20 > We're just using the defaults of qemu-user. Is there an option to > force-enable LFS in qemu? No sure in fact, my un(In reply to John Paul Adrian Glaubitz from comment #= 36) > (In reply to Adhemerval Zanella from comment #35) > > My question is why is preventing buildds on qemu-emulated architectures= to > > use LFS interfaces instead of non-LFS one? >=20 > We're just using the defaults of qemu-user. Is there an option to > force-enable LFS in qemu? In fact, it seems it would fail regardless of whether the process issue LFS= or non-LFS syscall, as Florian has pointed out [1]. Florian could you confirm that even 32-bit binaries built with LFS support while running on qemu-syst= em also built with LFS support still fail? Because I am failing to see where exactly it would be broken in this situation. [1] https://lore.kernel.org/lkml/20181229015453.GA6310@bombadil.infradead.org/T/ --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45362-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 17:50:39 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 7631 invoked by alias); 30 Apr 2019 17:50:39 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 7110 invoked by uid 48); 30 Apr 2019 17:50:33 -0000 From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 17:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00233.txt.bz2 Content-length: 1393 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #38 from Florian Weimer --- I feel we are running in circles here. Let me summarize what I think is go= ing on. The core issue is that neither POSIX nor glibc have an LFS interface for seekdir/telldir, and the d_off value is expected to be compatible with the non-LFS seekdir, telldir functions. The kernel implements an arbitrary truncation for both getdents and getdent= s64 (so both LFS and non-LFS interfaces) when running 32-bit compat mode. It is not possible at all to get the same truncation in 64-bit mode. qemu-user f= akes a *different* truncation when emulating the getdents system call. Since ha= rdly anyone uses d_off/seekdir/telldir, this does not matter. With the range checking for d_off in the current glibc implementation of getdents, we suddenly insist on a 32-bit-compatible d_off value from a getdents64 system call in 32-bit compat mode, like the actual kernel implem= ents this. So I think without new kernel/userspace APIs, the only way to fix this is to change the binaries running under qemu-user (and not qemu-user itself) to L= FS interfaces, and stop using telldir/seekdir, in favor of d_off from readdir64/LFS-readdir with lseek64/LFS-lseek. I hope this summary makes sense. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45363-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 18:00:44 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 40043 invoked by alias); 30 Apr 2019 18:00:44 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 39923 invoked by uid 48); 30 Apr 2019 18:00:38 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 18:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00234.txt.bz2 Content-length: 1874 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #39 from Adhemerval Zanella --- (In reply to Florian Weimer from comment #38) > I feel we are running in circles here. Let me summarize what I think is > going on. >=20 > The core issue is that neither POSIX nor glibc have an LFS interface for > seekdir/telldir, and the d_off value is expected to be compatible with the > non-LFS seekdir, telldir functions. >=20 > The kernel implements an arbitrary truncation for both getdents and > getdents64 (so both LFS and non-LFS interfaces) when running 32-bit compat > mode. It is not possible at all to get the same truncation in 64-bit mod= e.=20 > qemu-user fakes a *different* truncation when emulating the getdents syst= em > call. Since hardly anyone uses d_off/seekdir/telldir, this does not matt= er. >=20 > With the range checking for d_off in the current glibc implementation of > getdents, we suddenly insist on a 32-bit-compatible d_off value from a > getdents64 system call in 32-bit compat mode, like the actual kernel > implements this. >=20 > So I think without new kernel/userspace APIs, the only way to fix this is= to > change the binaries running under qemu-user (and not qemu-user itself) to > LFS interfaces, and stop using telldir/seekdir, in favor of d_off from > readdir64/LFS-readdir with lseek64/LFS-lseek. Ok, so this my understanding as well. To make it clear the truncation and t= hus the issue only happens when a binary runs with a qemu-system built without = LFS, so the question is which build step in debian buildd infrastructure is not being built with LFS support. The idea is once binaries are not using non-L= FS getdents anymore this issue won't happen. >=20 > I hope this summary makes sense. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45364-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 18:04:57 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 46741 invoked by alias); 30 Apr 2019 18:04:57 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 46685 invoked by uid 48); 30 Apr 2019 18:04:53 -0000 From: "hjl.tools at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd with --enable-hardcoded-path-in-tests Date: Tue, 30 Apr 2019 18:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hjl.tools at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00235.txt.bz2 Content-length: 679 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 H.J. Lu changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|FAIL: elf/tst-pldd |FAIL: elf/tst-pldd with | |--enable-hardcoded-path-in- | |tests --- Comment #10 from H.J. Lu --- I used --enable-hardcoded-path-in-tests. It should be able to test a to-be-installed program. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45365-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 19:04:57 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 28449 invoked by alias); 30 Apr 2019 19:04:57 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 28397 invoked by uid 48); 30 Apr 2019 19:04:52 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd with --enable-hardcoded-path-in-tests Date: Tue, 30 Apr 2019 19:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00236.txt.bz2 Content-length: 2169 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 --- Comment #11 from Adhemerval Zanella --- In fact test in container does support --enable-hardcoded-path-in-tests, it copies the required hardcoded libraries (taking care of replicating the full path inside testroot.root). The issue is the resulting library names obtain= ed with pldd will have the 'vanilla' names os 'ld.so' and 'libc.so' instead of= the installed ABI names (ld-linux-x86-64.so.2 for instance on x86_64). The following patch should fixed it: --- diff --git a/elf/tst-pldd.c b/elf/tst-pldd.c index ed19cedd05..0e2243349c 100644 --- a/elf/tst-pldd.c +++ b/elf/tst-pldd.c @@ -20,7 +20,6 @@ #include #include #include -#include #include #include @@ -39,6 +38,15 @@ target_process (void *arg) /* The test runs in a container because pldd does not support tracing a binary started by the loader iself (as with testrun.sh). */ +static bool +in_string_list (const char *libname, const char *const strlist[]) +{ + for (const char *const *str =3D strlist; *str !=3D NULL; str++) + if (strcmp (libname, *str) =3D=3D 0) + return true; + return false; +} + static int do_test (void) { @@ -89,14 +97,18 @@ do_test (void) if (buffer[strlen(buffer)-1] =3D=3D '\n') buffer[strlen(buffer)-1] =3D '\0'; - if (strcmp (basename (buffer), LD_SO) =3D=3D 0) + const char *libname =3D basename (buffer); + + if (in_string_list (libname, + (const char *const []) { "ld.so", LD_SO, NULL }= )) { TEST_COMPARE (interpreter_found, false); interpreter_found =3D true; continue; } - if (strcmp (basename (buffer), LIBC_SO) =3D=3D 0) + if (in_string_list (libname, + (const char *const []) { "libc.so", LIBC_SO, NU= LL })) { TEST_COMPARE (libc_found, false); libc_found =3D true; --- I will send it upstream. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45366-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 19:21:08 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 76834 invoked by alias); 30 Apr 2019 19:21:08 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 74734 invoked by uid 48); 30 Apr 2019 19:21:04 -0000 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/24506] FAIL: elf/tst-pldd with --enable-hardcoded-path-in-tests Date: Tue, 30 Apr 2019 19:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: adhemerval.zanella at linaro dot org X-Bugzilla-Target-Milestone: 2.30 X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: assigned_to target_milestone Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00237.txt.bz2 Content-length: 536 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24506 Adhemerval Zanella changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at sourceware dot org |adhemerval.zanella = at linaro dot o | |rg Target Milestone|--- |2.30 --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45367-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 23:03:19 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 38278 invoked by alias); 30 Apr 2019 23:03:19 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 38061 invoked by uid 48); 30 Apr 2019 23:03:13 -0000 From: "glaubitz at physik dot fu-berlin.de" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 23:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00238.txt.bz2 Content-length: 791 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #40 from John Paul Adrian Glaubitz --- (In reply to Florian Weimer from comment #38) > So I think without new kernel/userspace APIs, the only way to fix this is= to > change the binaries running under qemu-user (and not qemu-user itself) to > LFS interfaces, and stop using telldir/seekdir, in favor of d_off from > readdir64/LFS-readdir with lseek64/LFS-lseek. How do I achieve this? Does this mean I have to patch 12.000 Debian source packages to switch the binaries to LFS mode? If this really involves patchi= ng all of these packages, then I don't think we will ever realistically achieve this. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45368-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 23:19:57 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 59054 invoked by alias); 30 Apr 2019 23:19:57 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 58986 invoked by uid 48); 30 Apr 2019 23:19:52 -0000 From: "jrtc27 at jrtc27 dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 23:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jrtc27 at jrtc27 dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00239.txt.bz2 Content-length: 1253 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #41 from James Clarke --- (In reply to John Paul Adrian Glaubitz from comment #40) > (In reply to Florian Weimer from comment #38) > > So I think without new kernel/userspace APIs, the only way to fix this = is to > > change the binaries running under qemu-user (and not qemu-user itself) = to > > LFS interfaces, and stop using telldir/seekdir, in favor of d_off from > > readdir64/LFS-readdir with lseek64/LFS-lseek. >=20 > How do I achieve this? Does this mean I have to patch 12.000 Debian source > packages to switch the binaries to LFS mode? If this really involves > patching all of these packages, then I don't think we will ever > realistically achieve this. Easiest thing would be to patch gcc/config/whatever.h to include: builtin_define ("_LARGEFILE_SOURCE=3D1"); \ builtin_define ("_LARGEFILE64_SOURCE=3D1"); \ builtin_define ("_FILE_OFFSET_BITS=3D64"); \ though I don't know if that causes problems for compiling glibc itself. Note that this does count as an ABI break for things using off_t in structs expo= sed in their API. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45369-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Apr 30 23:40:38 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 77787 invoked by alias); 30 Apr 2019 23:40:38 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 74365 invoked by uid 48); 30 Apr 2019 23:40:32 -0000 From: "glaubitz at physik dot fu-berlin.de" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Tue, 30 Apr 2019 23:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-04/txt/msg00240.txt.bz2 Content-length: 1033 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #42 from John Paul Adrian Glaubitz --- (In reply to James Clarke from comment #41) > Easiest thing would be to patch gcc/config/whatever.h to include: >=20 > builtin_define ("_LARGEFILE_SOURCE=3D1"); \ > builtin_define ("_LARGEFILE64_SOURCE=3D1"); \ > builtin_define ("_FILE_OFFSET_BITS=3D64"); \ >=20 > though I don't know if that causes problems for compiling glibc itself. N= ote > that this does count as an ABI break for things using off_t in structs > exposed in their API. I just noticed that at least dash seems to have been patched to enable LFS = now, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D916255. So, it coul= d be that at least our original bug could already be addressed now. But I think there was another important package affected by this regression although I don't remember. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45370-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed May 01 07:53:03 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 55648 invoked by alias); 1 May 2019 07:53:03 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 55545 invoked by uid 48); 1 May 2019 07:52:58 -0000 From: "glaubitz at physik dot fu-berlin.de" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Wed, 01 May 2019 07:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-05/txt/msg00000.txt.bz2 Content-length: 1546 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #43 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #42) > (In reply to James Clarke from comment #41) > > Easiest thing would be to patch gcc/config/whatever.h to include: > >=20 > > builtin_define ("_LARGEFILE_SOURCE=3D1"); \ > > builtin_define ("_LARGEFILE64_SOURCE=3D1"); \ > > builtin_define ("_FILE_OFFSET_BITS=3D64"); \ > >=20 >=20 > I just noticed that at least dash seems to have been patched to enable LFS > now, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D916255. So, = it > could be that at least our original bug could already be addressed now. B= ut > I think there was another important package affected by this regression > although I don't remember. Okay, so I can confirm that dash is no longer affected after #916255. Howev= er, qt5-qmake still misbehaves. Looking at the build log, qt5-qmake is built wi= th _LARGEFILE_SOURCE=3D1 but not _LARGEFILE64_SOURCE=3D1 [1] while qt4-x11 is = [2]. I will rebuild qtbase-opensource-source with _LARGEFILE64_SOURCE to see if = that helps. > [1] https://buildd.debian.org/status/fetch.php?pkg=3Dqtbase-opensource-sr= c&arch=3Dm68k&ver=3D5.11.3%2Bdfsg1-1&stamp=3D1554325976&raw=3D0 > [2] https://buildd.debian.org/status/fetch.php?pkg=3Dqt4-x11&arch=3Dm68k&= ver=3D4%3A4.8.7%2Bdfsg-18&stamp=3D1555145133&raw=3D0 --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45371-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed May 01 08:29:31 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 29936 invoked by alias); 1 May 2019 08:29:31 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 29838 invoked by uid 48); 1 May 2019 08:29:26 -0000 From: "glaubitz at physik dot fu-berlin.de" To: glibc-bugs@sourceware.org Subject: [Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user Date: Wed, 01 May 2019 08:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.28 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-05/txt/msg00001.txt.bz2 Content-length: 1323 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23960 --- Comment #44 from John Paul Adrian Glaubitz --- Okay, interesting. It's not qmake that's broken (it's actually built with LARGEFILE64_SOURCE), but qtchooser: (sid-sh4-sbuild)root@epyc:/# qmake qmake: could not find a Qt installation of '' (sid-sh4-sbuild)root@epyc:/# ls -l `which qmake` lrwxrwxrwx 1 root root 9 Nov 27 20:22 /usr/bin/qmake -> qtchooser (sid-sh4-sbuild)root@epyc:/# /usr/bin/qtchooser -qt=3D5 -run-tool=3Dqmake qtchooser: could not find a Qt installation of '5' (sid-sh4-sbuild)root@epyc:/# For comparison, here is qtchooser natively: root@epyc:~> qtchooser -qt=3D5 -run-tool=3Dqmake Usage: /usr/lib/qt5/bin/qmake [mode] [options] [files] QMake has two modes, one mode for generating project files based on some heuristics, and the other for generating makefiles. Normally you shouldn't need to specify a mode, as makefile generation is the default mode for qmake, but you may use this to test qmake on an existing project (...) I have already tried building qtchooser with -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE, but that didn't help so far. Source of qtchoser is here: https://code.qt.io/cgit/qtsdk/qtchooser.git/ --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-45372-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed May 01 12:56:04 2019 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 10826 invoked by alias); 1 May 2019 12:56:03 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 10818 invoked by uid 89); 1 May 2019 12:56:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,T_FILL_THIS_FORM_SHORT autolearn=ham version=3.3.1 spammy=campaigns, H*UA:14.0, H*x:14.0, company's X-HELO: sonic306-25.consmr.mail.sg3.yahoo.com Received: from sonic306-25.consmr.mail.sg3.yahoo.com (HELO sonic306-25.consmr.mail.sg3.yahoo.com) (106.10.241.145) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 May 2019 12:56:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1556715358; bh=hWcfEmzx59mMYf2Nf3wMxA8tIZjgTC5EUclEWCIXseY=; h=From:To:References:In-Reply-To:Subject:Date:From:Subject; b=th65jhfy1hw0ghvmxOv9V9Hfk3PmuzjGYNKSPLhWcG/jnoGRqBDSTyVAlPV8pLUCf+nRp//LVe5EyxbZ0YTfpayU84x5ERm0EL54s5TcxB89TbAH6lVX79LEZpKUt64AZ7bx+kM6bhXWxyRYVtrvREPKqBChxw4YCYXJErNtwvB0nxhZT/WWZpr5+JfMPHUNdOly1/1NKU1dmnyhZ06v8Nj4E2GhBO8JTlOzYngLbphNVJXymbtcRb/nIukL9pXtsz25nXtSYaztXP1q4Ol3mfrS4lNgGmgEIuOfUcTRtdAv6joWJ0tYF6IMmyj3ZBmc6KAA6Ax3uaDgT7Ik/I+rYA== Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.sg3.yahoo.com with HTTP; Wed, 1 May 2019 12:55:58 +0000 Received: from 175.100.147.89 (EHLO Admin11PC) ([175.100.147.89]) by smtp427.mail.sg3.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b95a9f03cf8c3ec57599367e857e22c0 for ; Wed, 01 May 2019 12:55:55 +0000 (UTC) From: "Sara James" To: References: In-Reply-To: Subject: RE: Cisco Live USA ( San Diego, CA) - Register Portal List 2019 Date: Wed, 01 May 2019 12:56:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00002.txt.bz2 Content-length: 1548 Hello, Hope you're doing good. I'm not sure that you received my previous email, I just wanted to follow-up and see if you are interested in purchasing the Attendee List. I look forward to hearing from you. Regards, Sara James From: Sara James [mailto:abacobuz2@abacobuz.com] Sent: Monday, April 29, 2019 8:19 AM To: 'glibc-bugs@sourceware.org' Subject: Cisco Live USA ( San Diego, CA) - Register Portal List 2019 Importance: High Dear Exhibitors May we wish you every success in the forthcoming exhibition. Cisco Live USA 2019 Updated attendees List is Available now. Use of the mailing list is meant to facilitate your company's pre-show and post-show marketing efforts with the License Agreement allows for a unlimited of the list. Information fields include: Contact name, Company name, Job Title, Company Mailing address with Zip Code, Phone Number, Fax Number, SIC Code, Industry Classification, Website URL and contact person verified business email address and LinkedIn Profile. The complete list is available for a small investment, with unlimited usage rights, you can use this list for your regular marketing campaigns too. Pre-event campaigns with booth information can increase footfalls to booth by 80%. NOTE: If you think I should be talking to someone else, please forward the E-mail and do help me in reaching them. Looking back to hearing from you. Regards, Sara James Cisco Live USA 2019 - Event Attendees Specialist. 09 - 13 June, 2019 | San Diego, CA