Diferença entre os sinalizadores de vinculação

Question

Estou adicionando suporte ao tempo de execução e exceção c ++ ao kernel do Linux. Para isso, preciso fornecer meus próprios lib/gcc e lib/libstdc++ em vez das bibliotecas padrão fornecidas pelo compilador.

Então, estou confuso com os sinalizadores que devem ser passados para o vinculador. No Makefile de nível superior do kernel normal, LD = $(CROSS_COMPILE)ld , que permite ao kernel usar as bibliotecas padrão e os arquivos de inicialização padrão. Para meu kernel, estou usando LD = $(CROSS_COMPILE)ld -nostdlib -nodefaultlibs -nostartfiles como dito em uma documentação. O que eu entendi da documentação do gcc é que passar -nostdlib para o linker é o de passar os dois %código%. Qual é a diferença entre essas bandeiras?

    

Answer 1

Esses sinalizadores são definidos nos arquivos de especificação do GCC , portanto, a melhor maneira de determinar as diferenças entre eles é olhar para lá:

gcc -dumpspecs

A parte relevante é a definição link_command . Isso mostra que -nostdlib , -nodefaultlibs e -nostartfiles têm o seguinte impacto:

• %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}} - isso adiciona libgcc , libpthread , libc , libieee conforme necessário, usando um macro e as sequências de caracteres lib e libgcc spec;
• %{!nostdlib:%{!nostartfiles:%S}} - isso adiciona a string startfile spec, que especifica os arquivos de objetos a serem adicionados para manipular a inicialização ( crti.o etc.)
• %{!nostdlib:%{fvtable-verify=std: -lvtv -u_vtable_map_vars_start -u_vtable_map_vars_end} %{fvtable-verify=preinit: -lvtv -u_vtable_map_vars_start -u_vtable_map_vars_end}} - isso adiciona verificação de tabela virtual usando libvtv
• %{!nostdlib:%{!nodefaultlibs:%{mmpx:%{fcheck-pointer-bounds: %{static:--whole-archive -lmpx --no-whole-archive %:include(libmpx.spec)%(link_libmpx)} %{!static:%{static-libmpx:-Bstatic --whole-archive} %{!static-libmpx:--push-state --no-as-needed} -lmpx %{!static-libmpx:--pop-state} %{static-libmpx:--no-whole-archive -Bdynamic %:include(libmpx.spec)%(link_libmpx)}}}}%{mmpx:%{fcheck-pointer-bounds:%{!fno-chkp-use-wrappers: %{static:-lmpxwrappers} %{!static:%{static-libmpxwrappers:-Bstatic} -lmpxwrappers %{static-libmpxwrappers: -Bdynamic}}}}}}} - isso lida com libmpx
• %{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address): %{static-libasan:%:include(libsanitizer.spec)%(link_libasan)} %{static:%ecannot specify -static with -fsanitize=address}} %{%:sanitize(thread): %{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:%:include(libsanitizer.spec)%(link_liblsan)}}}} - isso lida com as várias opções de higienização
• %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}} - adiciona as opções de proteção da pilha e repete a sequência do link C (cujas bibliotecas já foram especificadas no início)
• %{!nostdlib:%{!nostartfiles:%E}} - adiciona a string endfile spec, que especifica os arquivos de objeto a serem adicionados para manipular as sobras ( crtfastmath.o , crtend.o etc.)

Como você entendeu na documentação, -nostdlib é um superconjunto de -nodefaultlibs e -nostartfiles . Também desativa a verificação de tabela virtual.

Portanto, -nostdlib é suficiente para desativar todos os recursos relacionados; -nodefaultlibs e -nostartfiles não adicionam nada a ele. (Mas não faz mal mencioná-los também.)