7170 friert ein mit neuer download-toolchain

[RalfFriedl]

Eine berechtigte Frage,

Ich vermute nicht, daß es wirklich so gedacht war, daß die eine Option ein Symbol __progname definiert, diesem aber keinen Wert zuweist.
Wie man im oben verlinkten openwrt-Ticket sieht, wird das so definiert:

strong_alias (__uclibc_progname, __progname)

Es könnte also sein, daß aus irgend einem Grund die neueren Binutils das nicht mehr richtig machen.

 

[er13]

Aber meine Frage ging eher in die Richtung: Warum tritt das Problem jetzt auf? Die uClibc Config hat seit 3 Jahren, diese Optionen so gesetzt.

hat wohl was mit copy relocations zu tun aka mips-plt-Optimierungen, die wir für gcc-4.4.5 eingeschaltet haben. Die zwei Changesets müssen wohl rückportiert werden: 1 u. 2

 

[RalfFriedl]

Es ist anscheinend von Bedeutung, ob man für das Hauptprogramm PIC aktiviert oder nicht.
Ein einfaches Testprogammfunktioniert korrekt mit -fPIC, während ohne fPIC der Wert NULL ist. Von daher wird auch die Änderung der Option UCLIBC_HAS_PROGRAM_INVOCATION_NAME nichts bringen, weil das Problem nicht die Initialisierung der Werte ist, sondern daß nicht auf die richtige Speicherstelle zugegriffen wird.

Die Lösungsmöglichkeiten wären also:
- Den Loader so anpassen, daß er in dieser Situation das richtige tut. Im Moment bin ich mir nicht sicher, ob das überhaupt möglich ist und was dafür getan werden müßte.
- Evtl. __progname nicht als hidden definieren. Schließlich funktioniert ja auch der Zugriff auf andere Variablen, die in der Library definiert werden, wie zum Beispiel stderr.
- Alle Programme mit fPIC übersetzen. Das verbraucht vermutlich mehr Speicherplatz.
- Nur Programme, die auf __progname zugreifen, mit -fPIC übersetzen.
- So tun, als hätte die Library das Symbol gar nicht, bzw. die Option in der Library deaktivieren.

 

[er13]

hmm, warum nicht die von mir vorgeschlagenen Changeset backportieren?

An Programmen bzw. CFLAGS von diesen würde ich nichts ändern. Mir wäre es lieber den Fehler ein für alle mal an einer Stelle zu korrigieren.

 

[RalfFriedl]

Zumindest der Changeset 2 hat nichts mit dem Problem zu tun, und bei 1 bin ich mir zumindest nicht sicher, aber man könnte es mal ausprobieren.

 

[er13]

2 behebt einen Bug in 1, hat also schon was mit dem Problem zu tun...

Und bei 1 steht ja auch schon alles dabei oder soll ich auch noch den Link auf Bug1310 posten...

 

[olistudent]

Nochmal zu dem libfreetz Problem:
Ich hab eine uClibc mit LD_DEBUG Support gebaut. Der Aufruf von /bin/busybox bleibt wie folgt stecken:

_dl_get_ready_to_run:742: Beginning relocation fixups
_dl_fixup:664: relocation processing: /lib/libewnwlinux.so.2
_dl_fixup:664: relocation processing: /lib/libewnwnet.so.0
_dl_fixup:664: relocation processing: /lib/libwebsrv.so.2
_dl_fixup:664: relocation processing: /lib/libwdt.so.1
_dl_fixup:664: relocation processing: /lib/libdl.so.0
_dl_fixup:664: relocation processing: /lib/libpthread.so.0
_dl_fixup:664: relocation processing: /lib/libavmcsock.so.2
_dl_fixup:664: relocation processing: /lib/libavmcipher.so.0
_dl_fixup:664: relocation processing: /lib/libavmhmac.so.2
_dl_fixup:664: relocation processing: /lib/libboxlib.so.0
_dl_fixup:664: relocation processing: /lib/libgcc_s.so.1
_dl_fixup:664: relocation processing: /lib/libusbcfg.so.1
_dl_fixup:664: relocation processing: /lib/libc.so.0
_dl_fixup:664: relocation processing: /lib/libfreetz.so.1.0.0
_dl_fixup:664: relocation processing: /bin/busybox
_dl_protect_relro:124: RELRO protecting /lib/libc.so.0:  start:0x2ab45000, end:0x2ab46000
_dl_protect_relro:124: RELRO protecting /lib/libpthread.so.0:  start:0x2ac7b000, end:0x2ac7c000
_dl_protect_relro:124: RELRO protecting /lib/libdl.so.0:  start:0x2ac94000, end:0x2ac95000
_dl_protect_relro:124: RELRO protecting /lib/ld-uClibc.so.0:  start:0x2aabe000, end:0x2aabf000
_dl_get_ready_to_run:820: calling INIT: /lib/libc.so.0
_dl_get_ready_to_run:820: calling INIT: /lib/libpthread.so.0
_dl_get_ready_to_run:820: calling INIT: /lib/libgcc_s.so.1
_dl_get_ready_to_run:820: calling INIT: /lib/libwdt.so.1
_dl_get_ready_to_run:820: calling INIT: /lib/libavmcsock.so.2

Sieht für mich danach aus als müssten wir doch ohne die libusbcfg auskommen?

Gruß
Oliver

edit:

_dl_get_ready_to_run:820: calling INIT: /lib/libavmcsock.so.2


resolve function: pthread_once
resolve function: pthread_mutexattr_init
resolve function: pthread_mutexattr_settype
resolve function: pthread_mutex_init
resolve function: pthread_mutexattr_destroy
resolve function: getenv
resolve function: memset
resolve function: mmap
resolve function: pthread_mutex_lock
resolve function: pthread_mutex_unlock
resolve function: pthread_key_create
resolve function: strlen
resolve function: memcpy
resolve function: strcmp
resolve function: pthread_attr_init

 

[RalfFriedl]

Kommt der zweite Teil, wenn man lange genug wartet, oder kommt der ohne libfreetz?

 

[olistudent]

Ich hab eine andere LD_DEBUG_OPTION aktiviert...

 

[olistudent]

Ausnahmsweise Doppelpost, weil es hier um zwei verschiedene Themen geht. Aber der Thread lässt sich auch nicht sauber trennen...

#include <stdio.h>

main() {
        extern char *__progname;
        fprintf(stderr, "progname:%s", __progname);
}

Taugt das als Testporgramm?

Mit der dl-Toolchain uClibc bekomme ich als Ausgabe:

root@fritz:/var/mod/root# ./progname
progname:(null)

Mit aktiviertem has_invocation_progname:

root@fritz:/var/mod/root# ./progname
progname:progname

Warum gibts da jetzt kein Segfault? Wie kann man feststellen, ob ein Objekt pic oder non-pic ist? readelf?

Gruß
oliver

 

[RalfFriedl]

Taugt das als Testporgramm?

Ja, es ist im Prinzip genau das, was ich auch verwendet habe.

Warum gibts da jetzt kein Segfault?

Weil printf den Wert NULL abfängt und dann den String "(null)" ausgibt.

Wie kann man feststellen, ob ein Objekt pic oder non-pic ist? readelf?

Wenn man die Datei selbst erstellt, ist es einfach:

mipsel-linux-gcc -o progname.pic progname.c -fPIC
mipsel-linux-gcc -o progname.nopic progname.c

Bei readelf müßte man mal schauen, ob es Unterschiede gibt, bzw. ich bin mir nicht sicher, ob es ein explizites Kennzeichen in der Datei dafür gibt. Unterschiede, die mir aufgefallen sind:
- Das nopic Programm enthält eine Section ".rel.dyn".
- Diese Section enthält Einträge vom Typ "R_MIPS_COPY".

Das Problem ist auch, daß genau diese COPY-Relocation für __progname nicht richtig verarbeitet werden, für stderr allerdings schon. (Mein Testprogramm verwendet fprintf auf stderr.)

 

[olistudent]

Mit dem "Fix" (2 Changesets von er13) sieht das dann so aus:

@fritz:/# ./progname
progname:
@fritz:/# ./progname.pic
progname:progname.pic

Gruß
Oliver

 

[RalfFriedl]

Das ist besser insoweit, als daß dann openntpd nicht abstürzen würde.

Wirklich gelöst ist das Problem aber trotzdem nicht.

 

[olistudent]

Ich mach für das libfreetz Problem einen neuen Thread auf. Bitte hier nicht mehr darüber weiter diskutieren...

Gruß
Oliver

 

[olistudent]

Die Lösungsmöglichkeiten wären also:
...
- Evtl. __progname nicht als hidden definieren. Schließlich funktioniert ja auch der Zugriff auf andere Variablen, die in der Library definiert werden, wie zum Beispiel stderr.

Aus uClibc-0.9.29:

attribute_hidden const char *__uclibc_progname = NULL;
#ifdef __UCLIBC_HAS___PROGNAME__
strong_alias (__uclibc_progname, __progname)
#endif
#ifdef __UCLIBC_HAS_PROGRAM_INVOCATION_NAME__
attribute_hidden const char *__progname_full = NULL;
strong_alias (__uclibc_progname, program_invocation_short_name)
strong_alias (__progname_full, program_invocation_name)
#endif

uClibc-0.9.31:

attribute_hidden const char *__uclibc_progname = "";
#ifdef __UCLIBC_HAS_PROGRAM_INVOCATION_NAME__
const char *program_invocation_short_name = "";
const char *program_invocation_name = "";
#endif
#ifdef __UCLIBC_HAS___PROGNAME__
weak_alias (program_invocation_short_name, __progname)
weak_alias (program_invocation_name, __progname_full)
#endif

Sollte das Problem durch diese Änderung behoben werden?

Gruß
Oliver

edit: Hm, das ist doch die Änderung aus dem von er13 angegebenen Changeset...

 

[er13]

Mit dem "Fix" (2 Changesets von er13) sieht das dann so aus

Hast Du bei Deinem Test UCLIBC_HAS_PROGRAM_INVOCATION_NAME aktiviert gehabt oder nicht? Wie man in 1 sieht ist es jetzt Pflicht...

Edit: Dein Post drüber, hast Du jetzt 0.9.29 mit 0.9.31 nicht verwechselt, ich meine es ist genau umgekehrt
Edit2: und schon korrigiert, jetzt ist es richtig

 

[RalfFriedl]

Sollte das Problem durch diese Änderung behoben werden?

Mit diesen Alias-Geschichten, ob strong oder weak, habe ich mich bisher nicht beschäftigt. Man könnte es mal ohne das hidden versuchen. Ansonsten komme ich erst nächste Woche dazu, mir das genauer anzuschauen.
Die geänderte Initialisierung auf Leerstring statt NULL sollte schon mal Speicherzugriffsfehler verhindern.

 

[olistudent]

Hast Du bei Deinem Test UCLIBC_HAS_PROGRAM_INVOCATION_NAME aktiviert gehabt oder nicht? Wie man in 1 sieht ist es jetzt Pflicht...

Ich musste ja beide Optionen aktivieren. Ohne die erste gibts ja kein __progname mehr.

Gruß
Oliver

 

[er13]

@Oliver: auf Deiner Box läuft bestimmt uClibc-0.9.31, funktioniert es denn mit dieser?

 

[olistudent]

Auf der 7320 läuft gcc-4.4.5-uClibc-0.9.30.3. Damit bekomme ich auch von der non-pic Version folgende Ausgabe:

root@fritz:/var/mod/root# ./progname.nonpic
progname:progname.nonpic

Die 7270 läuft momentan mit der uClibc-0.9.29 dl-Toolchain.