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