Re: [DynInst_API:] Dyninst-9.2 compile error on Intel Phi

[Jim Galarowicz <jeg@xxxxxxxxxxxxx>]

Hi Bill,

On 07/06/2016 01:25 PM, Bill Williams wrote:

My mistake; the actual definition you want is in Type-mem.h. That'll drag in the function definition, not just the declaration, and should make the linker behave.

--bw

Yes, that worked!  Thanks!

I made it through symtabAPI to parseAPI where this shows up.

Jim G

[ 38%] Building CXX object parseAPI/CMakeFiles/parseAPI.dir/__/dataflowAPI/src/InstructionCache.C.o
[ 39%] Building CXX object parseAPI/CMakeFiles/parseAPI.dir/__/dataflowAPI/src/liveness.C.o
[ 39%] Building CXX object parseAPI/CMakeFiles/parseAPI.dir/__/dataflowAPI/src/RegisterMap.C.o
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0/dataflowAPI/src/RegisterMap.C(53): error: no operator "=" matches these operands
            operand types are: Dyninst::DataflowAPI::RegisterMap = {...}
        mrmap = {
              ^

/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0/dataflowAPI/src/RegisterMap.C(129): error: no operator "=" matches these operands
            operand types are: Dyninst::DataflowAPI::RegisterMap = {...}
        mrmap = {
              ^

/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0/dataflowAPI/src/RegisterMap.C(304): error: no operator "=" matches these operands
            operand types are: Dyninst::DataflowAPI::RegisterMap = {...}
        mrmap = {
              ^

/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0/dataflowAPI/src/RegisterMap.C(484): error: no operator "=" matches these operands
            operand types are: Dyninst::DataflowAPI::RegisterMap = {...}
        mrmap = {
              ^

compilation aborted for /nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0/dataflowAPI/src/RegisterMap.C (code 2)
make[2]: *** [parseAPI/CMakeFiles/parseAPI.dir/__/dataflowAPI/src/RegisterMap.C.o] Error 2
make[1]: *** [parseAPI/CMakeFiles/parseAPI.dir/all] Error 2

On 07/06/2016 12:42 PM, Jim Galarowicz wrote:

Hi Bill,

Adding Type.h didn't change the behaviour unless it needs to be in a specific location in the include block?
This is the front-end build for MIC, so it is a x86_64 build.
I don't have this problem on my x864_64 laptop though.

Jim G


grep typeRef */*/*
dyninstAPI/src/BPatch_typePrivate.h:#define DYNINST_CLASS_NAME BPatch_typeRef
dyninstAPI/src/BPatch_typePrivate.h:class BPATCH_DLL_EXPORT BPatch_typeRef : public BPatch_type, public BPatch_fieldListInterface, public BPatch_rangedInterface {
dyninstAPI/src/BPatch_typePrivate.h:   BPatch_typeRef(int _ID, BPatch_type *_refType, const char *_name = NULL);
dyninstAPI/src/BPatch_typePrivate.h:   ~BPatch_typeRef() { refType->decrRefCount(); }
symtabAPI/doc/2-Abstractions.tex:            node [class2] (typeRef) {typeRef}
symtabAPI/doc/2-Abstractions.tex:            node [class2, below of=typeRef] (typePointer) {typePointer}
symtabAPI/doc/symtab-text.txt:typeRef *getRefType()
symtabAPI/doc/symtab-text.txt:    If this Type object represents a Reference type, then return the object casting the Type object to typeRef otherwise return NULL.
symtabAPI/doc/symtab-text.txt:6.2.7.3 Class typeRef
symtabAPI/doc/symtab-text.txt:static typeRef *create(string &name, Type *ptr, int size,
symtabAPI/h/Type.h:class typeRef;
symtabAPI/h/Type.h:   typeRef *getRefType();
symtabAPI/h/Type.h:class SYMTAB_EXPORT typeRef : public derivedType {