From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7CD69385B835; Thu, 16 Apr 2020 16:00:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7CD69385B835 From: "mark at klomp dot org" To: elfutils-devel@sourceware.org Subject: [Bug general/24498] 0.176: isn't LTO ready Date: Thu, 16 Apr 2020 16:00:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: elfutils X-Bugzilla-Component: general X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: ASSIGNED 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: 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-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:00:43 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24498 --- Comment #15 from Mark Wielaard --- Thanks for that setup. It allows me to play a bit more with LTO. One commit to help with one issue has been pushed already: commit 39f28eaf8c821d71d57ffc759655ec4168d0bead Author: Mark Wielaard Date: Thu Apr 16 17:45:31 2020 +0200 libdwfl: Initialize bits to NULL in dwfl_standard_find_debuginfo for LT= O. GCC10 LTO is too smart (and somewhat cryptic): find-debuginfo.c: In function =E2=80=98dwfl_standard_find_debuginfo= =E2=80=99: debuginfod-client.c:85:8: error: =E2=80=98bits=E2=80=99 may be used= uninitialized in this function [-Werror=3Dmaybe-uninitialized] find-debuginfo.c:360:24: note: =E2=80=98bits=E2=80=99 was declared = here lto1: all warnings being treated as errors So it inlines __libdwfl_debuginfod_find_debuginfo into dwfl_standard_find_debuginfo and since it cannot see into the function pointer (*fp_debuginfod_find_debuginfo), it assumes that build_id_bit (=3D=3D bits in dwfl_standard_find_debuginfo) will be used by the called function and it might not be initialized. But if you read the code the there is a check for build_id_len > 0 to see whether bits is or isn't initialized before using bits. But gcc isn't smart enough to figure that out. Maybe that actually should be an heuristic gcc lto should use. If the callchain I am inlining is so deep that I cannot figure out maybe-uninitialized variables anymore I should stop inlining. For now just help GCC out and initialize bits to NULL. Signed-off-by: Mark Wielaard I am not sure what to do about the various error: stack usage might be unbounded [-Werror=3Dstack-usage=3D] when "linking" the various tools. If you look at the src/Makefile.am you'll see that for each file we make su= re to build with -Wno-stack-usage=3D But since lto1 combines both files that h= ave been compiled with and without that warning flag it reappears again. The only workaround for now is using CFLAGS=3D"... -Wno-error=3Dstack-usage= =3D" when building inside the src/ directory. Which is a little ugly because it will disable the error also when it should be checked... --=20 You are receiving this mail because: You are on the CC list for the bug.=