[llvm-bugs] [Bug 47335] New: baremetal DWARF leaves dso_base uninitialized

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Aug 27 15:40:39 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=47335

            Bug ID: 47335
           Summary: baremetal DWARF leaves dso_base uninitialized
           Product: Runtime Libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: libunwind
          Assignee: unassignedbugs at nondot.org
          Reporter: rprichard at google.com
                CC: llvm-bugs at lists.llvm.org

For a -DLIBUNWIND_IS_BAREMETAL=ON configuration that uses DWARF EH (rather than
ARM EHABI), the UnwindInfoSections::dso_base field is read, but never
initialized.

The uninitialized field is copied to unw_proc_info_t::extra, which is also
exposed via _Unwind_Find_FDE's dwarf_eh_bases::tbase field.

dso_base is also used as the key to DwarfFDECache (as the "mh" value -- "mach
header").

An obvious fix is to set dso_base to 0, but then the first
DwarfFDECache::findFDE call ("otherwise, search cache of previously found
FDEs.") will search the entire cache (whereas dynamically-registered are
expected to be searched in a later pass). We could change the full-search
sentinel value to ~0, or add a parameter instead of a sentinel value.

After I make unrelated changes, gcc (but not clang) is able to detect the
uninitialized field:

/x/llvm-upstream/llvm-project/libunwind/src/UnwindCursor.hpp: In member
function ‘void libunwind::UnwindCursor<A, R>::setInfoBasedOnIPRegister(bool)
[with A = libunwind::LocalAddressSpace; R = libunwind::Registers_x86_64]’:
/x/llvm-upstream/llvm-project/libunwind/src/UnwindCursor.hpp:1924:9: warning:
‘sects.libunwind::UnwindInfoSections::dso_base’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
 1924 |         if (getInfoFromFdeCie(fdeInfo, cieInfo, pc, sects.dso_base))
      |         ^~

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200827/50dac898/attachment.html>


More information about the llvm-bugs mailing list