OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Feb 17, 2020 7:41 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: OS-specific toolchain and shared libraries
PostPosted: Fri Jan 16, 2015 10:48 am 
Offline
Member
Member

Joined: Sat Oct 16, 2010 3:38 pm
Posts: 573
A month or so ago when I was creating a cross-compiler for my OS (glidix) it didn't automatically add crt0.o and such to the executable, so to force it to include them, I modified gcc/config/glidix.h and added a STARTFILE_SPEC and ENDFILE_SPEC at the end, here's what it looks like now:

Code:
/* Useful if you wish to make target-specific gcc changes. */
#undef TARGET_GLIDIX
#define TARGET_GLIDIX 1

/* Don't automatically add extern "C" { } around header files. */
#undef  NO_IMPLICIT_EXTERN_C
#define NO_IMPLICIT_EXTERN_C 1

/* Additional predefined macros. */
#undef TARGET_OS_CPP_BUILTINS
#define TARGET_OS_CPP_BUILTINS()      \
  do {                                \
    builtin_define ("__glidix__");      \
    builtin_define ("__unix__");      \
    builtin_assert ("system=glidix");   \
    builtin_assert ("system=unix");   \
    builtin_assert ("system=posix");   \
  } while(0);

#undef ENDFILE_SPEC
#define ENDFILE_SPEC "crtend.o%s crtn.o%s"

#undef STARTFILE_SPEC
#define STARTFILE_SPEC "crt0.o%s crti.o%s crtbegin.o%s"


It now successfully builds static executable, but refuses to build a shared library, because when I run:

Code:
x86_64-glidix-gcc -shared -o out/lib/libc.so out/lib/libc.a


("libc.a" does NOT contain the crt0.o files; they are seperate files installed under /glidix/lib), it tries to link crt0.o into libc.so, and fails due to undefined reference to 'main'. Is there something I am doing horribly wrong? And if so, what is it?


Top
 Profile  
 
 Post subject: Re: OS-specific toolchain and shared libraries
PostPosted: Fri Jan 16, 2015 3:16 pm 
Offline
Member
Member

Joined: Thu Mar 25, 2010 11:26 pm
Posts: 1801
Location: Melbourne, Australia
My command line looks like this
Code:
x86_64-anvil-gcc -m64 -Wl,-e_start -shared -o libc.so *.o

So I think your command line is okay. I specifically link in a special version of the start-up code in that list of *.o files because my libc.o is also my ld loader but you needn't do that.

The difference is likely in your STARTFILE_SPEC. You need to tell it to leave out the crt1.o file when you're building shared.

Code:
#undef  STARTFILE_SPEC
#define STARTFILE_SPEC "%{!shared:crt1.o%s} \
   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"


The first bit tells gcc not to include crt1.o if the -shared option is supplied

_________________
If a trainstation is where trains stop, what is a workstation ?


Top
 Profile  
 
 Post subject: Re: OS-specific toolchain and shared libraries
PostPosted: Sat Jan 17, 2015 12:37 pm 
Offline
Member
Member

Joined: Sat Oct 16, 2010 3:38 pm
Posts: 573
Thank you for your help. It also seems that when I create static executable, they are linked so that there is only one program header, which stores all code, data and bss in a single segment, with read-write-execute permission. Does anyone know why it may be creating this one segment instead of 2? There should be, by default, a segment for code (read-and-execute) and for data (read-and-write).


Top
 Profile  
 
 Post subject: Re: OS-specific toolchain and shared libraries
PostPosted: Sat Jan 17, 2015 1:21 pm 
Offline
Member
Member

Joined: Sat Oct 16, 2010 3:38 pm
Posts: 573
OK, I managed to get it to link the shared library but it was linked as an executable instead of a DYN...

EDIT: I used the -v flag and it turns out that GCC is not passing the -shared option to the linker:

Code:
mariusz@mariusz-Satellite-A660:~/Madd/Glidix/glidix/userspace/libc/out/lib$ x86_64-glidix-gcc -v -shared -o libc.so libc.a
Using built-in specs.
COLLECT_GCC=x86_64-glidix-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-glidix/4.9.0/lto-wrapper
Target: x86_64-glidix
Configured with: ../glidix-gcc/configure --target=x86_64-glidix --prefix=/glidix/usr --exec-prefix=/usr --with-sysroot=/glidix --enable-languages=c --disable-nls
Thread model: single
gcc version 4.9.0 (GCC)
COMPILER_PATH=/usr/libexec/gcc/x86_64-glidix/4.9.0/:/usr/libexec/gcc/x86_64-glidix/4.9.0/:/usr/libexec/gcc/x86_64-glidix/:/usr/lib/gcc/x86_64-glidix/4.9.0/:/usr/lib/gcc/x86_64-glidix/:/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-glidix/4.9.0/:/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/lib/:/glidix/lib/
COLLECT_GCC_OPTIONS='-v' '-shared' '-o' 'libc.so' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-glidix/4.9.0/collect2 -plugin /usr/libexec/gcc/x86_64-glidix/4.9.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-glidix/4.9.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc3xbPRP.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc --sysroot=/glidix -o libc.so /glidix/lib/crti.o /usr/lib/gcc/x86_64-glidix/4.9.0/crtbegin.o -L/usr/lib/gcc/x86_64-glidix/4.9.0 -L/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/lib -L/glidix/lib libc.a -lgcc -lgcc /usr/lib/gcc/x86_64-glidix/4.9.0/crtend.o /glidix/lib/crtn.o
/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000c0


Top
 Profile  
 
 Post subject: Re: OS-specific toolchain and shared libraries
PostPosted: Sat Jan 17, 2015 2:53 pm 
Offline
Member
Member

Joined: Thu Mar 25, 2010 11:26 pm
Posts: 1801
Location: Melbourne, Australia
mariuszp wrote:
EDIT: I used the -v flag and it turns out that GCC is not passing the -shared option to the linker:

You need a LINK_SPEC to control what gets passed to the linker. Here's mine
Code:
#undef  LINK_SPEC
#define LINK_SPEC "%{" SPEC_64 ":-m elf_x86_64} %{" SPEC_32 ":-m elf_i386} \
  %{shared:-shared} \
  %{!shared: \
    %{!static: \
      %{rdynamic:-export-dynamic} \
      %{" SPEC_32 ":-dynamic-linker " "/lib32/ld-anvil32.so" "} \
      %{" SPEC_64 ":-dynamic-linker " "/lib/ld-anvil.so" "}} \
    %{static:-static}}"
The %{shared:-shared} is the bit you need right now. But to support things like dlopen you need it all.

_________________
If a trainstation is where trains stop, what is a workstation ?


Last edited by gerryg400 on Sat Jan 17, 2015 2:54 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: OS-specific toolchain and shared libraries
PostPosted: Sat Jan 17, 2015 2:53 pm 
Offline
Member
Member

Joined: Thu Mar 25, 2010 11:26 pm
Posts: 1801
Location: Melbourne, Australia
mariuszp wrote:
Thank you for your help. It also seems that when I create static executable, they are linked so that there is only one program header, which stores all code, data and bss in a single segment, with read-write-execute permission. Does anyone know why it may be creating this one segment instead of 2? There should be, by default, a segment for code (read-and-execute) and for data (read-and-write).
Did you fix this issue ?

_________________
If a trainstation is where trains stop, what is a workstation ?


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

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 8 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