OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 8:11 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Configuration problem with my gcc port
PostPosted: Sun Apr 08, 2018 10:07 am 
Offline
Member
Member

Joined: Wed Aug 10, 2016 3:07 am
Posts: 31
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
Attachment:
Capture d’écran_2018-04-08_17-58-43.png
Capture d’écran_2018-04-08_17-58-43.png [ 5.12 KiB | Viewed 2195 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)
Attachment:
Capture d’écran_2018-04-08_18-41-25.png
Capture d’écran_2018-04-08_18-41-25.png [ 1.64 KiB | Viewed 2187 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


Top
 Profile  
 
 Post subject: Re: Configuration problem with my gcc port
PostPosted: Sun Apr 08, 2018 2:21 pm 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 360
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.


Top
 Profile  
 
 Post subject: Re: Configuration problem with my gcc port
PostPosted: Mon Apr 09, 2018 1:01 am 
Offline
Member
Member

Joined: Wed Aug 10, 2016 3:07 am
Posts: 31
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...).
Attachment:
Capture d’écran_2018-04-09_08-58-00.png
Capture d’écran_2018-04-09_08-58-00.png [ 1.31 KiB | Viewed 2137 times ]


Top
 Profile  
 
 Post subject: Re: Configuration problem with my gcc port
PostPosted: Mon Apr 09, 2018 8:15 am 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 360
First, lets consult the "internals" manual of gcc:
Quote:
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.)


Top
 Profile  
 
 Post subject: Re: Configuration problem with my gcc port
PostPosted: Mon Apr 16, 2018 10:29 am 
Offline
Member
Member

Joined: Wed Aug 10, 2016 3:07 am
Posts: 31
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:
*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) }}}}}}


Top
 Profile  
 
 Post subject: Re: Configuration problem with my gcc port
PostPosted: Tue Apr 17, 2018 4:01 am 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 360
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:
*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.


Top
 Profile  
 
 Post subject: Re: Configuration problem with my gcc port
PostPosted: Wed Apr 18, 2018 8:49 am 
Offline
Member
Member

Joined: Wed Aug 10, 2016 3:07 am
Posts: 31
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:
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:
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:
#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


Top
 Profile  
 
 Post subject: Re: Configuration problem with my gcc port
PostPosted: Wed Apr 18, 2018 5:07 pm 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 360
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:
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:
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:
# 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:
$(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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: DotBot [Bot], Google [Bot] and 50 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group