Student: Ping Huang
Mentors: Arun Thomas, Ben Gras
git repository: pkgsrc
The primary goals of this project are porting GCC 4.7.0, binutils 2.22, and GDB 7.4.1 to MINIX 3, and sending the changes upstream.
|☑||Porting Binutils 2.22||100%||testsuite result: 3 fails in gas, 21 fails in binutils|
|☑||Porting dejagnu.4.4/expect-5.43||100%||Only root can run it successfully|
|☑||Porting GCC 4.7.0||100%||Only support C and C++ currently|
|☑||Porting GDB 7.4.1||100%||not stable|
Since I have built binutils-2.22 on minix3 successfully when I appled for the GSoC project, This week I tried to test it with DejaGnu framework. DejaGnu framework is dependent on expect. So this week the main work is porting expect and then DejaGnu to minix3. Work in detail are shown below.
This week I have been taking effort to make dejagnu/expect work well on minix3. According to the “no more ptys” message, firstly, I tried to increase the number of ptys by setting NR_PTYS to 64 in include/minix/config.h. Due to my ignorance to docs/UPDATE, I encountered some problems when rebuilding system. Finally, following docs/UPDATE, I have succeeded to rebuild it. However, with no change to MAKEDEV (later I learned from Ben), there are still 32 ptys in /dev.
But the situation is not so bad, the funny thing I found is that: I can make check successfully as root, then if I switch to other users, it will fail. More oddly, if I first make check as other users, then root will also fail with “no more ptys” message. So does it in the system which NR_PTYS is 32. So I think the “no more ptys” error is not caused with the number of ptys, instead, it has something to do with the authority. I suspect this phenomenon is relataed to the system call “setpgrp” I have commmented away in the source code of expect (since minix3 doesn't support it).
Anyway, DejaGnu works well on minix3 now, although only as root. I have tested binuitls-2.17 existing in pkgsrc and binuitls-2.22 I ported. The result is shown in the table below.
I glance over the UNEXPECTED FAILs in gas(3 fails) and binutils(21 fails), and don't find something that is dangerous. So Maybe binuitls-2.22 is ready for use on minix3.
This week, first, I ruled out the possibility that the commentted “setpgrp” causes “no more ptys” error, because the “setpgrp” is never called when I preprocessed it. The cause mustbe has something to do with the authority of minix. After that I begin to move on porting gcc-4.7.0 to minix3.
Since gcc-4.7-20110716 is available in pkgsrc, I built it on minix3 successfully after add a configure argument “–enable-initfini-array” in Makefile, otherwise, the system would crash when checking whether “–enable-initfini-array” was given. Then I make check it, dejagnu ran smoothly, and the result seems not bad. I just make check with the execute directory in testsuite, the result shows below.
|PASS||19956||Error: Couldn't determine version of g++||4005|
|UNEXPECTED FAIL||45||Error: Couldn't determine version of g++||9|
|UNRESOLVED||11||Error: Couldn't determine version of g++||0|
Next week, I will focus on porting the release version of gcc-4.7.0.
This week, I'm taking an effort to port gcc-4.7.0. Firstly, I enabled the language of c, c++ and fortran, when building gcc-4.7.0/libgfortran/intrinsics/chmod.c, it failed with the error message “S_IFMT undeclared”. The reason is the options when compiling that file is not include -D_NETBSD_SOURSE. After that, the building process went on well. However, when I tried to bmake install, it failed again, complaining that some files about gfortran are not exsiting.
Then I decided to disable fortran, and only enable c and c++ to build a version. This time the building process went smoothly. However, the install process failed again. Then I tried to directly type “make install” in work/obj directory, instead of “bmake install” in pkgsrc/gcc47-release directory, and it succeeded.
Next, I make check in obj/gcc, and the whole testsuite ran smoothly at the beginning, however, when it had run about 40000 testsuite, the make check process seemed suspending. until now, I don't know the reason. Then I ran some simple program, such as helloworld, and they all passed.
Now, I tried to build the system with gcc-4.7.0. First, I make some userland utils, such as ls, cat, cp, the tests passed too. and the whole commands are built successfully, however, then make install, it failed when installing MAKEDEV with error message :assertion “inited” failed: file “/usr/src/lib/libc/stdlib/_env.c”, line 179, function “allocenvvar”, which I'm trying to fix.
Continuing to the work in last week, I tried to build the system with gcc-4.7.0. I firstly tried to build minix 3.2.0, with three main errors. I posted a thread on googlegroup.
After the meeting with Arun and Ben, I switched my system to 3.2.1. Until now, I have built gcc-4.7.0 on minix 3.2.1 successfully. And I'm trying to rebuild the system. I have encountered two problems:
I will fix the problems next week.
Thanks to Ben's effort, the two problems at last week have been solved. Now, the system can be built with gcc-4.7.0. But there are still some strange problems.
This week I tried to fix the reboot problem. With many times' rebuilding, I found that the culprints are lib/csu and lib/libminc(both, not combination). If building the system in this way: with binuitls 2.17, compiling the two libraries with clang, and all the others with gcc47, then the system works well, without the reboot problem. Otherwise, reboot problem would occur.
I have tried to build the system with gcc 4.7 and binutils 2.22 in the way above, but use gcc44 instead of clang (it seems that ld 2.22 cannot link the object generated by clang), the system can be built but still have the reboot problem.
I have made clean packages of expect 5.43, binutils 2.22 and gcc 4.7, and have committed them to minix-master in pkgsrc.
These two weeks I tried to fix the issues Ben encountered:
I have committed the new gcc47 package to minix-master branch. With it and binutils 2.22, I can build world successful, the system works well except for the reboot problem.
This month I have finished these work:
Since This is a porting project, there is no a panoramic design. The project mainly consists of three parts which are listed below.
The following is my week-by-week timeline with milestones.
Port binutils 2.22 to MINIX.
This work mainly need to add Minix target description, the BFD backend for i386 Minix and the new depandencies in building, such as adding the description of bfd_elf32_i386_minix_vec, and the new elf-ifunc.o relied on.
Test binutils and write document of the binutils porting.
It may include porting dejagnu.
Milestone 1: Binutils are completed.
Port gcc 4.7.0 to MINIX.
This work includes adding Minix configure files and descriptions of Minix with ELF format, etc.
Key files involved are shown as following:
Test gcc and and write document of the gcc porting.
This test will also test binutils and may be involved with some large applicaiton. So it needs two weeks.
Milestone 2: GCC is completed.
Port gdb 7.4 to MINIX.
This work mainly including adding the description of backend for Minix and the file involved with ptrace.
Key files involved are shown as following:
Test gdb and writing document of the gdb porting.
Since gdb relys on the system call “ptrace” in Linux. To my knowledge, “ptrace” in MINIX is some different from it in Linux. So maybe I need a little more time to port and test gdb.
Milestone 3: GDB is completed.
Scrub all of the code. Improve the documentation. And send the MINIX toolchain changes upstream.
Milestone 4: Send the changes upstream.
Further refine the documentation of the whole toolchain.