[Bug 285401] x11/libxkbcommon: after recent updates to 1.8.0 and 1.8.1 several ports may need a PORTREVISION bump

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285401

--- Comment #68 from Mark Millard <[email protected]> ---
(In reply to Dimitry Andric from comment #62)
(In reply to Baptiste Daroussin from comment #59)

I have identified the code in lld/ELF/Writer.cpp 's
Writer<ELFT>::finalizeSections() that avoids reporting
a "diagnose" for the likes of environ and __progname
issue in main [so: 15+].

In the later, larger quote of text it is the part:

     for (SharedFile *file : ctx.sharedFiles) {
        bool allNeededIsKnown =
            llvm::all_of(file->dtNeeded, [&](StringRef needed) {
              return symtab.soNames.count(CachedHashStringRef(needed));
            });
        if (!allNeededIsKnown)
          continue;
. . . (dispose activity for file goes here, for example) . . .

Basically it avoids doing "diagnose" activity based
on the incomplete information if something like:

 0x0000000000000001 NEEDED               Shared library: [libsys.so.7]

has not been processed that could contribute for
file. (From it's view of view the missing material
could be what supplies what would end up doing a
diagnose on, thus producing potential false positives.)

So it looks like getting the diagnose output for 15+
of FreeBSD would mean this is the area that would
need to have FreeBSD specific code dealing with the
libc.so.* needing its matching libsys.so.* but just
the libsys.so.* being missing for the libc.so.* :
still diagnose such a file context.


I'll note that on 15+ libc.so.7 actually has 5 undefined
GLOBALs, instead of 2, although the other 3 have:
"@FBSDprivate_1.0 (12)" as well:

     2: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND environ
     3: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __progname
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_elf_aux_info@FBSDprivate_1.0 (12)
     5: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND
__elf_aux_vector@FBSDprivate_1.0 (12)
     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
__libsys_interposing_slot@FBSDprivate_1.0 (12)



For reference, the larger quote of code for this is:

    if (config->unresolvedSymbolsInShlib != UnresolvedPolicy::Ignore) {
      auto diagnose =
          config->unresolvedSymbolsInShlib == UnresolvedPolicy::ReportError
              ? errorOrWarn
              : warn;
      // Error on undefined symbols in a shared object, if all of its DT_NEEDED
      // entries are seen. These cases would otherwise lead to runtime errors
      // reported by the dynamic linker.
      //
      // ld.bfd traces all DT_NEEDED to emulate the logic of the dynamic linker
      // to catch more cases. That is too much for us. Our approach resembles
      // the one used in ld.gold, achieves a good balance to be useful but not
      // too smart.
      //
      // If a DSO reference is resolved by a SharedSymbol, but the SharedSymbol
      // is overridden by a hidden visibility Defined (which is later discarded
      // due to GC), don't report the diagnostic. However, this may indicate an
      // unintended SharedSymbol.
      for (SharedFile *file : ctx.sharedFiles) {
        bool allNeededIsKnown =
            llvm::all_of(file->dtNeeded, [&](StringRef needed) {
              return symtab.soNames.count(CachedHashStringRef(needed));
            });
        if (!allNeededIsKnown)
          continue;
        for (Symbol *sym : file->requiredSymbols) {
          if (sym->dsoDefined)
            continue;
          if (sym->isUndefined() && !sym->isWeak()) {
            diagnose("undefined reference: " + toString(*sym) +
                     "\n>>> referenced by " + toString(file) +
                     " (disallowed by --no-allow-shlib-undefined)");
          } else if (sym->isDefined() && sym->computeBinding() == STB_LOCAL) {
            diagnose("non-exported symbol '" + toString(*sym) + "' in '" +
                     toString(sym->file) + "' is referenced by DSO '" +
                     toString(file) + "'");
          }
        }
      }
    }

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