public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.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	[thread overview]
Message-ID: <bug-24498-10460-DZV63roHKj@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-24498-10460@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=24498

--- Comment #15 from Mark Wielaard <mark at klomp dot org> ---
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 <mark@klomp.org>
Date:   Thu Apr 16 17:45:31 2020 +0200

    libdwfl: Initialize bits to NULL in dwfl_standard_find_debuginfo for LTO.

    GCC10 LTO is too smart (and somewhat cryptic):

        find-debuginfo.c: In function ‘dwfl_standard_find_debuginfo’:
        debuginfod-client.c:85:8: error: ‘bits’ may be used uninitialized
        in this function [-Werror=maybe-uninitialized]
        find-debuginfo.c:360:24: note: ‘bits’ 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 (== 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 <mark@klomp.org>

I am not sure what to do about the various error: stack usage might be
unbounded [-Werror=stack-usage=] when "linking" the various tools.

If you look at the src/Makefile.am you'll see that for each file we make sure
to build with -Wno-stack-usage= But since lto1 combines both files that have
been compiled with and without that warning flag it reappears again.

The only workaround for now is using CFLAGS="... -Wno-error=stack-usage=" when
building inside the src/ directory. Which is a little ugly because it will
disable the error also when it should be checked...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2020-04-16 16:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28 19:49 [Bug general/24498] New: " kloczko.tomasz at gmail dot com
2019-04-28 20:25 ` [Bug general/24498] " mark at klomp dot org
2019-04-28 20:25 ` mark at klomp dot org
2019-04-28 20:37 ` kloczko.tomasz at gmail dot com
2019-04-28 20:43 ` mark at klomp dot org
2019-09-15 13:57 ` kloczko.tomasz at gmail dot com
2019-10-04  7:39 ` mark at klomp dot org
2020-03-30 22:11 ` kloczko.tomasz at gmail dot com
2020-04-02 11:14 ` mark at klomp dot org
2020-04-10 19:47 ` mark at klomp dot org
2020-04-15  5:12 ` marxin.liska at gmail dot com
2020-04-15  7:03 ` kloczko.tomasz at gmail dot com
2020-04-15  7:07 ` marxin.liska at gmail dot com
2020-04-15 12:50 ` mark at klomp dot org
2020-04-15 13:56 ` mark at klomp dot org
2020-04-15 15:53 ` kloczko.tomasz at gmail dot com
2020-04-16 16:00 ` mark at klomp dot org [this message]
2020-04-16 17:04 ` mark at klomp dot org
2020-04-17  9:42 ` mark at klomp dot org
2020-04-17 10:36 ` mark at klomp dot org
2020-05-06 14:39 ` mark at klomp dot org
2020-05-06 15:23 ` kloczko.tomasz at gmail dot com
2020-05-06 15:25 ` kloczko.tomasz at gmail dot com
2020-05-06 16:10 ` mark at klomp dot org
2020-05-06 16:10 ` [Bug general/24498] 0.179: " mark at klomp dot org
2020-05-06 17:28 ` kloczko.tomasz at gmail dot com
2022-04-24 18:14 ` mark at klomp dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-24498-10460-DZV63roHKj@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).