www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - LDC -noruntime

reply "BLM768" <blm768 gmail.com> writes:
I've been trying to write an OS kernel in D, and I'm having 
issues with the runtime. I'm trying to use LDC's -noruntime 
option, which is _supposed_ to prevent any runtime calls from 
being generated, but the linker keeps complaining about 
unresolved references to _d_assert_msg and other runtime 
functions. It seems that LDC is ignoring the switch and is 
generating runtime references anyway. Is there some other way to 
force it to stop trying to pull in the runtime? I'd rather not 
have to create/link a custom runtime at this point; I don't even 
have a memory allocator written, so I really don't want to mess 
with a runtime yet.
Jul 05 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 06-07-2012 08:53, BLM768 wrote:

 I've been trying to write an OS kernel in D, and I'm having issues with
 the runtime. I'm trying to use LDC's -noruntime option, which is
 _supposed_ to prevent any runtime calls from being generated, but the
 linker keeps complaining about unresolved references to _d_assert_msg
 and other runtime functions. It seems that LDC is ignoring the switch
 and is generating runtime references anyway. Is there some other way to
 force it to stop trying to pull in the runtime? I'd rather not have to
 create/link a custom runtime at this point; I don't even have a memory
 allocator written, so I really don't want to mess with a runtime yet.


It's not like compiling without a runtime will make the compiler not 
emit calls; what else would it do for e.g. the 'new' expression? Anyway, 
given your situation, just grab the function prototypes from druntime 
and stub them out, then fill them in later.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jul 06 2012
parent reply "BLM768" <blm768 gmail.com> writes:
 It's not like compiling without a runtime will make the 
 compiler not emit calls; what else would it do for e.g. the 
 'new' expression? Anyway, given your situation, just grab the 
 function prototypes from druntime and stub them out, then fill 
 them in later.


I knew that stuff like "new" wouldn't work without the runtime, 
but code that only does a few struct member accesses and a 
pointer cast shouldn't require runtime functions; that's all 
elementary C stuff. I've worked a little on stubbing out 
functions, but I'd rather not link any extra code to my current 
program, which is just a small 32-bit assembly/D bootstrapper 
that loads the actual 64-bit kernel. Looks like I might have to 
just use assembly, use some C, or write my own compiler.
Jul 06 2012
parent "bearophile" <bearophileHUGS lycos.com> writes:
BLM768:


 I knew that stuff like "new" wouldn't work without the runtime, 
 but code that only does a few struct member accesses and a 
 pointer cast shouldn't require runtime functions; that's all 
 elementary C stuff.


D isn't C, it was not designed for your very uncommon purpose, it 
creates and manages things like moduleinfos, typeinfos, plus it 
initializes the GC even if you don't use it later. And currently 
in some cases D uses heap allocations even when you don't think 
they are needed, like when you define an array literal. Probably 
there are ways to disable each one of those (LDC has ways to 
disable typeinofos, and maybe even moduleinfos), so you have to 
find them all and disable/break/stub them.

Bye,
bearophile
Jul 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-06 08:53, BLM768 wrote:

 I've been trying to write an OS kernel in D, and I'm having issues with
 the runtime. I'm trying to use LDC's -noruntime option, which is
 _supposed_ to prevent any runtime calls from being generated, but the
 linker keeps complaining about unresolved references to _d_assert_msg
 and other runtime functions. It seems that LDC is ignoring the switch
 and is generating runtime references anyway. Is there some other way to
 force it to stop trying to pull in the runtime? I'd rather not have to
 create/link a custom runtime at this point; I don't even have a memory
 allocator written, so I really don't want to mess with a runtime yet.


I'm pretty sure that the only thing the -noruntime flag does is 
preventing the runtime from being linked. It will not prevent the 
compiler for generating calls to the runtime.

So if you see calls to runtime functions you need to stub them out as 
Alex suggested or try to find a way to avoid them. Note that the 
compiler will link with the standard library by default as well. I don't 
know if the -noruntime flag prevents that.

-- 
/Jacob Carlborg
Jul 06 2012
next sibling parent reply "BLM768" <blm768 gmail.com> writes:
On Friday, 6 July 2012 at 09:38:13 UTC, Jacob Carlborg wrote:

 On 2012-07-06 08:53, BLM768 wrote:

 I've been trying to write an OS kernel in D, and I'm having 
 issues with
 the runtime. I'm trying to use LDC's -noruntime option, which 
 is
 _supposed_ to prevent any runtime calls from being generated, 
 but the
 linker keeps complaining about unresolved references to 
 _d_assert_msg
 and other runtime functions. It seems that LDC is ignoring the 
 switch
 and is generating runtime references anyway. Is there some 
 other way to
 force it to stop trying to pull in the runtime? I'd rather not 
 have to
 create/link a custom runtime at this point; I don't even have 
 a memory
 allocator written, so I really don't want to mess with a 
 runtime yet.


 I'm pretty sure that the only thing the -noruntime flag does is 
 preventing the runtime from being linked. It will not prevent 
 the compiler for generating calls to the runtime.

 So if you see calls to runtime functions you need to stub them 
 out as Alex suggested or try to find a way to avoid them. Note 
 that the compiler will link with the standard library by 
 default as well. I don't know if the -noruntime flag prevents 
 that.


The output of the --help switch suggested that it would actually 
keep LDC from generating the calls, but I guess not. Looks like 
I've got a rumtime to stub out. At least I'll understand it 
better when I'm done.
Jul 06 2012
parent reply "BLM768" <blm768 gmail.com> writes:
 The output of the --help switch suggested that it would 
 actually keep LDC from generating the calls, but I guess not. 
 Looks like I've got a rumtime to stub out. At least I'll 
 understand it better when I'm done.


I meant "runtime." Stupid touch-screen keyboard :).
Jul 06 2012
parent reply "K.Wilson" <wilsonk cpsc.ucalgary.ca> writes:
Check out the Xomb OS as they had to stub things in the runtime 
out IIRC, and they use LDC still, I believe. May need to check 
out a very old copy to see what they originally did to get a 
minimal kernel running.


On Friday, 6 July 2012 at 14:40:19 UTC, BLM768 wrote:

 The output of the --help switch suggested that it would 
 actually keep LDC from generating the calls, but I guess not. 
 Looks like I've got a rumtime to stub out. At least I'll 
 understand it better when I'm done.


 I meant "runtime." Stupid touch-screen keyboard :).
Jul 06 2012
parent "BLM768" <blm768 gmail.com> writes:
On Friday, 6 July 2012 at 15:35:17 UTC, K.Wilson wrote:

 Check out the Xomb OS as they had to stub things in the runtime 
 out IIRC, and they use LDC still, I believe. May need to check 
 out a very old copy to see what they originally did to get a 
 minimal kernel running.


I've looked a little at XomB. They've got a "bare bones" kernel 
setup as one of their sub-projects, and I took a glance at the 
runtime. It's a lot smaller than what I started trying to do, 
which was to copy the entire runtime and then prune it back until 
it compiled. I guess I'll do it the other way and copy/write as 
little as possible until it works. I was worried I'd have to 
process most of the runtime so the typeinfo classes would work, 
but it looks like XomB managed to get by with a pretty small 
runtime.
Jul 06 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 6 July 2012 at 09:38:13 UTC, Jacob Carlborg wrote:

 It will not prevent the compiler for generating calls to the 
 runtime.


It should – TypeInfo references will still be generated, though.


 So if you see calls to runtime functions you need to stub them 
 out as Alex suggested or try to find a way to avoid them. Note 
 that the compiler will link with the standard library by 
 default as well. I don't know if the -noruntime flag prevents 
 that.


This is a good point – it doesn't. Use -nodefaultlib (LDC's 
-defaultlib switch works a bit differently than DMD's in that it 
appends to a list of default libs instead of replacing, this 
should imho be fixed).

David
Jul 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-07-06 21:42, David Nadlinger wrote:

 On Friday, 6 July 2012 at 09:38:13 UTC, Jacob Carlborg wrote:

 It will not prevent the compiler for generating calls to the runtime.


 It should – TypeInfo references will still be generated, though.


So what happens with code like this:

auto o = new Object;

It won't generate any code for that? Then what happens with "o", 
uninitialized?

-- 
/Jacob Carlborg
Jul 07 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Friday, 6 July 2012 at 06:53:11 UTC, BLM768 wrote:

 I'm trying to use LDC's -noruntime option […] It seems that 
 LDC is ignoring the switch and is generating runtime references 
 anyway.


If this happens, it is a bug – please report it at 
https://github.com/ldc-developers/ldc/issues.

David
Jul 06 2012
prev sibling parent reply 1100110 <10equals2 gmail.com> writes:
I swear you guys read my mind sometimes...  It's creepy.

I just had this very issue, doing the exact same thing, about an hour ago.

Have you tried with -nodefaultlib -noruntime ?  Cause that's what works  
for me...

I just got *something* to compile with no runtime or std.
Whether or not it actually does anything remains to be seen.


On Fri, 06 Jul 2012 01:53:10 -0500, BLM768 <blm768 gmail.com> wrote:


 I've been trying to write an OS kernel in D, and I'm having issues with  
 the runtime. I'm trying to use LDC's -noruntime option, which is  
 _supposed_ to prevent any runtime calls from being generated, but the  
 linker keeps complaining about unresolved references to _d_assert_msg  
 and other runtime functions. It seems that LDC is ignoring the switch  
 and is generating runtime references anyway. Is there some other way to  
 force it to stop trying to pull in the runtime? I'd rather not have to  
 create/link a custom runtime at this point; I don't even have a memory  
 allocator written, so I really don't want to mess with a runtime yet.



-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jul 06 2012
parent reply "BLM768" <blm768 gmail.com> writes:
On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:

 I swear you guys read my mind sometimes...  It's creepy.

 I just had this very issue, doing the exact same thing, about 
 an hour ago.

 Have you tried with -nodefaultlib -noruntime ?  Cause that's 
 what works for me...

 I just got *something* to compile with no runtime or std.
 Whether or not it actually does anything remains to be seen.


No luck; it still references the runtime.
I've been stubbing out the runtime; it seems to be about done 
except for references to some functions I can't find. The symbols 
are __moddi3 and __divdi3; I assume they're C math library 
functions, as they're generated from code that uses div/mod 
operations. It also seems to be unable to properly find 
Object.toString() after I changed it to be nothrow, which I 
needed to do because I'm stubbing out the exception handling 
routines; it seems to have changed the mangling. It's a bit of a 
mess in there; I'm glad I don't always have to hack up the 
runtime :).
Jul 06 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 07, 2012 05:45:53 BLM768 wrote:

 On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:

 I swear you guys read my mind sometimes...  It's creepy.
 
 I just had this very issue, doing the exact same thing, about
 an hour ago.
 
 Have you tried with -nodefaultlib -noruntime ?  Cause that's
 what works for me...
 
 I just got *something* to compile with no runtime or std.
 Whether or not it actually does anything remains to be seen.


 
 No luck; it still references the runtime.
 I've been stubbing out the runtime; it seems to be about done
 except for references to some functions I can't find. The symbols
 are __moddi3 and __divdi3; I assume they're C math library
 functions, as they're generated from code that uses div/mod
 operations. It also seems to be unable to properly find
 Object.toString() after I changed it to be nothrow, which I
 needed to do because I'm stubbing out the exception handling
 routines; it seems to have changed the mangling. It's a bit of a
 mess in there; I'm glad I don't always have to hack up the
 runtime :).


Yes. nothrow is part of the name mangling, because it's part of the signature. 
In the long run, toString will be  safe const pure nothrow, but it's not there 
quite yet (const correctness and Object is still being sorted out would be one 
reason; a number of key string-related functions need to become pure for 
another). But if the compiler is expecting a specific signature, then that's 
the signature that you're going to have to give it, or the linker's not going 
to find the function when it goes to look for it.

- Jonathan M Davis
Jul 06 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 07-07-2012 06:26, Jonathan M Davis wrote:

 On Saturday, July 07, 2012 05:45:53 BLM768 wrote:

 On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:

 I swear you guys read my mind sometimes...  It's creepy.

 I just had this very issue, doing the exact same thing, about
 an hour ago.

 Have you tried with -nodefaultlib -noruntime ?  Cause that's
 what works for me...

 I just got *something* to compile with no runtime or std.
 Whether or not it actually does anything remains to be seen.


 No luck; it still references the runtime.
 I've been stubbing out the runtime; it seems to be about done
 except for references to some functions I can't find. The symbols
 are __moddi3 and __divdi3; I assume they're C math library
 functions, as they're generated from code that uses div/mod
 operations. It also seems to be unable to properly find
 Object.toString() after I changed it to be nothrow, which I
 needed to do because I'm stubbing out the exception handling
 routines; it seems to have changed the mangling. It's a bit of a
 mess in there; I'm glad I don't always have to hack up the
 runtime :).


 Yes. nothrow is part of the name mangling, because it's part of the signature.
 In the long run, toString will be  safe const pure nothrow, but it's not there
 quite yet (const correctness and Object is still being sorted out would be one
 reason; a number of key string-related functions need to become pure for
 another). But if the compiler is expecting a specific signature, then that's
 the signature that you're going to have to give it, or the linker's not going
 to find the function when it goes to look for it.

 - Jonathan M Davis


Is overriding a  safe function with  trusted allowed/meant to be 
allowed? I hope so, otherwise this is going to be a severe limitation.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jul 06 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 07, 2012 07:27:52 Alex R=C3=B8nne Petersen wrote:

 Is overriding a  safe function with  trusted allowed/meant to be
 allowed? I hope so, otherwise this is going to be a severe limitation=


.

Well, an overriding function in a derived class cannot be any looser th=
an the=20
one it's overriding in the base class, but  trusted is essentially the =
same as=20
 safe from the caller's perspective, so I would expect it to work (I wo=
uldn't=20
expect  system to work though, since that _is_ looser). In fact, I'm pr=
etty=20
sure that there was a post about it not too long ago where someone was =
having=20
issues because the function in a derived class was inferred as  safe, a=
nd they=20
had to mark it as  trusted to get it to work. So, I think that you're f=
ine on=20
that count. However, even if you _couldn't_ override an  safe function =
with an=20
 trusted one for some reason, all you would have to do is create a help=
er=20
function which was  trusted, and you could get around the limitation qu=
ite=20
easily.

- Jonathan M Davis
Jul 06 2012
prev sibling parent "BLM768" <blm768 gmail.com> writes:
On Saturday, 7 July 2012 at 04:27:07 UTC, Jonathan M Davis wrote:

 On Saturday, July 07, 2012 05:45:53 BLM768 wrote:

 On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:

 I swear you guys read my mind sometimes...  It's creepy.
 
 I just had this very issue, doing the exact same thing, about
 an hour ago.
 
 Have you tried with -nodefaultlib -noruntime ?  Cause that's
 what works for me...
 
 I just got *something* to compile with no runtime or std.
 Whether or not it actually does anything remains to be seen.


 
 No luck; it still references the runtime.
 I've been stubbing out the runtime; it seems to be about done
 except for references to some functions I can't find. The 
 symbols
 are __moddi3 and __divdi3; I assume they're C math library
 functions, as they're generated from code that uses div/mod
 operations. It also seems to be unable to properly find
 Object.toString() after I changed it to be nothrow, which I
 needed to do because I'm stubbing out the exception handling
 routines; it seems to have changed the mangling. It's a bit of 
 a
 mess in there; I'm glad I don't always have to hack up the
 runtime :).


 Yes. nothrow is part of the name mangling, because it's part of 
 the signature.
 In the long run, toString will be  safe const pure nothrow, but 
 it's not there
 quite yet (const correctness and Object is still being sorted 
 out would be one
 reason; a number of key string-related functions need to become 
 pure for
 another). But if the compiler is expecting a specific 
 signature, then that's
 the signature that you're going to have to give it, or the 
 linker's not going
 to find the function when it goes to look for it.

 - Jonathan M Davis


The problem is that if I leave the try/catch block, it's 
referring to stubbed-out functions, and if I get rid of it, LDC 
complains that toString() isn't nothrow. I guess I'd just better 
leave it in and hope that toString() never gets called. I could 
throw in an assert(false), which I'll have wired up to just cause 
a kernel panic.
Jul 06 2012
prev sibling parent 1100110 <10equals2 gmail.com> writes:
Wow, I haven't had that much trouble.  But I've tried to keep everything
at my level.  It's about half xomb. =P

I salute you for your bravery.

I had planned to stay far, far away from as much of that as I could.



On Fri, 06 Jul 2012 22:45:53 -0500, BLM768 <blm768 gmail.com> wrote:


 On Friday, 6 July 2012 at 21:54:15 UTC, 1100110 wrote:

 I swear you guys read my mind sometimes...  It's creepy.

 I just had this very issue, doing the exact same thing, about an hour  
 ago.

 Have you tried with -nodefaultlib -noruntime ?  Cause that's what works  
 for me...

 I just got *something* to compile with no runtime or std.
 Whether or not it actually does anything remains to be seen.


 No luck; it still references the runtime.
 I've been stubbing out the runtime; it seems to be about done except for  
 references to some functions I can't find. The symbols are __moddi3 and  
 __divdi3; I assume they're C math library functions, as they're  
 generated from code that uses div/mod operations. It also seems to be  
 unable to properly find Object.toString() after I changed it to be  
 nothrow, which I needed to do because I'm stubbing out the exception  
 handling routines; it seems to have changed the mangling. It's a bit of  
 a mess in there; I'm glad I don't always have to hack up the runtime :).



-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jul 06 2012