Can dmd compile with my own runtime library?

[Frits van Bommel]

Huang F Guan wrote:
> Frits van Bommel Wrote:
> 
>>> I'm not sure what exactly this is about, I've run in the the same 
>>> problems lately. I think it's some (static) initialization code for 
>>> TypeInfo, or at least that's what the mangled name suggests. Try to add 
>>> an implementation for init in the TypeInfo definition in object.d.
>> It's not a function. As I think I mentioned in my other post[1], though 
>> perhaps not with so many words, this is part of what DMD emits when it 
>> encounters a class called TypeInfo_Aa (The name used for the result type 
>> of typeid(char[]).
>>
> 
> I solved this problem by defining a function like below:
> void _D11TypeInfo_Aa6__initZ()
> {
> 	while(1){}
> }
> But it is stupid to do such a thing.

Yes it is, because *it's not supposed to be a function*!
Just take phobos/std/typeinfo/ti_Ag.d[1], implement or replace memcmp 
and std.string.cmp, and put it into your source tree. Problem solved.


[1] or the equivalent file from Tango, IIRC 
tango/lib/compiler/{dmd,gdc}/typeinfo/ti_Ag.d

> Now my object.d can be linked well. 

It may link (assuming that function is declared extern(C)), but does it 
do what it's supposed to do?

Try running something like this, compiled with your function above 
linked in:
---
void test2(...) {
     // Replace "writefln" with whatever function you use for text output
     writefln(_arguments[0].toString);
}

void test() {
     test("string");
}
---
The expected output when calling test() would be "char[]", but I'm 
pretty sure it won't be if your function replaced the initialization 
*data* of typeid(char[])...
(Hint: the first four bytes of that function probably don't point to a 
meaningful vtable)

> And I want to know how the classinfos get the information of the class, is it stored in a initialized data section?

Yes, ClassInfo instances, like TypeInfo instances, are stored directly 
in data sections by the compiler.

> I wrote this program with my object.d
> 
[snip classes]
> extern (C) int test()
> {
> 	B b = new B;
> 	b.printok();
> 	delete b;
> 	return 2;
> }
> 
> The result is 
> test(): passed
> a.this(): passed
> b.this(): passed
> b.printok() : passed
> b.~this(): not passed
> a.~this(): not passed
> 
> I don't know why the two disconstructors are not passed everytime. When I check the deallocator of the classinfo of these two classes, they are all empty pointers. 
> 
> This is my _d_delclass:
> 
[snip]
> 		if (c.deallocator) //====failed at here!!!!!!!!! 
[snip]

I think that field is to store the overloaded delete operator, if any 
(see http://www.digitalmars.com/d/1.0/class.html#ClassDeallocator). 
Since you didn't overload it they're null (as they usually should be).
In Phobos _d_callfinalizer for classes allocated on the GC heap is 
called somewhere from the '_gc.free' call that you replaced with a 
regular 'free'. Putting an explicit call to 
"_d_callfinalizer(cast(void*) p);" before the free should fix this, I think.