]> git.ipfire.org Git - thirdparty/elfutils.git/commit
libdwfl: Initialize bits to NULL in dwfl_standard_find_debuginfo for LTO.
authorMark Wielaard <mark@klomp.org>
Thu, 16 Apr 2020 15:45:31 +0000 (17:45 +0200)
committerMark Wielaard <mark@klomp.org>
Thu, 16 Apr 2020 15:45:31 +0000 (17:45 +0200)
commit39f28eaf8c821d71d57ffc759655ec4168d0bead
tree6f13f166ef81d13860d4323e777a1d5300734b85
parent1a9fe4bfa71b6ad87555ef8e5b204e2ad3285213
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>
libdwfl/ChangeLog
libdwfl/find-debuginfo.c