binutils-2.37-25.fc36.x86_64
gcc-12.0.1-0.6.fc36.x86_64

(In reply to Tom "spot" Callaway from comment #0)
 
> /usr/bin/ld: /usr/bin/ld: DWARF error: could not find abbrev number 43

I am fairly sure that this error message is unrelated to the main problem.  
Although it does indicate the possibility that some debug information is
missing.

 
> undefined reference to `void
> Ice::X8664::emitIASRegOpTyGPR<true, true>(Ice::Cfg const*, Ice::Type,
> Ice::Variable const*, Ice::Operand const*,
> Ice::X8664::AssemblerX8664::GPREmitterRegOp const&)'

 
> Notably,
> obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceInstX8664.o
> is included within it, and seems to possess the symbol that ld thinks is
> missing:
> 
> $ eu-readelf -s
> obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceInstX8664.o
> |grep emitIASRegOpTyGPR
>   274: 0000000000000000    554 FUNC    LOCAL  DEFAULT      741
> _ZN3Ice5X866417emitIASRegOpTyGPRILb0ELb1EEEvPKNS_3CfgENS_4TypeEPKNS_8Variable
> EPKNS_7OperandERKNS0_14AssemblerX866415GPREmitterRegOpE.isra.0


Ah - but this is a LOCAL symbol, so it cannot be seen outside of IceInstX864.o...

Is this a recent regression ?  Ie could it have been triggered by the 
change from gcc-11 to gcc-12 ?

Cheers
  Nick

Is this during some src.rpm build?  I think I'd need to reproduce to see the debug info in detail to see if it is a gcc or binutils bug.

Yeah, but it is chromium. If you checkout the chromium Fedora git package, and build from rawhide, you should hit this.

I've tried to reproduce that, but didn't get that far.
My build (latest fc35 src.rpm) fails with:
In file included from ../../base/third_party/symbolize/symbolize.cc:64:
../../base/third_party/symbolize/symbolize.h: In constructor 'google::FileDescriptor::FileDescriptor(google::FileDescriptor&&)':
../../base/third_party/symbolize/symbolize.h:123:53: error: 'exchange' is not a member of 'std'
  123 |   FileDescriptor(FileDescriptor&& other) : fd_(std::exchange(other.fd_, -1)) {}
      |                                                     ^~~~~~~~
../../base/third_party/symbolize/symbolize.h: In member function 'google::FileDescriptor& google::FileDescriptor::operator=(google::FileDescriptor&&)':
../../base/third_party/symbolize/symbolize.h:127:18: error: 'exchange' is not a member of 'std'
  127 |       fd_ = std::exchange(rhs.fd_, -1);
      |                  ^~~~~~~~
Since https://gcc.gnu.org/r12-2534-g16158c96496b537194111526d25e19f268d613b6
<algorithm> no longer includes <utility>.

Apologies, I forgot to push that change, the patch for that and the updated spec are now in rawhide git.

For the /usr/bin/ld: /usr/bin/ld: DWARF error: could not find abbrev number 43 diagnostics, I suspect a binutils bug.
This is -gsplit-dwarf, the diagnostics is on
obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.o
which contains in its skeleton DW_TAG_skeleton_unit DW_AT_dwo_name
obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo
Now, eu-readelf -w is unhappy about it too, because it wants to treat that
obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo
name as relative to the object, but if I
$ cp obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.o IceTargetLoweringX8664.o
then eu-readelf -w IceTargetLoweringX8664.o
doesn't print anything to stderr and is happy about it (and that one prints not just the skeleton but also the .dwo file content).
$ readelf -wi IceTargetLoweringX8664.o
is happy too, but that just prints the skeleton.
$ readelf -wi obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo >/dev/null
readelf: obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo: Warning: Unrecognized form: 0x23
readelf: obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo: Warning: DIE at offset 0xab917 refers to abbreviation number 2293759 which does not exist
$ eu-readelf -w obj/third_party/swiftshader/src/Reactor/swiftshader_subzero/IceTargetLoweringX8664.dwo >/dev/null
The last one doesn't print anything.

As for the other errors, the undefined symbol in IceTargetLoweringX8664.o is
_ZN3Ice5X866417emitIASRegOpTyGPRILb1ELb1EEEvPKNS_3CfgENS_4TypeEPKNS_8VariableEPKNS_7OperandERKNS0_14AssemblerX866415GPREmitterRegOpE
12 times.
And the fact that it is undefined in that TU looks completely correct, IceInstX8664.h has:
/// Emit a two-operand (GPR) instruction, where the dest operand is a Variable
/// that's guaranteed to be a register.
template <bool VarCanBeByte = true, bool SrcCanBeByte = true>
void emitIASRegOpTyGPR(const Cfg *Func, Type Ty, const Variable *Dst,
                       const Operand *Src, const GPREmitterRegOp &Emitter);
declaration and doesn't provide definition.  If I compile the same TU with g++ 11.2.1, I get the same undefined refs there.

The template definition is in IceInstX8664.cpp:
template <bool VarCanBeByte, bool SrcCanBeByte>
void emitIASRegOpTyGPR(const Cfg *Func, Type Ty, const Variable *Var,
                       const Operand *Src, const GPREmitterRegOp &Emitter) {
...
}
and the template function is called in a few spots later in the TU, but doesn't seem to be explicitly instantiated.
When IceInstX8664.ii is compiled with cc1plus 12.0.1, we get only
_ZN3Ice5X866417emitIASRegOpTyGPRILb1ELb1EEEvPKNS_3CfgENS_4TypeEPKNS_8VariableEPKNS_7OperandERKNS0_14AssemblerX866415GPREmitterRegOpE.isra.0
symbols in there, while with cc1plus 11.2.1 we get
_ZN3Ice5X866417emitIASRegOpTyGPRILb1ELb1EEEvPKNS_3CfgENS_4TypeEPKNS_8VariableEPKNS_7OperandERKNS0_14AssemblerX866415GPREmitterRegOpE
instead.
This changed in https://gcc.gnu.org/r12-578
for the emitIASRegOpTyGPR function template.
With my limited C++ knowledge, I think it is bug in chromium where it can't rely on implicit instantiation making the symbol available and would need to
instantiate it explicitly.

Reduced testcase where in GCC11 and until r12-577 the symbol is exported from the TU when it is implicitly instantiated, while with r12-578 and later it is not, just -O2 is needed:
template <class To> struct cast_retty_impl { typedef To *ret_type; };
template <class, class, class> struct cast_retty_wrap;
template <class To, class FromTy> struct cast_retty_wrap<To, FromTy, FromTy> {
  typedef typename cast_retty_impl<To>::ret_type ret_type;
};
template <class To> struct cast_retty {
  typedef typename cast_retty_wrap<To, int, int>::ret_type ret_type;
};
template <class X, class Y> typename cast_retty<X>::ret_type dyn_cast(Y);
namespace Ice {
enum Type {};
struct Cfg {
  template <typename T> T *getAssembler() const;
};
class Operand {};
struct Variable {
  bool hasReg();
};
class Inst {
  virtual void emitIAS(const Cfg *) const;
};
struct RegX8664 {
  enum GPRRegister {};
  static GPRRegister getEncodedGPR();
};
namespace X8664 {
using RegisterSet = RegX8664;
using GPRRegister = RegisterSet::GPRRegister;
struct AsmAddress {
  AsmAddress(int *);
};
struct AssemblerX8664 {
  using TypedEmitGPRGPR = void (AssemblerX8664::*)(Type, GPRRegister,
                                                   GPRRegister);
  using TypedEmitGPRAddr = void (AssemblerX8664::*)(Type, GPRRegister,
                                                    AsmAddress);
  struct GPREmitterRegOp {
    TypedEmitGPRGPR GPRGPR;
    TypedEmitGPRAddr GPRAddr;
  };
};
using Assembler = AssemblerX8664;
using TargetLowering = int;
using GPREmitterRegOp = Assembler::GPREmitterRegOp;
struct InstX86Base : Inst {
  static TargetLowering *getTarget();
};
template <bool = true, bool = true>
void emitIASRegOpTyGPR(const Cfg *, Type, const Variable *, const Operand *,
                       const GPREmitterRegOp &);
class InstX86Mov : InstX86Base {
  void emitIAS(const Cfg *) const;
};
template <bool, bool>
void emitIASRegOpTyGPR(const Cfg *Func, Type Ty, const Variable *,
                       const Operand *Src, const GPREmitterRegOp &Emitter) {
  auto Target = InstX86Base::getTarget();
  Assembler *Asm = Func->getAssembler<Assembler>();
  GPRRegister VarReg = RegX8664::getEncodedGPR();
  if (auto SrcVar = dyn_cast<Variable>(Src))
    if (SrcVar->hasReg()) {
      GPRRegister SrcReg = RegX8664::getEncodedGPR();
      (Asm->*Emitter.GPRGPR)(Ty, VarReg, SrcReg);
      AsmAddress SrcStackAddr(Target);
      (Asm->*Emitter.GPRAddr)(Ty, VarReg, SrcStackAddr);
    }
}
void InstX86Mov::emitIAS(const Cfg *Func) const {
  Variable Dest;
  Operand Src;
  Type DestTy;
  GPREmitterRegOp GPRRegEmitter;
  emitIASRegOpTyGPR(Func, DestTy, &Dest, &Src, GPRRegEmitter);
}
}
}

For the binutils bug I've filed sw#28915.

Created attachment 1863204 [details]
electron-16-fix-swiftshader-template.patch

The attached patch fixes the issue for me. I've moved the definition of the template to the header file.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.