Summary: | sys-fs/xfsprogs-5.5.0: Building with -O3 results in <artificial>:(.text+0x19f0): undefined reference to `.L366' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Piotr Karbowski (RETIRED) <slashbeast> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | andre, mjo, stylinae, vivo75, yellowhat46 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Piotr Karbowski (RETIRED)
2020-03-15 14:02:14 UTC
This looks like maybe an LTO related problem? I am having this with -O2 too Sorry forget that I didn't look right. I have -O3 too. Problem persists in sys-fs/xfsprogs-5.6.0. Same for me on 5.6.0 and -O3 The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9f48774c6b67f91e120b1e993820f981a9161d71 commit 9f48774c6b67f91e120b1e993820f981a9161d71 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2020-04-18 12:39:39 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-04-18 12:39:39 +0000 sys-fs/xfsprogs: Build fails with -O3. Replaced with -O2 Closes: https://bugs.gentoo.org/712698 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-fs/xfsprogs/xfsprogs-5.5.0.ebuild | 3 +++ sys-fs/xfsprogs/xfsprogs-5.6.0.ebuild | 3 +++ 2 files changed, 6 insertions(+) Instead of just ignoring peoples' CFLAGS from now on... can someone experiencing this problem try to figure out which commit introduced the breakage? I mentioned this bug on IRC (#xfs in freenode) and this was the response: <sandeen> mjo, is that a regression? <sandeen> doubt it's related to any xfsprogs change but if you can narrow it down to one ,let us know on the list please Re-opening since this isn't really "fixed". This is indeed triggered by the combination of -O3 and LTO. (In reply to Michael Orlitzky from comment #7) > Instead of just ignoring peoples' CFLAGS from now on... can someone > experiencing this problem try to figure out which commit introduced the > breakage? a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc is the first bad commit commit a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc Author: Darrick J. Wong <darrick.wong@oracle.com> Date: Wed Jan 22 11:29:37 2020 -0500 xfs: always log corruption errors Source kernel commit: a5155b870d687de1a5f07e774b49b1e8ef0f6f50 Make sure we log something to dmesg whenever we return -EFSCORRUPTED up the call stack. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eric Sandeen <sandeen@sandeen.net> libxfs/libxfs_priv.h | 2 ++ libxfs/util.c | 13 +++++++++++++ libxfs/xfs_alloc.c | 9 +++++++-- libxfs/xfs_attr_leaf.c | 12 +++++++++--- libxfs/xfs_bmap.c | 8 +++++++- libxfs/xfs_btree.c | 5 ++++- libxfs/xfs_da_btree.c | 24 ++++++++++++++++++------ libxfs/xfs_dir2.c | 4 +++- libxfs/xfs_dir2_leaf.c | 4 +++- libxfs/xfs_dir2_node.c | 12 +++++++++--- libxfs/xfs_inode_fork.c | 6 ++++++ libxfs/xfs_refcount.c | 4 +++- libxfs/xfs_rtbitmap.c | 5 +++-- 13 files changed, 87 insertions(+), 21 deletions(-) bisect run success $ git bisect log # bad: [0618c372868777d287168965bbcfe5f963d34893] xfsprogs: Release v5.6.0 # good: [0cfb2952319d237f1d079097810546f24e3883bf] xfsprogs: Release v5.4.0 git bisect start 'master' 'v5.4.0' # bad: [dda1a0a27059ee2d7b2913ff465504d2c808d945] xfsprogs: alphabetize libxfs_api_defs.h git bisect bad dda1a0a27059ee2d7b2913ff465504d2c808d945 # bad: [5e9bc7eef8bf1da148dbf9f3a686b723b8f9dbe4] xfs: remove the data_dot_offset field in struct xfs_dir_ops git bisect bad 5e9bc7eef8bf1da148dbf9f3a686b723b8f9dbe4 # bad: [530bc0fc4799b3edfb5803b9fd6a50ee3c087e07] xfs: null out bma->prev if no previous extent git bisect bad 530bc0fc4799b3edfb5803b9fd6a50ee3c087e07 # good: [b6d2b93c4e45aaca317b0b1723d97e8377e4bf3b] xfs: fix inode fork extent count overflow git bisect good b6d2b93c4e45aaca317b0b1723d97e8377e4bf3b # good: [2ac7663ab1e4c3b0f753e0b50dc8adf18a9bc1ca] xfs: refactor xfs_bmapi_allocate git bisect good 2ac7663ab1e4c3b0f753e0b50dc8adf18a9bc1ca # good: [d11b23b618a137a817a962eaa59e3b8978da6ef0] xfs: relax shortform directory size checks git bisect good d11b23b618a137a817a962eaa59e3b8978da6ef0 # bad: [3af5535c24d13160b3a05d34569affaae2f0e941] xfs: decrease indenting problems in xfs_dabuf_map git bisect bad 3af5535c24d13160b3a05d34569affaae2f0e941 # bad: [a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc] xfs: always log corruption errors git bisect bad a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc # first bad commit: [a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc] xfs: always log corruption errors (In reply to Matt Whitlock from comment #10) I can confirm that bisect result. Just a guess but I think it might be the function defined in xfs_error.c that's the problem (and how the symbols are exported). Most everything else is a macro for that calls into a logging function that was already there. It also seems that upstream moved where that file is defined (in the master branch, anyway). |