Compiling x86_64 bit drivers

Development
1

First, I have compiled a number of my CLI programs for 64 bit Haiku. I had few problems compiling using the terminal to call the compiler directly. As I was able to compile using “make” on a makefile.

Then I tried compiling some drivers I wrote. After having a lot of problems trying to compile use the CLI or the “make” and a makefile I came to realize there is a problem with how Haiku is setup to compile program without “jam”.

At one point I even thought I had finally gotten the system to create proper drivers, but a quick look at the “syslog” file showed that when the system tried to load in my driver it got reject for “Bad Data”, whatever that means.

Now I know a number of people have no problem using “jam” and if I watch what it does to create a valid driver I could use the same information to compile using the CLI or to edit the make-engine so "make: and makefiles will work okay.

So I have downloaded the latest Haiku source files and the buildtools, and I will first try and build the drivers that come with Haiku and hopefully this will give me the clues I need.

I plan to post my progress here.

1 Like
2

Why open a new topic? Compiling device drivers was where one could follow the discussion.

3

Because a number of replies seemed to assume I was using the 32 bit version of Haiku. The 32 Bit version seems to compile drivers okay, it is the 64 bit version I need help with.

Neither the methods I used to compile drivers using CLI, MakeFiles or Paladin seem to work. Jam seems to need a lot of setup that is so far not going well for me. When you have problem compiling drivers zero.c null.c or fifo.c you know there is wrong in how Haiku handles compiling.

Personally, I do not like JAM, I do not like a system that seems to scatters additional files in different directories to compile a simple program. I am not trying to compile an entire OS for different CPUs, I am trying a compile for just my system only.

I always post my source code with my programs if people are interested but I find the present system needlessly complicated.

I would like a dimple way to compile 64 bit drivers!

1 Like
4

You mean that taking null.c and create a makefile-engine based Makefile to build a “null” kernel driver don’t produce a correct kernel driver anymore?

If it’s the case, it deserve to file a bug report as that mean our makefile-engine is broken on this area.

5

Hope it helps your quest…

6

Smell like our DRIVER support case in makefile-engine is broken for 64bits, then.

7

It is, but I would like to do some experiments and tests first so I can write a clear report of what I found wrong, what work-a-rounds if any, and all the steps I have taken so people know where to look.

Hope to report soon.

1 Like
8

I am sorry I have been taking so long.

The test driver I am trying to get to compile as a driver in 64 Bit Haiku started as the zero.c code that can be found in the Haiku source code at https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/common/zero.c

However, I did make changes. First, I used a text editor to change the string “zero” to “xxxx” and change the value of 0 on line 50 to 85. I then saved the file as xxxx.c

Afterwards, I tried compiling the driver on different versions of Haiku to see what would happen.

1 Like
9

First, I tried compiling using the Haiku Release 1 Alpha 4 which uses a GCC2 compiler. I used MAKE to compile the file as I found Paladin has problems with compilers. Which reported it did the following steps.

Haiku hrev1 alpha4-44702 GCC2

~/Desktop/Projects/driver_xxxx> make

[ -d objects.x86-gcc2-release ] || mkdir objects.x86-gcc2-release > /dev/null 2>&1; \

mkdepend -I./ -p .c:objects.x86-gcc2-release/%n.o -m -f “objects.x86-gcc2-release/xxxx.d” xxxx.c

gcc -c xxxx.c -I./ -I- -D_KERNEL_MODE=1 -no-fpic -O0 -Wall -Wno-multichar -Wno-ctor-dtor-privacy -o “objects.x86-gcc2-release/xxxx.o”

gcc -o “objects.x86-gcc2-release/xxxx” objects.x86-gcc2-release/xxxx.o -nostdlib /boot/develop/lib/x86/KERNEL /boot/develop/lib/x86/haiku_version_glue.o -L./

xres -o objects.x86-gcc2-release/xxxx

mimeset -f “objects.x86-gcc2-release/xxxx”

~/Desktop/Projects/driver_xxxx>

The resulting driver when placed in the right “bin” folder and have a link to the “dev” folder works okay.

I tested it using dd if=/dev/xxxx of=test bs=65536

Then used diskprobe on the file 'test" to see worked okay.

1 Like
10

I then tried the same on a more recent NIGHTLY to see if it would compile with the GCC2 version of a more up to date version of Haiku. Which reported it did the following steps.

Walter hrev51740 x86_gcc2

I did notice some differences:

~/Desktop/Projects/driver_xxxx> make

The makedirectory has the same function but does not has the same beginning.
mkdir -p objects.x86-cc2-release; \

The makedepend seems to be the same.
mkdepend -I./ -p .c:objects.x86-cc2-release/%n.o -m -f “objects.x86-cc2-release/xxxx.d” xxxx.c

Notice the use of cc instead of gcc also the flag -no-fpic is different
cc -c xxxx.c -I./ -I- -D_KERNEL_MODE=1 -fno-pic -O0 -Wall -Wno-multichar -Wno-ctor-dtor-privacy -o “objects.x86-cc2-release/xxxx.o”

Again using cc instead of gcc and the path is also changed.
cc -o “objects.x86-cc2-release/xxxx” objects.x86-cc2-release/xxxx.o -nostdlib /boot/system/develop/lib/KERNEL /boot/system/develop/lib/haiku_version_glue.o -L./

This stays the same.
xres -o objects.x86-cc2-release/xxxx

And also this.
mimeset -f “objects.x86-cc2-release/xxxx”

~/Desktop/Projects/driver_xxxx>

The resulting driver when placed in the right “bin” folder and have a link to the “dev” folder works okay here too, so it seem there was no problem with the 32 Bit version of Haiku.

Once again I tested it using dd if=/dev/xxxx of=test bs=65536

Then used diskprobe on the file 'test" to see it worked okay.

11

So now I tried to compile the same driver, on a 64 Bit version of Haiku. Again I used “MAKE” but the results were very different.

Walter hrev51740 x86_64

~/Desktop/Projects/driver_xxxx> make

mkdir -p objects.x86_64-cc5-release; \

mkdepend -I./ -p .c:objects.x86_64-cc5-release/%n.o -m -f “objects.x86_64-cc5-release/xxxx.d” xxxx.c

cc -c xxxx.c -iquote./ -iquote./ -D_KERNEL_MODE=1 -fno-pic -O0 -Wall -Wno-multichar -Wno-ctor-dtor-privacy -o “objects.x86_64-cc5-release/xxxx.o”

cc1: warning: command line option ‘-Wno-ctor-dtor-privacy’ is valid for C++/ObjC++ but not for C

cc -o “objects.x86_64-cc5-release/xxxx” objects.x86_64-cc5-release/xxxx.o -nostdlib /boot/system/develop/lib/KERNEL /boot/system/develop/lib/haiku_version_glue.o -L./

/boot/system/develop/tools/bin/…/lib/gcc/x86_64-unknown-haiku/5.4.0/…/…/…/…/x86_64-unknown-haiku/bin/ld: objects.x86_64-cc5-release/xxxx.o: relocation R_X86_64_32 against `.rodata’ can not be used when making a shared object; recompile with -fPIC

/boot/system/develop/tools/bin/…/lib/gcc/x86_64-unknown-haiku/5.4.0/…/…/…/…/x86_64-unknown-haiku/bin/ld: final link failed: Nonrepresentable section on output

collect2: error: ld returned 1 exit status

/boot/system/develop/etc/makefile-engine:246: recipe for target ‘objects.x86_64-cc5-release/xxxx’ failed

make: *** [objects.x86_64-cc5-release/xxxx] Error 1

~/Desktop/Projects/driver_xxxx>

As you can see the make engine does not compile the driver.

I also tried trying different command lines to force a compile, but the resulting driver when it did compile reported “bad data” in the ‘syslog’ and did not add a driver to the /dev/ directory.

Tomorrow, I will try the very latest 64 Bit Nightly and see what happens.

12

Also I have downloaded the haiku.zip and buildtools.zip and try to use JAM, that did not work out. I want to try it again and more carefully document the errors to see if someone can point out what I am doing wrong.

I am hoping to use the JAM build to see how drivers are compiled and then make changes to the make-file-engine so it can compile 64 Bit drivers properly.

1 Like
13

Let me know if you get Haiku to build itself in 64 bit mode. I recently got only part way through with a build error. And that’s using the source files from git within Haiku 64. Though maybe your device driver doesn’t need the full build.

14

This as far as I have gotten so far. This does compile the driver, but the driver does not load. Instead in the Syslog I see the driver loaded, then unloaded with the error “Bad data”. So this is as far as I have gotten so far, next comes the tests with JAM.

rm -v -r objects

mkdir -v objects

mkdepend -I./ -p .c:objects/%n.o -m -f “objects/xxxx.d” xxxx.c

gcc -c xxxx.c -iquote./ -iquote./ -D_KERNEL_MODE=1 -fPIC -O0 -o “objects/xxxx.o”

gcc -o “objects/xxxx” objects/xxxx.o -nostdlib /boot/system/develop/lib/KERNEL /boot/system/develop/lib/haiku_version_glue.o -L./

/boot/system/bin/ld objects/xxxx.o
xxxx

xres -o objects/xxxx

mimeset -f “objects/xxxx”

copyattr --data objects/xxxx /boot/home/config/non-packaged/add-ons/kernel/drivers/bin/xxxx

mkdir -p /boot/home/config/non-packaged/add-ons/kernel/drivers/dev

ln -sf /boot/home/config/non-packaged/add-ons/kernel/drivers/bin/xxxx /boot/home/config/non-packaged/add-ons/kernel/drivers/dev/xxxx

15

Okay, found out that you currently can’t build Haiku 64bit inside Haiku 64 bit. https://dev.haiku-os.org/ticket/10815 Has trouble compiling the 32 bit bootloader code. So I’d have to build the full system on Linux.

Though for building just the device driver, it works under Haiku x86_64. After hacking up zero.c to return 1’s and have an internal name string of “one”, compile it inside the haiku source directory with this:

mkdir generated
cd generated
…/configure
cd …/src/add-ons/kernel/drivers/common
jam -q -da zero

Then copy the executable out of generated/objects/haiku/x86_64/release/add-ons/kernel/drivers/common/zero into the ~/config/non-packaged/add-ons…/bin/one (note the new name of “one”) and make a symbolic link to it in …/non-packaged/…/dev/one and reboot. Should show up as /dev/one and if you read it, it returns ones (hd /dev/one to see it in action, vs hd /dev/zero).

There’s probably some way of getting it to compile as one.c, but I couldn’t figure it out.

1 Like
16

Thank you. I have been able to compile my test driver using your instructions.

I was able to also to change the driver name okay by editing the jam file in the common directory.

I am looking at the Jam files to figure out how x86_64 drivers are made. I think I have found the right section but now I have to find out the contents of all variables to figure out the what the script is doing.

Again, thanks for the help. And I will try to figure out what is needed to get the make-file-engine working properly if I can.

17

Try “jam -q -dax zero” to see what the compiler command lines are.

18

Wow! Thanks for the help. I will try this out tonight and see where it takes me,

At-least I can now compile drivers so now I can start back the work on compression and voice processing.

Again, Thank.

3 Likes
19

Okay, I used the -dax option.

OH MY GOD!

The number of flags and options and directories it checks. I think I can prune it down but it will be a lot of work, anyway thank again for the help. Hopefully I can make it work to the point of editing the make-engine file.

20

I started work again on compiling drivers for 64 bit Haiku.

At the moment I have not gotten GCC7 to work properly, however I also had some problems run configure on even older Haiku source code. Then the configure ran properly after getting access to the internet.

Does the Haiku and GCC7 need the internet to compile properly?