OSDev.org

Finally got it to work. Writing some wiki now ( as I promised )

Here you go:
http://wiki.osdev.org/GDC_Cross-Compiler
(Not completed)

Change D_OS_VERSYM to whatever you want, since it is a string, like "MyOS" or NULL.

Wrong. If you set it to NULL, you will cause the compiler to segfault.

I noticed you copied and pasted much of the GCC Cross Compiler guide. Are you sure that is necessary? It really comes down to configuring GDC, changing D_OS_VERSYM, and then doing exactly what is in the GCC Cross Compiler guide. Fairly simple.

Wilkie wrote:Wrong. If you set it to NULL, you will cause the compiler to segfault.

Oops, I didn't know that

OK, check the page again. Complains are wellcome.

quanganht wrote:Wrong. If you set it to NULL, you will cause the compiler to segfault.

fixed .

shiner wrote:fixed .

Thanks! If I weren't lazy \ busy, I would have done that myself. Verification of that issue is here: PittGeeks.org. This was already referred in the topic, and this was our group, so I can personally confirm.

On a new note, the XOmB crew are working alongside the LDC crew. We have been their advisers on what is necessary for kernel work in D, within the D language spec. They have heeded us! They were missing the 'naked' attribute for inline assembly (which is QUITE necessary for kernel dev! especially when you want to define mixins for assembly routines for efficiency of computer time and coding time!)

Long story short, they are already working on implementing 'naked' for us and say it is in the testing stage. Soon, we can dump gdc for ldc. <strong opinion>YAY</strong opinion> Since we are working alongside them, they have been providing the builds, but I will take up the task of learning the process to build an LDC cross-compiler, and will personally write the wiki article.

For anyone interested, the differences between GDC and LDC are simply put: LDC is closer to the true D spec. Where it deviates is typically on the case of a compiler bug and inline assembly. Instead of the GAS syntax used in gcc, ldc uses the Intel syntax. It is also maintained...by several people! It is also BSD licensed, if that is a concern.

I think you might be able to use the "-masm=intel" flag to at least keep some portability in gdc, but it will still be a little different (mixins could allow some transparency). Don't quote me on it, though. But, hey, if it is possible and you don't want to have to spend a weekend switching operands (like ME), it might be better to just use the Intel syntax to begin with. I was going to do it last weekend, but I live in Pittsburgh

Wilkie wrote:Soon, we can dump gdc for ldc. <strong opinion>YAY</strong opinion> Since we are working alongside them, they have been providing the builds, but I will take up the task of learning the process to build an LDC cross-compiler, and will personally write the wiki article.

That would be great! Can LDC object files be linked with LCC object files? Because while I'm hoping for my kernel to be pure D in the near future, I'm still linking with some of my old C++ code (a lot of the core kernel code is inter-dependent).

Other than that, and besides LDC being Linux only (it surely wouldn't be too hard to compile on (not target) Windows), there is nothing holding me to GCC.

Yes, you should be able to link anything together in the same fashion as gcc and gdc.

Also, it would be possible to get it to work in Windows with much effort, but don't .

I am still waiting on getting the instructions for the cross compiler. I'm not sure if they understand that we need a naked compiler yet. That is, I haven't gotten to the linking stage yet, still switching operands.

Eh? how to fix "code model 'kernel' not supported in 32 bit mode" ???

EDIT: I got it. Rebuild GCC/GDC with target as x86_64-pc-elf

I've been working on an OS in the D programming language for quite some time now. I'm currently in the process of migrating servers, but the SVN repository is accessible here: http://svn.devlime.com/neptune

I have some detailed instructions for building a full set of cross compilers for GDC (targeting i586-pc-elf and x86_64-pc-elf) which have worked on amd64 ubuntu and cygwin in the past.

It looks like most of you have had issues with the missing object.d file, as well as various missing runtime functions. I ended up porting and rewriting a large portion of the D runtime (no garbage collection though). For this, I relied very heavily on the documentation and advice of Kris and Sean over at the Tango project (http://www.dsource.org/projects/tango).

If anyone has any questions I'd be happy to answer them - I haven't made my way through this whole thread yet.

Wilkie wrote:For userland, you will have to port a C runtime (newlib) and\or a D runtime (phobos, tango). Look at reference implementations, much of which you can copy verbatim. They make calls to a malloc and are easily understood. From there, you can interface with your page allocator.

I'm not actually that interested in porting a complete standard library like Phobos or Tango. I just want to implement enough of the runtime so every feature of the language (exceptions, RTTI, new/delete, concatenating strings, dynamic arrays, etc) will work.

As far as the the C Standard Library, is it required just for the runtime features of the language (not the standard libraries - Phobos/Tango)? (I'd much rather use my own functions for reading, writing, printing, etc until my OS is more mature).

MessiahAndrw wrote:I'm not actually that interested in porting a complete standard library like Phobos or Tango. I just want to implement enough of the runtime so every feature of the language (exceptions, RTTI, new/delete, concatenating strings, dynamic arrays, etc) will work.

For the language runtime, just implement all of the stubs. I really meant for you to refer to phobos and tango as to what each stub does rewriting the parts to refer to your kernel. But that is all you need to do.

MessiahAndrw wrote:As far as the the C Standard Library, is it required just for the runtime features of the language (not the standard libraries - Phobos/Tango)? (I'd much rather use my own functions for reading, writing, printing, etc until my OS is more mature).

Nope. That would require porting the C standard library, and thus the C runtime to use your kernel, just to write the D runtime. Don't do that. What I was referring to was that to implement malloc in userland you would port either a C runtime or D runtime implementation.

How is LDC coming along?

I'm keen on hearing about it. According to their website they're really close to getting something stable (unless they're just over-optimists and talk that way in general).

LDC is coming well. The bare bones compiles with it, and the OS is very close, too.

I'm currently using the GDC with the barebone.
It compiles fine and I'm just trying to get it up in the higher half. I already loaded the trick GDT after coming from grub und jumped to the main method where I can print some text.

The big problem I have is as soon as I call a function in another module that is compiled seperately and should be linked afterwards, I'm getting a "Bus error" from LD.