OSDev.org

x64dev wrote:

MollenOS wrote:If you ever figure out how to use Clang to output PE files for bare targets, _please_ let me know. I don't know how much time I've spent trying to figure that out.

Sure

I may end up implementing a backend to produce the PE if I need to. In theory any linker that produces PE images could do the final stage linking of the clang compiled object code and produce a PE native subsystem image.

Yea i tried doing some quick hacks to get the LLVM linker to work with it, but I realized that I would have to put in more time actually implementing the support for PE targets than I was willing too, so I've been continuing it with the ms toolchain for now untill I felt like I had to time to do it. But thanks, if you get there I would love to know, otherwise I'll get around to it some day

alexfru wrote:

x64dev wrote:I may end up implementing a backend to produce the PE if I need to. In theory any linker that produces PE images could do the final stage linking of the clang compiled object code and produce a PE native subsystem image.

In theory, it's in there:

LLD is a linker from the LLVM project. That is a drop-in replacement for system linkers and runs much faster than them. It also provides features that are useful for toolchain developers.

The linker supports ELF (Unix), PE/COFF (Windows) and Mach-O (macOS) in descending order of completeness. Internally, LLD consists of three different linkers. The ELF port is the one that will be described in this document. The PE/COFF port is almost complete except the lack of the Windows debug info (PDB) support.

Hmm, since Microsoft has now made the PDB stuff public (https://github.com/Microsoft/microsoft-pdb) it may be easier to modify LLD and add that. I've been playing with LLVM so that would be the easiest route I would think.

MollenOS wrote:If you ever figure out how to use Clang to output PE files for bare targets, _please_ let me know. I don't know how much time I've spent trying to figure that out.

Use lld with COFF output format.

dozniak wrote:

MollenOS wrote:If you ever figure out how to use Clang to output PE files for bare targets, _please_ let me know. I don't know how much time I've spent trying to figure that out.

Use lld with COFF output format.

I tried that, it won't produce that for non-windows targets

MollenOS wrote:

dozniak wrote:

MollenOS wrote:If you ever figure out how to use Clang to output PE files for bare targets, _please_ let me know. I don't know how much time I've spent trying to figure that out.

Use lld with COFF output format.

I tried that, it won't produce that for non-windows targets

I pulled down the llvm, clang and lld source from the SVN repository (for version 5.0) and after using CMake to generate the Visual Studio 2015 (Update 3) solution, I was able to build everything.

I then tried to see what options where valid for linking on Windows and found that the following is valid:

lld-link /nodefaultlib /subsystem:native /machine:AMD64

This makes me think that I'll be able to move over to an LLVM based build process and still build my 64-bit OS without an issue. I'm actually using JWasm (which has MASM support) for the assembler so I don't have to be concerned about having to migrate for Masm etc.

I'll try moving to a clang/lld/Jwasm solution for my OS when I have a bit more free time on my hands.

MollenOS wrote:

dozniak wrote:

MollenOS wrote:If you ever figure out how to use Clang to output PE files for bare targets, _please_ let me know. I don't know how much time I've spent trying to figure that out.

Use lld with COFF output format.

x64dev wrote:
I pulled down the llvm, clang and lld source from the SVN repository (for version 5.0) and after using CMake to generate the Visual Studio 2015 (Update 3) solution, I was able to build everything.

I then tried to see what options where valid for linking on Windows and found that the following is valid:

lld-link /nodefaultlib /subsystem:native /machine:AMD64

This makes me think that I'll be able to move over to an LLVM based build process and still build my 64-bit OS without an issue. I'm actually using JWasm (which has MASM support) for the assembler so I don't have to be concerned about having to migrate for Masm etc.

I'll try moving to a clang/lld/Jwasm solution for my OS when I have a bit more free time on my hands.

After searching different forums and playing around for a while, I managed to use clang & lld-link to build a no default lib, native 64-bit PE executable. I still need to get debug symbols working.

The following is a "kernel" entry routine (obviously simplified) - i.e. the first routine that will execute after control is transferred from the boot loader (be that GRUB or something else - in my case my own but that's because I plan to build a new file system too).

test.c:

void KernelStartup()
{
while (1) {

}
}

Compile 64 bit with clang:

clang -m64 -c test.c

Link with lld-link:

lld-link /nodefaultlib /subsystem:native /entry:KernelStartup test.o

Verify that the resulting executable is a 64-bit PE executable without any libraries:

D:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin>link /dump /all d:\testclang\test.exe
Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
Copyright (C) Microsoft Corporation. All rights reserved.


Dump of file d:\testclang\test.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
8664 machine (x64)
1 number of sections
0 time date stamp
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
Application can handle large (>2GB) addresses

OPTIONAL HEADER VALUES
20B magic # (PE32+)
0.00 linker version
200 size of code
0 size of initialized data
0 size of uninitialized data
1000 entry point (0000000140001000)
1000 base of code
140000000 image base (0000000140000000 to 00000001400013FF)
1000 section alignment
200 file alignment
6.00 operating system version
0.00 image version
6.00 subsystem version
0 Win32 version
1400 size of image
400 size of headers
0 checksum
1 subsystem (Native)
8160 DLL characteristics
High Entropy Virtual Addresses
Dynamic base
NX compatible
Terminal Server Aware
100000 size of stack reserve
1000 size of stack commit
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
0 [ 0] RVA [size] of Export Directory
0 [ 0] RVA [size] of Import Directory
0 [ 0] RVA [size] of Resource Directory
0 [ 0] RVA [size] of Exception Directory
0 [ 0] RVA [size] of Certificates Directory
0 [ 0] RVA [size] of Base Relocation Directory
0 [ 0] RVA [size] of Debug Directory
0 [ 0] RVA [size] of Architecture Directory
0 [ 0] RVA [size] of Global Pointer Directory
0 [ 0] RVA [size] of Thread Storage Directory
0 [ 0] RVA [size] of Load Configuration Directory
0 [ 0] RVA [size] of Bound Import Directory
0 [ 0] RVA [size] of Import Address Table Directory
0 [ 0] RVA [size] of Delay Import Directory
0 [ 0] RVA [size] of COM Descriptor Directory
0 [ 0] RVA [size] of Reserved Directory


SECTION HEADER #1
.text name
A virtual size
1000 virtual address (0000000140001000 to 0000000140001009)
200 size of raw data
400 file pointer to raw data (00000400 to 000005FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
Execute Read

RAW DATA #1
0000000140001000: E9 00 00 00 00 E9 FB FF FF FF é....éûÿÿÿ

Summary

1000 .text

I will still need to build my kernel with this and see if it still boots, but this does look promising.