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.

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

>
> 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.

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

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

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.

>
> 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 :).

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 :).

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.

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