Changes between Initial Version and Version 1 of GCCPort

Timestamp:

2012-06-18T10:36:23Z (12 years ago)

Author:

vivekprakash

Comment:

—

GCCPort

@@ +1 @@
+== '''Port gcc to HelenOS''' ==
+
+Student: Vivek Prakash[[BR]]
+Mentor: Jiri Svoboda[[BR]]
+bzr repository: lp:~vivek-cs-iitr/helenos/gcc[[BR]]
+
+
+=== '''Current Task''' ===
+
+||Task||Percentage complete||Status||Comment||
+||Port libgmp||50%||In progress||||
+||Port libmpfr||30%||TODO||Analyzed dependencies||
+||Port libmpc||30%||TODO||Analyzed dependencies||
+
+=== '''Status Reports''' ===
+
+==== '''Week 1 & 2''' ====
+I started working on my project (porting gcc) on 19th May after
+getting free from the university engagements. I worked till 25th, but
+then I had to relocate to home due to urgent personal reasons. When I
+was coming back to college, the train I was travelling in
+unfortunately met a very fatal accident in which I nearly lost my
+life. I had few minor injuries. I have relocated back to college and
+have got settled here. I will resume my work from tomorrow morning.
+
+I have been experimenting with the binutils build
+and learning how it was done. I have also analyzed the gcc-core
+dependencies in more detail.
+
+I have inspected the binutils build process closely. I went through
+some of the commits in the Petr repository too. I believe I have a
+good idea of how to go forward for now. I will start writing Makefile
+and scripts similar to that done for binutils as next step. Then
+during the build, whatever fails to compile will have to be sorted out
+one by one.
+
+==== '''Week 3''' ====
+
+This week I started coding after several setbacks. I made a build
+process structure for gcc similar to that done for binutils.
+Currently, I am working with gcc-core-4-6.3, but there would not be a
+big problem when bumping to gcc-4.7.0. I chose the core package so as
+to not confuse me with the new packaging structure of gcc-4.7.0 where
+all the components are present at one place, and also because my
+primary goal now is to port the C compiler part.
+
+I started my porting attempt with cross-compilation of gcc. I will be
+using the target `all-gcc' in the gcc-core Makefile.in to initiate the
+target build from my Makefile. But before that, the challenge is to
+get past the configure stage with host and target set to that of the
+HelenOS. This stage requires the presence of libgmp, libmpfr and
+libmpc. So the configure stage currently fails and asks for the
+location of gmp (--with-gmp) , mpfr (--with-mpfr) and mpc (--with-mpc)
+to proceed. Now, I have started porting the libgmp and libmpfr.
+
+There are few questions related to design decisions about which I
+would like to get suggestions:
+1. gcc will obviously go in uspace/app/, am i right?
+2. The external libraries libgmp, libmpfr and libmpc should be placed
+in uspace/app/gcc/dependencies/lib/ or other directory e.g. uspace/lib
+?
+
+I have also started looking at libposix at what functions or stubs
+needs to be implemented or improved there. That will become evident in
+the porting process. So, my next step is to port the external
+libraries on which gcc build is dependent and then proceed forward.
+Also the current patching of gcc source is very minimal, with
+cross_compilation flags set to `yes'. I am studying the source too to
+examine what all sorts of patching that are required.
+
+''Jiri suggested that we might make some common subdirectory(-ies) for ported software (akin to BSD ports) due to the ultimately different method of building it (and one day there could be some common framework for that). For now uspace/app/gcc seems adequate. Also, if we had some kind of ports dir, eg. with uspace/ports/gcc, then I would put them in uspace/ports/libxyz, with uspace/app/gcc I'd prefer the former variant, i.e. place them under gcc - this should work nicely for now, since gcc will be the only consumer for now. After this discussion, i placed gcc in uspace/app/ and the libraries in uspace/app/gcc/ itself. For example, libgmp is placed at uspace/app/gcc/dep/libgmp and similarly it was done for other dependencies."
+
+==== '''Week 4''' ====
+
+This week I started porting libgmp, libmpfr, and libmpc. Initially I got stuck on the cross compilation issue and then referred to the libgmp manual to solve it. All these libraries expect --host and --build arguments in configure stage for cross compilation. I also used --disable-shared and --disable-static flags in configure stage.
+
+There were problems with locating the cross-compiler toolchain and and flags were not being passed properly during the compilation test to the gcc. I had to define the CFLAGS in the Makefile itself and pass them to the configure script. But, this was quick and dirty way to proceed, i will look for some other ways.
+This is the flag that i had to pass:
+DEP_CFLAGS = -I../../../../lib/posix -I../../../../lib/c/include -imacros ../../../../../config.h -fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE -finput-charset=UTF-8 -ffreestanding -fno-builtin -nostdlib -nostdinc -std=gnu99 -D__LE__ -march=pentium -fno-omit-frame-pointer
+
+Now, I tried cross-compiling libgmp, libmpfr and libmpc one by one.
+
+Log for libgmp build shows that it could not find wchar.h and there ws undefined reference to memcpy. Similarly, libmpfr could not find  memory.h, wchar.h, sys/fpu.h, fenv.h and gmp.h. There were undefined references to fopen, ferror, fclose, memmove, memset, setlocale, strtol, gettimeofday, round, trunc, floor, ceil and nearbyint. There were undefined references to fopen, ferror and fclose in case of libmpc. I will implement some of the missing functions in libposix. Undefined references to memcpy, memmove, memset, fopen, fclose, ferror, strtol and gettimeoday can be easily fixed by linking correctly to libposix as these functions are already implemented in libc and their prototypes are only required in lib/posix/. 
+
+Moreover, libmpfr first needs libgmp to be built and llibmpc needs both libgmp and libmpfr to be already built. So, my first goal to port libgmp as soon as possible. Analyzing all the external libraries gave a more detailed understanding of the work required to be done to port all of them.