OSDev.org

Posted: **Sun Apr 08, 2018 10:07 am**

Hello everyone,
I just successfully ported GCC 7.3.0 and binutils 2.30 to my OS and they seem to work fine. Only, I have some problems with them, probably configuration:

Problem #1: GCC does not find includes like stdio.h in usr/include: however, when I compile with the -v option, the usr/include folder is in the search list, but at the end

: Capture d’écran_2018-04-08_17-58-43.png (5.12 KiB) Viewed 2793 times

And the folder /usr/local/include is empty but i can't delete it otherwise gcc complains about not finding the folder (that is useless)

: Capture d’écran_2018-04-08_18-41-25.png (1.64 KiB) Viewed 2785 times

Problem #2: If I compile a program without include, at the time of the link, ld can't find crt0.o: ld looks for it in /lib/gcc/i686-haoudos/7.3.0/, where it finds crtend.o crtbegin.o libgcc.a ... but not crt0.o, which is in usr/lib/. But ld found libc.a libm.a ... in the same directory: it's gcc passing a bad absolute path.

Problem #3: When I compile with this command line "gcc /test.c" I get from ld this error : "option 'plugin not recognized": my solution is to add -fno-use-linker-plugin in the command line, but is there a way to include it directly in gcc this option?

Thank you in advance for your answer and if you need more information do not hesitate to ask

Posted: **Sun Apr 08, 2018 2:21 pm**

For the linker problem, maybe try the -print-file-name=crt0.o option and see where this gets you. You can inspect -print-sysroot, -dumpmachine, etc, or change the header and library path with the -sysroot option.

Posted: **Mon Apr 09, 2018 1:01 am**

simeonz,Thank you for your answer.
Indeed, gcc believes that crt0.o is located with crtbegin.o/crtend.o/crti.o and crtn.o while crt0.o is in /usr/lib. I don't know how to tell gcc where crt0.o is (and only crt0.o without crti.o, crtn.o...).

: Capture d’écran_2018-04-09_08-58-00.png (1.31 KiB) Viewed 2735 times

Posted: **Mon Apr 09, 2018 8:15 am**

First, lets consult the "internals" manual of gcc:

Here is the order of prefixes tried for startfiles:

Any prefixes specified by the user with -B.
The environment variable GCC_EXEC_PREFIX or its automatically determined value based on the installed toolchain location.
The directories specified by the environment variable LIBRARY_PATH (or port-specific name; native only, cross compilers do not use this).
The macro STANDARD_EXEC_PREFIX, but only if the toolchain is installed in the configured prefix or this is a native compiler.
The location /usr/lib/gcc/, but only if this is a native compiler.
The macro MD_EXEC_PREFIX, if defined, but only if this is a native compiler.
The macro MD_STARTFILE_PREFIX, if defined, but only if this is a native compiler, or we have a target system root.
The macro MD_STARTFILE_PREFIX_1, if defined, but only if this is a native compiler, or we have a target system root.
The macro STANDARD_STARTFILE_PREFIX, with any sysroot modifications. If this path is relative it will be prefixed by GCC_EXEC_PREFIX and the machine suffix or STANDARD_EXEC_PREFIX and the machine suffix.
The macro STANDARD_STARTFILE_PREFIX_1, but only if this is a native compiler, or we have a target system root. The default for this macro is /lib/.
The macro STANDARD_STARTFILE_PREFIX_2, but only if this is a native compiler, or we have a target system root. The default for this macro is /usr/lib/.

The "-B" approach works on my test machine. Note that "-B" takes precedence over the gcc install folder, where the crtbegin.o, etc, are located in your case. If your /usr/lib also contains crtbegin.o for some reason and you want to shadow it, you need to specify the gcc install path with the "-B" option as well, and make it first, before /usr/lib.

Anyway. My understanding is that you want to host gcc inside your platform and not just to cross-compile. At the bare minimum, you may want to check out the "--with-sysroot" option. Setting it to "/" might fix your specific problem now. But the more comprehensive solution is to port GCC. I am not familiar with the process, but thankfully there is an osdev guide for this type of thing and it addresses the steps necessary to create a port. Also, there is the relevant documentation here.

If you don't want to host the compiler execution, but to simply cross compile, you may use the ffreestanding flag to instruct the compiler that the standard library routines cannot be treated as built-ins (that is, may not entirely conform to the standard) and to either pass -nostartfiles, -nodefaultlibs, or -nostdlib to the compiler driver during the linking stage, or directly invoke ld. In any case, if you call ld directly, or invoke gcc with -nostartfiles, you can control the directory of crt0, crtbegin and crtend manually. None of this applies if you want to host the compiler on your OS and build software there (such as when you have POSIX compatibility.)

Posted: **Mon Apr 16, 2018 10:29 am**

Thank you for your answer and sorry for mine so late (I was on holidays)
I solved the includes problem (a problem with errno in the libc that contained a negative value instead of a positive value)
The problem with crt0.o has been partially solved (I moved crt0.o to where gcc was looking for it but still couldn't find the exact location)
The last problem is the -fno-use-linker-plugin option that I have to spend all the time on gcc for it to work properly. The problem is in the specs file but I have absolutely no idea how to modify it (I compile with the option -disable-plugin)

Code: Select all

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %{!fno-use-linker-plugin:%{!fno-lto:     -plugin %(linker_plugin_file)     -plugin-opt=%(lto_wrapper)     -plugin-opt=-fresolution=%u.res[     %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}}     }}%{flto|flto=*:%<fcompare-debug*}     %{flto} %{fno-lto} %{flto=*} %l %{static|shared|r:;pie:-pie} %{fuse-ld=*:-fuse-ld=%*}  %{gz|gz=zlib:--compress-debug-sections=zlib} %{gz=none:--compress-debug-sections=none} %{gz=zlib-gnu:--compress-debug-sections=zlib-gnu} %X %{o*} %{e*} %{N} %{n} %{r}    %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}}     %{static|no-pie:} %{L*} %(mfwrap) %(link_libgcc) %{fvtable-verify=none:} %{fvtable-verify=std:   %e-fvtable-verify=std is not supported in this configuration} %{fvtable-verify=preinit:   %e-fvtable-verify=preinit is not supported in this configuration} %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):}     %{%:sanitize(thread):}     %{%:sanitize(leak):}}} %o      %{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1):	%:include(libgomp.spec)%(link_gomp)}    %{fcilkplus:%:include(libcilkrts.spec)%(link_cilkrts)}    %{fgnu-tm:%:include(libitm.spec)%(link_itm)}    %(mflib)  %{fsplit-stack: --wrap=pthread_create}    %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):%{static-libasan:-Bstatic} -lasan %{static-libasan:-Bdynamic} %{static-libasan:%:include(libsanitizer.spec)%(link_libasan)}    %{static:%ecannot specify -static with -fsanitize=address}}    %{%:sanitize(thread):%{static-libtsan:-Bstatic} -ltsan %{static-libtsan:-Bdynamic} %{static-libtsan:%:include(libsanitizer.spec)%(link_libtsan)}    %{static:%ecannot specify -static with -fsanitize=thread}}    %{%:sanitize(undefined):%{static-libubsan:-Bstatic} -lubsan %{static-libubsan:-Bdynamic} %{static-libubsan:%:include(libsanitizer.spec)%(link_libubsan)}}    %{%:sanitize(leak):%{static-liblsan:-Bstatic} -llsan %{static-liblsan:-Bdynamic} %{static-liblsan:%:include(libsanitizer.spec)%(link_liblsan)}}}}     %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}    %{!nostdlib:%{!nostartfiles:%E}} %{T*}  
%(post_link) }}}}}}

Posted: **Tue Apr 17, 2018 4:01 am**

You should use "--disable-lto" to disable the link-time plugin. "--disable-plugins" (if this is the option you meant) disables the GCC compiler plugins. In case this doesn't work, the specs file I believe can be modified to something like:

Code: Select all

*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %{fuse-linker-plugin:%eLTO Disabled}%{flto|flto=*:%eLTO Disabled}     %{flto} %{fno-lto} %{flto=*} %l %{static|shared|r:;pie:-pie} %{fuse-ld=*:-fuse-ld=%*}  %{gz|gz=zlib:--compress-debug-sections=zlib} %{gz=none:--compress-debug-sections=none} %{gz=zlib-gnu:--compress-debug-sections=zlib-gnu} %X %{o*} %{e*} %{N} %{n} %{r}    %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}}     %{static|no-pie:} %{L*} %(mfwrap) %(link_libgcc) %{fvtable-verify=none:} %{fvtable-verify=std:   %e-fvtable-verify=std is not supported in this configuration} %{fvtable-verify=preinit:   %e-fvtable-verify=preinit is not supported in this configuration} %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):}     %{%:sanitize(thread):}     %{%:sanitize(leak):}}} %o      %{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1):   %:include(libgomp.spec)%(link_gomp)}    %{fcilkplus:%:include(libcilkrts.spec)%(link_cilkrts)}    %{fgnu-tm:%:include(libitm.spec)%(link_itm)}    %(mflib)  %{fsplit-stack: --wrap=pthread_create}    %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):%{static-libasan:-Bstatic} -lasan %{static-libasan:-Bdynamic} %{static-libasan:%:include(libsanitizer.spec)%(link_libasan)}    %{static:%ecannot specify -static with -fsanitize=address}}    %{%:sanitize(thread):%{static-libtsan:-Bstatic} -ltsan %{static-libtsan:-Bdynamic} %{static-libtsan:%:include(libsanitizer.spec)%(link_libtsan)}    %{static:%ecannot specify -static with -fsanitize=thread}}    %{%:sanitize(undefined):%{static-libubsan:-Bstatic} -lubsan %{static-libubsan:-Bdynamic} %{static-libubsan:%:include(libsanitizer.spec)%(link_libubsan)}}    %{%:sanitize(leak):%{static-liblsan:-Bstatic} -llsan %{static-liblsan:-Bdynamic} %{static-liblsan:%:include(libsanitizer.spec)%(link_liblsan)}}}}     %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}    %{!nostdlib:%{!nostartfiles:%E}} %{T*} 
%(post_link) }}}}}}

Note that using the above spec file is a temporary kludge if you want to experiment with things.

Edit: spec correction - change !fno-use-linker-plugin to fuse-linker-plugin condition - i.e. assume fno-use-linker-plugin is default.

Posted: **Wed Apr 18, 2018 8:49 am**

OK, your solution to modify the specs file was the right one (the --disable-plugin didn't work in the configuration script)

However when the specs file is not copied when I type these commands

Code: Select all

make DESTDIR=$SYSROOT install-gcc 
make DESTDIR=$SYSROOT install-target-libgcc

I must do it every time.
Is it possible to include the file in gcc? Under my system when I enter this command I get this:

Code: Select all

gcc -v
Using built-in specs.
[*Some unless text*]

I understand from this command that the specs file is not a separate file on my Linux

I also still have the problem with crt0.o, here is the haoudos.h file in gcc/config:

Code: Select all

#undef TARGET_HAOUDOS
#define TARGET_HAOUDOS 1
 
#undef LIB_SPEC
#define LIB_SPEC "-lc -lg -lm -lnosys"
 
#undef STARTFILE_SPEC
#define STARTFILE_SPEC "crt0.o%s crti.o%s crtbegin.o%s"
 
#undef ENDFILE_SPEC
#define ENDFILE_SPEC "crtend.o%s crtn.o%s"

#undef STANDARD_STARTFILE_PREFIX
#define STANDARD_STARTFILE_PREFIX "/usr/lib/"
 
#undef  NO_IMPLICIT_EXTERN_C
#define NO_IMPLICIT_EXTERN_C 1
 
#undef TARGET_OS_CPP_BUILTINS
#define TARGET_OS_CPP_BUILTINS()      	\
  do {                                	\
    builtin_define ("__haoudos__");  	\
    builtin_define ("__unix__");      	\
    builtin_assert ("system=haoudos");  \
    builtin_assert ("system=unix");   	\
    builtin_assert ("system=posix");  	\
  } while(0);

Thank you in advance

Posted: **Wed Apr 18, 2018 5:07 pm**

Haoud wrote:OK, your solution to modify the specs file was the right one (the --disable-plugin didn't work in the configuration script)

I wasn't clear enough. I meant that you shouldn't use "--disable-plugins" (because it disables the gcc plugins, which are harmless in your case), and use the "--disable-lto" option. You seem to be missing the linker plugin, but gcc was build to use it. "--disable-lto" should suppress link time optimizations and drop the attempts to load the linker plugin. Now - why the plugin is not available and whether you intended this is a different question. May be its installation fails. It is supposed to be built with gcc.

Haoud wrote:However when the specs file is not copied when I type these commands
Code: Select all
make DESTDIR=$SYSROOT install-gcc 
make DESTDIR=$SYSROOT install-target-libgcc
I must do it every time.
Is it possible to include the file in gcc? Under my system when I enter this command I get this:
Code: Select all
gcc -v
Using built-in specs.
[*Some unless text*]
I understand from this command that the specs file is not a separate file on my Linux

They seem to have done away with copying external spec files during installations and use a burned-in spec file. There is even the following comment in the gcc configure script, which makes the intent clear:

Code: Select all

# We no longer install the specs file because its presence makes the
# driver slower, and because people who need it can recreate it by
# using -dumpspecs.  We remove any old version because it would
# otherwise override the specs built into the driver.

On the other hand, any spec file with filename:

Code: Select all

$(dirname "$(gcc -print-libgcc-file-name)")/specs

is going to be automatically read by gcc. It will show as "Reading specs from" in place of the built in spec processing. You may be able to use the extra_programs variable in your target case in gcc/config.gcc to add the specs into the installation list. I still insist that the spec hack is a kludge.

Haoud wrote:I also still have the problem with crt0.o, here is the haoudos.h file in gcc/config:...

The above seems fine as far as the start files are concerned. However, from the documentation I quoted earlier, the install location (or GCC_EXEC_PREFIX) is searched immediately after "-B" is processed, meaning that any crt0.o found there is going to take precedence no matter what. The fact that your crt0.o is in /usr/lib indicates to me that you may have provided it in your libc build as well. So, I wonder why do you install it as part of gcc. This means that you have built it in the libgcc build and it is specified in extra_parts in config.host. Basically, if you have crt0.o as part of libgcc and libc, libgcc takes precedence.

As I already noted, I don't have experience with porting gcc, so I may be missing information here. Keep that in mind.

OSDev.org

Configuration problem with my gcc port

Configuration problem with my gcc port

Re: Configuration problem with my gcc port

Re: Configuration problem with my gcc port

Re: Configuration problem with my gcc port

Re: Configuration problem with my gcc port

Re: Configuration problem with my gcc port

Re: Configuration problem with my gcc port

Re: Configuration problem with my gcc port