[Lldb-commits] [Diffusion] rL234178: We have an issue where if you use a C function right now that has no prototype…

Greg Clayton clayborg at gmail.com
Thu Apr 9 11:26:46 PDT 2015


We aren't talking about "S" here we are talking about "myInt" which is in the source code myInt::myInt(int) or _ZN5myIntC1Ei. That should be in the object file. 

cd lldb/test/functionalities/data-formatter/data-formatter-synthval
make
% dsymutil -s a.out | grep _ZN5myIntC1Ei
[    16] 0000010c 24 (N_FUN        ) 01     0000   0000000100000ee0 '__ZN5myIntC1Ei'
[    33] 0000015f 1e (PEXT SECT    ) 01     0080   0000000100000ee0 '__ZN5myIntC1Ei'

So the symbol is there for MacOSX with clang. Not there on other systems as it is _ZN3fooC2Ei

  <ctor-dtor-name> ::= C1	# complete object constructor
		   ::= C2	# base object constructor
		   ::= C3	# complete object allocating constructor
		   ::= D0	# deleting destructor
		   ::= D1	# complete object destructor
		   ::= D2	# base object destructor


So it looks like it has only the base object constructor (C2), not the "complete object constructor" (C1).

So the code looks like this:

class myInt {
    private: int theValue;
    public: myInt() : theValue(0) {}
    public: myInt(int _x) : theValue(_x) {}
    int val() { return theValue; }
};

class hasAnInt {
    public:
        myInt theInt;
        hasAnInt() : theInt(42) {}  
};

myInt operator + (myInt x, myInt y) { return myInt(x.val() + y.val()); }

int main() {
    myInt x{3};
    myInt y{4};
    myInt z {x+y};
    hasAnInt hi;
    return z.val(); // break here
}

This might be due to trying to use the initializer lists instead of using a default constructor. Luckily the expression we later try to run also uses the initializer lists:

self.expect("expression struct S { myInt theInt{12}; }; S()", substrs = ['(theInt = 12)'])


The question is does this just work if we change the code to:

class myInt {
    private: int theValue;
    public: myInt() : theValue(0) {}
    public: myInt(int _x) : theValue(_x) {}
    int val() { return theValue; }
};

class hasAnInt {
    public:
        myInt theInt;
        hasAnInt() : theInt(42) {}  
};

myInt operator + (myInt x, myInt y) { return myInt(x.val() + y.val()); }

int main() {
    myInt x(3);
    myInt y(4);
    myInt z(x+y);
    hasAnInt hi;
    return z.val(); // break here
}

And the expression to be "expression struct S { myInt theInt(12); }; S()".

Maybe it will just work? 

If we do fix this test, we need to add a C++ test that fails that we can make a compiler fix for and mark as an expected fail.





More information about the lldb-commits mailing list