Verwirrung um libc_nano, weak und Clang

[Vincent H. (vinci)]

Grüß euch

Ich hab eine Frage bezüglich weak Symbolen in der libc_nano (und 
libstdc++_nano). Und zwar arbeite ich gerade an einem Cortex-M4 Projekt 
dass ich aus Gründen der Compile-Zeit nun lieber mit Clang10 als mit 
GCC10 bauen würde. Das ist mit Ausnahme des Linkens eigentlich auch 
keine Hexerei und funktionierte auch recht flott.

Einige Kleinigkeiten verwirren mich jedoch. Aus irgendeinem Grund 
scheint Clang10 beim Linken nicht zu erkennen welche Symbole weak sind 
und welche nicht. Es ist somit nicht möglich Dinge wie __assert_func mit 
sinnvollen Implementierungen zu überschreiben. Welchen Linker man nutzt 
(einstellbar via -fuse-ld) spielt dabei auch keine Rolle.

Irgendwer eine Idee woran das liegen könnte?

Hier die Linker-Flags

GCC10

    -nostartfiles
    --specs=nano.specs
    -Wl,--gc-sections,-Map=${PROJECT_NAME}.map
    -T${CMAKE_CURRENT_SOURCE_DIR}/ldscript/mem.ld
    -T${CMAKE_CURRENT_SOURCE_DIR}/ldscript/sections.ld)

Clang10

    -nostartfiles
    -nostdlib
    -nostdlib++
    -Wl,--gc-sections,-Map=${PROJECT_NAME}.map
    /usr/arm-none-eabi/lib/crt0.o
    /usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crti.o
    /usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtbegin.o
    /usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtn.o
    /usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtend.o
    -L/usr/arm-none-eabi/lib/thumb/v7e-m+fp/hard/
    -L/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/
    -Wl,--start-group
    -lstdc++_nano
    -lm
    -lgcc
    -lc_nano
    -Wl,--end-group
    -T${CMAKE_CURRENT_SOURCE_DIR}/ldscript/mem.ld
    -T${CMAKE_CURRENT_SOURCE_DIR}/ldscript/sections.ld)

PS: Kann man sich irgendwie anzeigen lassen zu welchen Flags die GCC 
"spec" files auf der Kommandozeile tatsächlich runterbrechen?

/edit
Typo fixed

[Jörg W. (dl8dtl) (Moderator)]

Vincent H. schrieb:
> Kann man sich irgendwie anzeigen lassen zu welchen Flags die GCC "spec"
> files auf der Kommandozeile tatsächlich runterbrechen?

gcc -v meinst du?

[Vincent H. (vinci)]

Jörg W. schrieb:
> Vincent H. schrieb:
>> Kann man sich irgendwie anzeigen lassen zu welchen Flags die GCC "spec"
>> files auf der Kommandozeile tatsächlich runterbrechen?
>
> gcc -v meinst du?

Achja... auf die Idee hät ich auch kommen können...
Ich werd mal schaun obs da gravierende Unterschiede gibt.

[Vincent H. (vinci)]

Ich hab nun beide Linkvorgänge verbos angesehn, werd aber trotzdem nicht 
wirklich schlau draus. Zwei kleine Unterschiede fielen mir allerdings 
auf.

- GCC10 scheint zuerst meine eigenen Bibliotheken und erst anschließend 
libc_nano und Co zu linken
- GCC10 wiederholt das Linken von libc_nano in 2x Gruppen? Das hab ich 
mit Clang aber ebenfalls probiert und es scheint keinen Einfluss auf das 
Endergebnis zu haben...

GCC10

/usr/lib/gcc/arm-none-eabi/10.1.0/collect2 
-plugin /usr/lib/gcc/arm-none-eabi/10.1.0/liblto_plugin.so 
-plugin-opt=/usr/lib/gcc/arm-none-eabi/10.1.0/lto-wrapper 
-plugin-opt=-fresolution=/tmp/ccea5cKc.res 
-plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lg_nano 
-plugin-opt=-pass-through=-lc_nano 
-plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lc_nano 
--sysroot=/usr/arm-none-eabi 
-EL -X -o myelf 
-L/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard 
-L/usr/lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard 
-L/usr/arm-none-eabi/lib/thumb/v7e-m+fp/hard -L/usr/lib/gcc/arm-none-eabi/10.1.0 
-L/usr/lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/lib 
-L/usr/arm-none-eabi/lib 
--gc-sections
my.obj
libmylib.a
-lstdc++_nano -lm 
--start-group -lgcc -lg_nano -lc_nano --end-group 
--start-group -lgcc -lc_nano --end-group
-T ldscript.ld

Clang10

"/usr/bin/ld.lld" 
--gc-sections 
/usr/arm-none-eabi/lib/crt0.o 
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crti.o 
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtbegin.o 
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtn.o 
/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/crtend.o 
--start-group -lstdc++_nano -lm -lgcc -lc_nano --end-group 
my.obj
libmylib.a
-Bstatic 
-L/usr/lib/clang/10.0.0/lib/baremetal 
-L/usr/arm-none-eabi/lib/thumb/v7e-m+fp/hard/ 
-L/usr/lib/gcc/arm-none-eabi/10.1.0/thumb/v7e-m+fp/hard/ 
-T ldscript.ld
-o myelf

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Kontrolliere die Kommandozeile mit der du clang aufrufst. In deinem 
clang-Beispiel erscheinen sie in der falschen Reihenfolge.

Leider hat sich in den Köpfen vieler Programmierer festgesetzt dass die 
Kommandozeilen-Reihenfolge in der man Objektdateien und Bibliotheken 
angeben kann beliebig ist. Dank den Internet-Idioten die den selben 
Stuss von Webseite zu Webseite weiter kopieren.

Es wird aber immer noch in der Reihenfolge der Parameter gelinkt. Bei 
dynamischem Linken fällt es nur nicht so auf.

Kurzform:

gut: a.o b.o c.o -lx -ly -lz

scheiße: -lx -ly -ly a.o b.o c.o

Letzteres erscheint in deinem Beispiel
>

> --start-group -lstdc++_nano -lm -lgcc -lc_nano --end-group 
> my.obj
> libmylib.a
>

[DPA (Gast)]

Ich denke, --whole-archive ... --no-whole-archive könnten hier eventuell 
helfen: 
https://stackoverflow.com/questions/52435705/whats-difference-between-start-group-and-whole-archive-in-l

[Vincent H. (vinci)]

Hat leider ein wenig gedauert bis ich rausgefunden hab wie das in CMake 
zu bewerkstelligen ist... Hab nun ein "target_link_options" durch ein 
"target_link_libraries" ersetzen müssen. Just CMake things... ;)

Danke