[Info] freetz für serf1.3.x angepasst

[kmeleon]

Hallo!

Weil ich reproduzierbare Abstürze des auf der Fritzbox 7270v2 laufenden apache2 in Verbindung mit subversion habe, habe ich zwei Dateien von freetz so abgeändert, dass die aktuelle libserf1.3.4 gebaut werden kann. Serf nutzt nach Version 1.2.1 nicht mehr configure und make, sondern scons. Deswegen wurden bisher keine neueren Versionen unterstützt. Die Umbauarbeiten hielten sich in Grenzen (hab ca. 1,5 Stunden gebraucht), allerdings ist es noch nicht 100%ig umgesetzt: Das serf Paket wird lauffähig gebaut, aber mehr auch noch nicht. Falls jemand Interesse an den Files hat, kann er sich bei mir melden. Vielleicht liest auch ein freetz-Entwickler mit, der es erweitern und integrieren möchte.

Leider hat es meine apache2 segfaults noch nicht gelöst und ich ich muss weiter forschen...

Viele Grüße
K-Meleon

 

[er13]

Hallo kmeleon,

ich habe auch einen version-bump-patch für libserf, der setzt aber voraus, dass auf dem Build-System scons in der richtigen Version installiert ist. Meine Idee war, dass freetz scons einfach mitliefert, zumal Python (von dem scons abhängt) bereits mitgeliefert wird. Ich bin leider noch nicht dazu gekommen, es umzusetzen.

Ansonsten gibt es bereits ein Ticket zu dem Thema.

Grüße,
Gene

p.s. Deinen libserf-Patch kannst Du trotzdem anhängen.

 

[kmeleon]

Hi Gene!

Jo, das ist bei mir auch alles so. Scons muss installiert sein! Wenn Du es eh schon gemacht hast, dann wäre ich eher an Deiner Umsetzung interessiert . Ich habe es nur so weit getrieben, dass es herunterlädt und baut: Keine angepasste Clean-Regel, keine vernünftige Trennung von Configure und Build. Es läuft, aber zum öffentlichen Anhängen ist es mir zu unfertig. Ich wollte ja eigentlich meinen apache-Fehler lösen :-|

Viele Grüße, K-Meleon

 

[er13]

Anbei mein Patch. Bekannte Bugs: subversion lässt sich damit nur dynamisch linken, statisch geht (noch) nicht. Scons in Version 2.3.0 auf dem Host wird vorausgesetzt.

Andere Frage: warum hast Du libserf überhaupt aktualisiert? Da Du von apache sprichst, nehme ich mal an, dass Du den subversion-Server (svnserve) betreibst mit Zugang über http, i.e. über apache. libserf wird jedoch nur für den subversion-Client benötigt (svn). Damit war es eigentlich von Anfang an klar, dass der Version-Bump von libserf keine Abhilfe schaffen wird.

 

[kmeleon]

Super, ich danke Dir! Werde den Patch mal bei Gelegenheit ausprobieren.

Stimmt, Du hast Recht. Ich hatte im Zusammenhang mit serf nur etwas von HTTP gelesen und das war dann eher der Schuss ins Blaue und "kostet ja nicht viel Zeit, wer weiß wofür es gut ist" . Dass sich das nur auf die Client-Seite beschränkt, wusste ich nicht (klingt für mich jetzt auch logisch, weil apache ja die Serverseite übernimmt). Die Abhängigkeiten/Funktionalitäten im Detail sind mir bei dem "Programmpaket" von apache, den Libraries/Modulen von apache, svn und den Libraries von svn einfach nicht klar, das muss ich zugeben. Für den Segfault hätte aber auch schnell eine tiefer liegende Library verantwortlich sein können.

 

[kmeleon]

Die Frage ist jetzt nur: Wie löse ich das Problem? Ich habe apache2 und alle anderen Module mit den Debug-Symbolen gebaut, um einen Backtrace zu bekommen. Wenn ich versuche, apache2 mit den benötigten Modulen über gdb auf der Fritzbox laufen zu lassen, platzt sie leider und resettet irgendwann. Kann man sich irgendwie noch RAM-schonender dem Problem lösen? Damit habe ich unter Linux bisher keine Erfahrung gesammelt.

Ich muss zugeben, dass mein Fritzbox/Freetz-Setup auch nicht ganz sauber ist: Ich benutze die original Firmware und subversion, apache und die Libraries liegen auf dem USB-Stick. Subversion und apache laufen aber wunderbar einzeln. Ich kann über das svn-Protokoll auschecken und über apache im Repository herumstöbern. Nur das Auschecken über HTTP klappt nicht: Es werden keine Files ausgecheckt, aber TortoiseSVN meldet auch keinen Fehler.

 

[olistudent]

Wie wäre es mit swap auf den usbstick? Ansonsten kannst du versuchen einige AVM Daemons zu beenden.

 

[kmeleon]

@olistudent: Wusste nicht, dass das so einfach geht. War mir eben gerade sehr hilfreich. Danke schön!

Ich bin nun etwas weiter, aber nun weiß ich keinen Rat mehr. Mit der fertig gebauten freetz-Toolchain (gcc 4.6.4) bekomme ich folgende Fehlermeldung:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x2aff89e4 in __gtsf2 (arg_a=<optimized out>, arg_b=<optimized out>)
    at ../.././gcc/fp-bit.c:1246
#2  0x2afe91e8 in sort_encoding_pref (accept_rec1=0x5bb140,
    accept_rec2=0x5bb148) at subversion/mod_dav_svn/repos.c:1664
#3  0x2ae9c9ec in qsort () from /lib/libc.so.0
#4  0x2afe9328 in negotiate_encoding_prefs (r=0x5b9970,
    svndiff_version=0x5bb104) at subversion/mod_dav_svn/repos.c:1691
#5  0x2afea26c in get_resource (warning: GDB can't find the start of the function at 0x2af96392.

    GDB is unable to find the start of the function at 0x2af96392
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2af96392 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
r=0x5b9970, root_path=0x5bb060 "/svn/linux", label=0x0, use_checked_in=0,
    resource=0x7f1ffb20) at subversion/mod_dav_svn/repos.c:2040
#6  0x2af96394 in ?? () from /var/media/ftp/Storage-00/lib/apache2/mod_dav.so

Weiter hat gdb es nicht aufgelöst, weil ihm dann nur noch gestrippte Libraries zur Verfügung standen (obwohl ich das in freetz komplett ausgeschaltet habe). Aber man sieht, dass er ja irgendwann in die libc und libgcc abtaucht und dort der Fehler passiert. Daraufhin habe ich ihm auch noch eine externe libc (vom USB-Stick) zur Verfügung gestellt. Das hat aber auch nichts verändert:

#0  0x00000000 in ?? ()
#1  0x2afe79e4 in __gtsf2 (arg_a=<optimized out>, arg_b=<optimized out>)
    at ../.././gcc/fp-bit.c:1246
#2  0x2afd81e8 in sort_encoding_pref (accept_rec1=0x5bb158, accept_rec2=0x5bb160)
    at subversion/mod_dav_svn/repos.c:1664
#3  0x2aebb45c in qsort () from /var/media/ftp/Storage-00/lib/libc.so.0
#4  0x2afd8328 in negotiate_encoding_prefs (r=0x5b9988, svndiff_version=0x5bb11c)
    at subversion/mod_dav_svn/repos.c:1691
#5  0x2afd926c in get_resource (warning: GDB can't find the start of the function at 0x2a                    f85392.

Danach habe ich gehofft, dass ja wirklich etwas mit der libc/libgcc nicht stimmen könnte, die neuere Toolchain (gcc 4.7.3) bauen lassen und noch weitere nicht gestrippte Libaraires unter Verwendung von 64MB Swap-Speicher eingebunden. Nun ist der Backtrace etwas länger und die Funktion, die den Fehler hervorruft, eine andere

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x2b0384b4 in __nesf2 (arg_a=0.100000024, arg_b=0)
    at /home/freetz/fritzbox/freetz/freetz-devel/source/toolchain-mipsel_gcc-4.7.3_uClibc-0.9.32.1/gcc-4.7.3/libgcc/fp-bit.c:1221
#2  0x2b027498 in sort_encoding_pref (accept_rec1=0x57b0a0, accept_rec2=0x57b0a8) at subversion/mod_dav_svn/repos.c:1664
#3  0x2aec79ec in qsort () from /lib/libc.so.0
#4  0x2b0275f4 in negotiate_encoding_prefs (r=0x5798d0, svndiff_version=0x57b064) at subversion/mod_dav_svn/repos.c:1691
#5  0x2b028530 in get_resource (r=0x5798d0, root_path=0x57afc0 "/svn/pitx-sp", label=0x0, use_checked_in=0, resource=0x7f1ffb20)
    at subversion/mod_dav_svn/repos.c:2040
#6  0x2afc4624 in dav_get_resource (r=0x5798d0, label_allowed=0, use_checked_in=0, res_p=0x7f1ffb20) at mod_dav.c:717
#7  0x2afcf4a8 in dav_method_report (r=0x5798d0) at mod_dav.c:4112
#8  0x2afd1440 in dav_handler (r=0x5798d0) at mod_dav.c:4763
#9  0x00456b38 in ap_run_handler (r=0x5798d0) at config.c:170
#10 0x00457a4c in ap_invoke_handler (r=0x5798d0) at config.c:439
#11 0x0047b2f0 in ap_process_async_request (r=0x5798d0) at http_request.c:317
#12 0x0047b424 in ap_process_request (r=0x5798d0) at http_request.c:363
#13 0x00475cf4 in ap_process_http_sync_connection (c=0x5158a8) at http_core.c:190
#14 0x00475e60 in ap_process_http_connection (c=0x5158a8) at http_core.c:231
#15 0x00467e84 in ap_run_process_connection (c=0x5158a8) at connection.c:41
#16 0x0046858c in ap_process_connection (c=0x5158a8, csd=0x5156f8) at connection.c:202
#17 0x004871b4 in process_socket (thd=0x4edcf8, p=0x5156b0, sock=0x5156f8, my_child_num=0, my_thread_num=0, bucket_alloc=0x572880) at worker.c:619
#18 0x004883cc in worker_thread (thd=0x4edcf8, dummy=0x509570) at worker.c:978
#19 0x2ad70c6c in dummy_worker (opaque=0x4edcf8) at threadproc/unix/thread.c:142
#20 0x2ae05604 in pthread_start_thread () from /var/media/ftp/Storage-00/lib/libpthread.so.0
#21 0x2ae0567c in pthread_start_thread_event () from /var/media/ftp/Storage-00/lib/libpthread.so.0
#22 0x2ae7e718 in __thread_start () from /lib/libc.so.0
Backtrace stopped: frame did not save the PC
(gdb)

Folgend auch nochmal unter Verwendung der libc von freetz vom USB-Stick

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xc04 (LWP 5227)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x2b05f4b4 in __nesf2 (arg_a=0.100000024, arg_b=0)
    at /home/freetz/fritzbox/freetz/freetz-devel/source/toolchain-mipsel_gcc-4.7.3_uClibc-0.9.32.1/gcc-4.7.3/libgcc/fp-bit.c:1221
#2  0x2b04e498 in sort_encoding_pref (accept_rec1=0x57b0a0, accept_rec2=0x57b0a8) at subversion/mod_dav_svn/repos.c:1664
#3  0x2af087d8 in __GI_qsort (base=0x57b0a0, nel=24, width=8, comp=0x2b04e42c <sort_encoding_pref>) at libc/stdlib/stdlib.c:826
#4  0x2b04e5f4 in negotiate_encoding_prefs (r=0x5798d0, svndiff_version=0x57b064) at subversion/mod_dav_svn/repos.c:1691
#5  0x2b04f530 in get_resource (r=0x5798d0, root_path=0x57afc0 "/svn/pitx-sp", label=0x0, use_checked_in=0, resource=0x7efffb20)
    at subversion/mod_dav_svn/repos.c:2040
#6  0x2afeb624 in dav_get_resource (r=0x5798d0, label_allowed=0, use_checked_in=0, res_p=0x7efffb20) at mod_dav.c:717
#7  0x2aff64a8 in dav_method_report (r=0x5798d0) at mod_dav.c:4112
#8  0x2aff8440 in dav_handler (r=0x5798d0) at mod_dav.c:4763
#9  0x00456b38 in ap_run_handler (r=0x5798d0) at config.c:170
#10 0x00457a4c in ap_invoke_handler (r=0x5798d0) at config.c:439
#11 0x0047b2f0 in ap_process_async_request (r=0x5798d0) at http_request.c:317
#12 0x0047b424 in ap_process_request (r=0x5798d0) at http_request.c:363
#13 0x00475cf4 in ap_process_http_sync_connection (c=0x5158a8) at http_core.c:190
#14 0x00475e60 in ap_process_http_connection (c=0x5158a8) at http_core.c:231
#15 0x00467e84 in ap_run_process_connection (c=0x5158a8) at connection.c:41
#16 0x0046858c in ap_process_connection (c=0x5158a8, csd=0x5156f8) at connection.c:202
#17 0x004871b4 in process_socket (thd=0x4edd18, p=0x5156b0, sock=0x5156f8, my_child_num=0, my_thread_num=1, bucket_alloc=0x572880) at worker.c:619
#18 0x004883cc in worker_thread (thd=0x4edd18, dummy=0x509570) at worker.c:978
#19 0x2ad70c6c in dummy_worker (opaque=0x4edd18) at threadproc/unix/thread.c:142
#20 0x2ae05604 in pthread_start_thread () from /var/media/ftp/Storage-00/lib/libpthread.so.0
#21 0x2ae0567c in pthread_start_thread_event () from /var/media/ftp/Storage-00/lib/libpthread.so.0
#22 0x2ae7f8f8 in __thread_start () at libc/sysdeps/linux/mips/clone.S:146
Backtrace stopped: frame did not save the PC

Vermutlich beissen sich da die verschiedenen libc-Versionen oder woran kann das liegen? Hat jemand noch eine Idee?

 

[RalfFriedl]

Du solltest keine verschiedenen libc Versionen mischen. Trotzdem sieht dieser Fehler nicht danach aus, es sei denn, es wird irgendwo wahllos Speicher überschrieben, was natürlich die Folge unterschiedlicher C Libraries sein kann.Normalerweise sollten die beiden Funktionen keinen Speicherzugriffsfehler produzieren.

Mach mal im Debugger folgendes:

x/40i __gtsf2
x/40i __nesf2
x/48i __unpack_f
x/64i __fpcmp_parts_f
p/x $ra

 

[kmeleon]

Ich fasse es nicht! Ich habe zusätzlich "just for fun" auch noch die 4.8.2er Toolchain ausprobiert und damit läuft es. Ich weiß noch nicht, ob andere Sachen dafür vielleicht nicht mehr laufen, aber der svn checkout via http funktioniert.

Mann-o-mann, war das ein Akt! Seit Donnerstagabend versuche ich den Fehler zu finden. Aber ich bin glücklich und habe viel dazu gerlernt.

@RalfFriedl: Soll ich die Befehle von Dir oben noch ausführen? Dann würde ich nochmal alles für 4.6.4 umstellen und den Fehler wieder reproduzieren! Vielleicht kann ich noch weitere Sachen lernen. Aber nur, wenn Du Zeit und Lust dazu hast...

 

[RalfFriedl]

Vermutlich liegt der Fehler daran, dass inkompatible Libraries zusammen verwendet wurden. Wenn es jetzt funktioniert, sei froh darüber. Wegen mir müssen wir dem nicht weiter nachgehen.

Wenn es Dich interessiert, kannst Du nochmal umstellen, aber behalte das funktionierende Image.

 

[kmeleon]

So, die Umstellung hat etwas länger gedauert. Irgendwie wollte er die libthread_db nicht annehmen und dann hat die Kombination apache/gdb immer nen Segfault gemeldet. Mal gucken, was Du da siehst:

(gdb) x/80i __gtsf2
   0x2b03e518 <__gtsf2>:        lui     gp,0x2
   0x2b03e51c <__gtsf2+4>:      addiu   gp,gp,27192
   0x2b03e520 <__gtsf2+8>:      addu    gp,gp,t9
   0x2b03e524 <__gtsf2+12>:     addiu   sp,sp,-72
   0x2b03e528 <__gtsf2+16>:     sw      ra,68(sp)
   0x2b03e52c <__gtsf2+20>:     sw      s8,64(sp)
   0x2b03e530 <__gtsf2+24>:     move    s8,sp
   0x2b03e534 <__gtsf2+28>:     sw      gp,16(sp)
   0x2b03e538 <__gtsf2+32>:     sw      a0,72(s8)
   0x2b03e53c <__gtsf2+36>:     sw      a1,76(s8)
   0x2b03e540 <__gtsf2+40>:     lw      v0,72(s8)
   0x2b03e544 <__gtsf2+44>:     sw      v0,56(s8)
   0x2b03e548 <__gtsf2+48>:     lw      v0,76(s8)
   0x2b03e54c <__gtsf2+52>:     sw      v0,60(s8)
   0x2b03e550 <__gtsf2+56>:     addiu   v0,s8,56
   0x2b03e554 <__gtsf2+60>:     move    a0,v0
   0x2b03e558 <__gtsf2+64>:     addiu   v0,s8,24
   0x2b03e55c <__gtsf2+68>:     move    a1,v0
   0x2b03e560 <__gtsf2+72>:     lw      v0,-32680(gp)
   0x2b03e564 <__gtsf2+76>:     move    t9,v0
   0x2b03e568 <__gtsf2+80>:     jalr    t9
   0x2b03e56c <__gtsf2+84>:     nop
   0x2b03e570 <__gtsf2+88>:     lw      gp,16(s8)
   0x2b03e574 <__gtsf2+92>:     addiu   v1,s8,60
   0x2b03e578 <__gtsf2+96>:     addiu   v0,s8,40
   0x2b03e57c <__gtsf2+100>:    move    a0,v1
   0x2b03e580 <__gtsf2+104>:    move    a1,v0
   0x2b03e584 <__gtsf2+108>:    lw      v0,-32680(gp)
   0x2b03e588 <__gtsf2+112>:    move    t9,v0
   0x2b03e58c <__gtsf2+116>:    jalr    t9
   0x2b03e590 <__gtsf2+120>:    nop
   0x2b03e594 <__gtsf2+124>:    lw      gp,16(s8)
   0x2b03e598 <__gtsf2+128>:    addiu   v0,s8,24
   0x2b03e59c <__gtsf2+132>:    move    a0,v0
   0x2b03e5a0 <__gtsf2+136>:    lw      v0,-32696(gp)
   0x2b03e5a4 <__gtsf2+140>:    addiu   v0,v0,17584
   0x2b03e5a8 <__gtsf2+144>:    move    t9,v0
   0x2b03e5ac <__gtsf2+148>:    jalr    t9
   0x2b03e5b0 <__gtsf2+152>:    nop
   0x2b03e5b4 <__gtsf2+156>:    lw      gp,16(s8)
   0x2b03e5b8 <__gtsf2+160>:    bnez    v0,0x2b03e5e8 <__gtsf2+208>
   0x2b03e5bc <__gtsf2+164>:    nop
   0x2b03e5c0 <__gtsf2+168>:    addiu   v0,s8,40
   0x2b03e5c4 <__gtsf2+172>:    move    a0,v0
   0x2b03e5c8 <__gtsf2+176>:    lw      v0,-32696(gp)
   0x2b03e5cc <__gtsf2+180>:    addiu   v0,v0,17584
   0x2b03e5d0 <__gtsf2+184>:    move    t9,v0
   0x2b03e5d4 <__gtsf2+188>:    jalr    t9
   0x2b03e5d8 <__gtsf2+192>:    nop
   0x2b03e5dc <__gtsf2+196>:    lw      gp,16(s8)
   0x2b03e5e0 <__gtsf2+200>:    beqz    v0,0x2b03e5f4 <__gtsf2+220>
   0x2b03e5e4 <__gtsf2+204>:    nop
   0x2b03e5e8 <__gtsf2+208>:    li      v0,-1
   0x2b03e5ec <__gtsf2+212>:    b       0x2b03e618 <__gtsf2+256>
   0x2b03e5f0 <__gtsf2+216>:    nop
   0x2b03e5f4 <__gtsf2+220>:    addiu   v0,s8,40
   0x2b03e5f8 <__gtsf2+224>:    addiu   v1,s8,24
   0x2b03e5fc <__gtsf2+228>:    move    a0,v1
   0x2b03e600 <__gtsf2+232>:    move    a1,v0
   0x2b03e604 <__gtsf2+236>:    lw      v0,-31684(gp)
   0x2b03e608 <__gtsf2+240>:    move    t9,v0
   0x2b03e60c <__gtsf2+244>:    jalr    t9
   0x2b03e610 <__gtsf2+248>:    nop
   0x2b03e614 <__gtsf2+252>:    lw      gp,16(s8)
   0x2b03e618 <__gtsf2+256>:    move    sp,s8
   0x2b03e61c <__gtsf2+260>:    lw      ra,68(sp)
   0x2b03e620 <__gtsf2+264>:    lw      s8,64(sp)
   0x2b03e624 <__gtsf2+268>:    addiu   sp,sp,72
   0x2b03e628 <__gtsf2+272>:    jr      ra
   0x2b03e62c <__gtsf2+276>:    nop
   0x2b03e630 <__extendsfdf2>:  lui     gp,0x2
...
(gdb) x/80i __nesf2
   0x2b03e398 <__nesf2>:        lui     gp,0x2
   0x2b03e39c <__nesf2+4>:      addiu   gp,gp,27576
   0x2b03e3a0 <__nesf2+8>:      addu    gp,gp,t9
   0x2b03e3a4 <__nesf2+12>:     addiu   sp,sp,-72
   0x2b03e3a8 <__nesf2+16>:     sw      ra,68(sp)
   0x2b03e3ac <__nesf2+20>:     sw      s8,64(sp)
   0x2b03e3b0 <__nesf2+24>:     move    s8,sp
   0x2b03e3b4 <__nesf2+28>:     sw      gp,16(sp)
   0x2b03e3b8 <__nesf2+32>:     sw      a0,72(s8)
   0x2b03e3bc <__nesf2+36>:     sw      a1,76(s8)
   0x2b03e3c0 <__nesf2+40>:     lw      v0,72(s8)
   0x2b03e3c4 <__nesf2+44>:     sw      v0,56(s8)
   0x2b03e3c8 <__nesf2+48>:     lw      v0,76(s8)
   0x2b03e3cc <__nesf2+52>:     sw      v0,60(s8)
   0x2b03e3d0 <__nesf2+56>:     addiu   v0,s8,56
   0x2b03e3d4 <__nesf2+60>:     move    a0,v0
   0x2b03e3d8 <__nesf2+64>:     addiu   v0,s8,24
   0x2b03e3dc <__nesf2+68>:     move    a1,v0
   0x2b03e3e0 <__nesf2+72>:     lw      v0,-32680(gp)
   0x2b03e3e4 <__nesf2+76>:     move    t9,v0
   0x2b03e3e8 <__nesf2+80>:     jalr    t9
   0x2b03e3ec <__nesf2+84>:     nop
   0x2b03e3f0 <__nesf2+88>:     lw      gp,16(s8)
   0x2b03e3f4 <__nesf2+92>:     addiu   v1,s8,60
   0x2b03e3f8 <__nesf2+96>:     addiu   v0,s8,40
   0x2b03e3fc <__nesf2+100>:    move    a0,v1
   0x2b03e400 <__nesf2+104>:    move    a1,v0
   0x2b03e404 <__nesf2+108>:    lw      v0,-32680(gp)
   0x2b03e408 <__nesf2+112>:    move    t9,v0
   0x2b03e40c <__nesf2+116>:    jalr    t9
   0x2b03e410 <__nesf2+120>:    nop
   0x2b03e414 <__nesf2+124>:    lw      gp,16(s8)
   0x2b03e418 <__nesf2+128>:    addiu   v0,s8,24
   0x2b03e41c <__nesf2+132>:    move    a0,v0
   0x2b03e420 <__nesf2+136>:    lw      v0,-32696(gp)
   0x2b03e424 <__nesf2+140>:    addiu   v0,v0,17200
   0x2b03e428 <__nesf2+144>:    move    t9,v0
   0x2b03e42c <__nesf2+148>:    jalr    t9
   0x2b03e430 <__nesf2+152>:    nop
   0x2b03e434 <__nesf2+156>:    lw      gp,16(s8)
   0x2b03e438 <__nesf2+160>:    bnez    v0,0x2b03e468 <__nesf2+208>
   0x2b03e43c <__nesf2+164>:    nop
   0x2b03e440 <__nesf2+168>:    addiu   v0,s8,40
   0x2b03e444 <__nesf2+172>:    move    a0,v0
   0x2b03e448 <__nesf2+176>:    lw      v0,-32696(gp)
   0x2b03e44c <__nesf2+180>:    addiu   v0,v0,17200
   0x2b03e450 <__nesf2+184>:    move    t9,v0
   0x2b03e454 <__nesf2+188>:    jalr    t9
   0x2b03e458 <__nesf2+192>:    nop
   0x2b03e45c <__nesf2+196>:    lw      gp,16(s8)
   0x2b03e460 <__nesf2+200>:    beqz    v0,0x2b03e474 <__nesf2+220>
   0x2b03e464 <__nesf2+204>:    nop
   0x2b03e468 <__nesf2+208>:    li      v0,1
   0x2b03e46c <__nesf2+212>:    b       0x2b03e498 <__nesf2+256>
   0x2b03e470 <__nesf2+216>:    nop
   0x2b03e474 <__nesf2+220>:    addiu   v0,s8,40
   0x2b03e478 <__nesf2+224>:    addiu   v1,s8,24
   0x2b03e47c <__nesf2+228>:    move    a0,v1
   0x2b03e480 <__nesf2+232>:    move    a1,v0
   0x2b03e484 <__nesf2+236>:    lw      v0,-31684(gp)
   0x2b03e488 <__nesf2+240>:    move    t9,v0
   0x2b03e48c <__nesf2+244>:    jalr    t9
   0x2b03e490 <__nesf2+248>:    nop
   0x2b03e494 <__nesf2+252>:    lw      gp,16(s8)
   0x2b03e498 <__nesf2+256>:    move    sp,s8
   0x2b03e49c <__nesf2+260>:    lw      ra,68(sp)
   0x2b03e4a0 <__nesf2+264>:    lw      s8,64(sp)
   0x2b03e4a4 <__nesf2+268>:    addiu   sp,sp,72
   0x2b03e4a8 <__nesf2+272>:    jr      ra
   0x2b03e4ac <__nesf2+276>:    nop
   0x2b03e4b0 <isnan>:  addiu   sp,sp,-8
...
(gdb) x/140i __unpack_f
   0x491030 <__unpack_f>:       addiu   sp,sp,-32
   0x491034 <__unpack_f+4>:     sw      s8,28(sp)
   0x491038 <__unpack_f+8>:     move    s8,sp
   0x49103c <__unpack_f+12>:    sw      a0,32(s8)
   0x491040 <__unpack_f+16>:    sw      a1,36(s8)
   0x491044 <__unpack_f+20>:    lw      v0,32(s8)
   0x491048 <__unpack_f+24>:    lw      v1,0(v0)
   0x49104c <__unpack_f+28>:    lui     v0,0x7f
   0x491050 <__unpack_f+32>:    ori     v0,v0,0xffff
   0x491054 <__unpack_f+36>:    and     v0,v1,v0
   0x491058 <__unpack_f+40>:    sw      v0,8(s8)
   0x49105c <__unpack_f+44>:    lw      v0,32(s8)
   0x491060 <__unpack_f+48>:    lw      v0,0(v0)
   0x491064 <__unpack_f+52>:    srl     v0,v0,0x17
   0x491068 <__unpack_f+56>:    move    v1,v0
   0x49106c <__unpack_f+60>:    li      v0,-1
   0x491070 <__unpack_f+64>:    and     v0,v1,v0
   0x491074 <__unpack_f+68>:    andi    v0,v0,0xff
   0x491078 <__unpack_f+72>:    sw      v0,12(s8)
   0x49107c <__unpack_f+76>:    lw      v0,32(s8)
   0x491080 <__unpack_f+80>:    lw      v0,0(v0)
   0x491084 <__unpack_f+84>:    srl     v0,v0,0x1f
   0x491088 <__unpack_f+88>:    andi    v0,v0,0xff
   0x49108c <__unpack_f+92>:    sw      v0,16(s8)
   0x491090 <__unpack_f+96>:    lw      v1,16(s8)
   0x491094 <__unpack_f+100>:   lw      v0,36(s8)
   0x491098 <__unpack_f+104>:   sw      v1,4(v0)
   0x49109c <__unpack_f+108>:   lw      v0,12(s8)
   0x4910a0 <__unpack_f+112>:   bnez    v0,0x491140 <__unpack_f+272>
   0x4910a4 <__unpack_f+116>:   nop
   0x4910a8 <__unpack_f+120>:   lw      v0,8(s8)
   0x4910ac <__unpack_f+124>:   bnez    v0,0x4910c8 <__unpack_f+152>
   0x4910b0 <__unpack_f+128>:   nop
   0x4910b4 <__unpack_f+132>:   lw      v0,36(s8)
   0x4910b8 <__unpack_f+136>:   li      v1,2
   0x4910bc <__unpack_f+140>:   sw      v1,0(v0)
   0x4910c0 <__unpack_f+144>:   b       0x4911f0 <__unpack_f+448>
   0x4910c4 <__unpack_f+148>:   nop
   0x4910c8 <__unpack_f+152>:   lw      v0,12(s8)
   0x4910cc <__unpack_f+156>:   addiu   v1,v0,-126
   0x4910d0 <__unpack_f+160>:   lw      v0,36(s8)
   0x4910d4 <__unpack_f+164>:   sw      v1,8(v0)
   0x4910d8 <__unpack_f+168>:   lw      v0,8(s8)
   0x4910dc <__unpack_f+172>:   sll     v0,v0,0x7
   0x4910e0 <__unpack_f+176>:   sw      v0,8(s8)
   0x4910e4 <__unpack_f+180>:   lw      v0,36(s8)
   0x4910e8 <__unpack_f+184>:   li      v1,3
   0x4910ec <__unpack_f+188>:   sw      v1,0(v0)
   0x4910f0 <__unpack_f+192>:   b       0x491118 <__unpack_f+232>
   0x4910f4 <__unpack_f+196>:   nop
   0x4910f8 <__unpack_f+200>:   lw      v0,8(s8)
   0x4910fc <__unpack_f+204>:   sll     v0,v0,0x1
   0x491100 <__unpack_f+208>:   sw      v0,8(s8)
   0x491104 <__unpack_f+212>:   lw      v0,36(s8)
   0x491108 <__unpack_f+216>:   lw      v0,8(v0)
   0x49110c <__unpack_f+220>:   addiu   v1,v0,-1
   0x491110 <__unpack_f+224>:   lw      v0,36(s8)
   0x491114 <__unpack_f+228>:   sw      v1,8(v0)
   0x491118 <__unpack_f+232>:   lw      v1,8(s8)
   0x49111c <__unpack_f+236>:   lui     v0,0x4000
   0x491120 <__unpack_f+240>:   sltu    v0,v1,v0
   0x491124 <__unpack_f+244>:   bnez    v0,0x4910f8 <__unpack_f+200>
   0x491128 <__unpack_f+248>:   nop
   0x49112c <__unpack_f+252>:   lw      v0,36(s8)
   0x491130 <__unpack_f+256>:   lw      v1,8(s8)
   0x491134 <__unpack_f+260>:   sw      v1,12(v0)
   0x491138 <__unpack_f+264>:   b       0x4911f0 <__unpack_f+448>
   0x49113c <__unpack_f+268>:   nop
   0x491140 <__unpack_f+272>:   lw      v0,12(s8)
   0x491144 <__unpack_f+276>:   xori    v0,v0,0xff
   0x491148 <__unpack_f+280>:   sltiu   v0,v0,1
   0x49114c <__unpack_f+284>:   andi    v0,v0,0xff
   0x491150 <__unpack_f+288>:   beqz    v0,0x4911bc <__unpack_f+396>
   0x491154 <__unpack_f+292>:   nop
   0x491158 <__unpack_f+296>:   lw      v0,8(s8)
   0x49115c <__unpack_f+300>:   bnez    v0,0x491178 <__unpack_f+328>
   0x491160 <__unpack_f+304>:   nop
   0x491164 <__unpack_f+308>:   lw      v0,36(s8)
   0x491168 <__unpack_f+312>:   li      v1,4
   0x49116c <__unpack_f+316>:   sw      v1,0(v0)
   0x491170 <__unpack_f+320>:   b       0x4911f0 <__unpack_f+448>
   0x491174 <__unpack_f+324>:   nop
   0x491178 <__unpack_f+328>:   lw      v1,8(s8)
   0x49117c <__unpack_f+332>:   lui     v0,0x10
   0x491180 <__unpack_f+336>:   and     v0,v1,v0
   0x491184 <__unpack_f+340>:   bnez    v0,0x4911a0 <__unpack_f+368>
   0x491188 <__unpack_f+344>:   nop
   0x49118c <__unpack_f+348>:   lw      v0,36(s8)
   0x491190 <__unpack_f+352>:   li      v1,1
   0x491194 <__unpack_f+356>:   sw      v1,0(v0)
   0x491198 <__unpack_f+360>:   b       0x4911a8 <__unpack_f+376>
   0x49119c <__unpack_f+364>:   nop
   0x4911a0 <__unpack_f+368>:   lw      v0,36(s8)
   0x4911a4 <__unpack_f+372>:   sw      zero,0(v0)
   0x4911a8 <__unpack_f+376>:   lw      v0,36(s8)
   0x4911ac <__unpack_f+380>:   lw      v1,8(s8)
   0x4911b0 <__unpack_f+384>:   sw      v1,12(v0)
   0x4911b4 <__unpack_f+388>:   b       0x4911f0 <__unpack_f+448>
   0x4911b8 <__unpack_f+392>:   nop
   0x4911bc <__unpack_f+396>:   lw      v0,12(s8)
   0x4911c0 <__unpack_f+400>:   addiu   v1,v0,-127
   0x4911c4 <__unpack_f+404>:   lw      v0,36(s8)
   0x4911c8 <__unpack_f+408>:   sw      v1,8(v0)
   0x4911cc <__unpack_f+412>:   lw      v0,36(s8)
   0x4911d0 <__unpack_f+416>:   li      v1,3
   0x4911d4 <__unpack_f+420>:   sw      v1,0(v0)
   0x4911d8 <__unpack_f+424>:   lw      v0,8(s8)
   0x4911dc <__unpack_f+428>:   sll     v1,v0,0x7
   0x4911e0 <__unpack_f+432>:   lui     v0,0x4000
   0x4911e4 <__unpack_f+436>:   or      v1,v1,v0
   0x4911e8 <__unpack_f+440>:   lw      v0,36(s8)
   0x4911ec <__unpack_f+444>:   sw      v1,12(v0)
   0x4911f0 <__unpack_f+448>:   move    sp,s8
   0x4911f4 <__unpack_f+452>:   lw      s8,28(sp)
   0x4911f8 <__unpack_f+456>:   addiu   sp,sp,32
   0x4911fc <__unpack_f+460>:   jr      ra
   0x491200 <__unpack_f+464>:   nop
   0x491204:    nop
   0x491208:    nop
   0x49120c:    nop
   0x491210 <__extendsfdf2>:    lui     gp,0x3
...
(gdb) x/64i __fpcmp_parts_f
   0x2b3d35c8 <__fpcmp_parts_f>:        lui     gp,0x2
   0x2b3d35cc <__fpcmp_parts_f+4>:      addiu   gp,gp,26408
   0x2b3d35d0 <__fpcmp_parts_f+8>:      addu    gp,gp,t9
   0x2b3d35d4 <__fpcmp_parts_f+12>:     addiu   sp,sp,-32
   0x2b3d35d8 <__fpcmp_parts_f+16>:     sw      ra,28(sp)
   0x2b3d35dc <__fpcmp_parts_f+20>:     sw      s8,24(sp)
   0x2b3d35e0 <__fpcmp_parts_f+24>:     move    s8,sp
   0x2b3d35e4 <__fpcmp_parts_f+28>:     sw      gp,16(sp)
   0x2b3d35e8 <__fpcmp_parts_f+32>:     sw      a0,32(s8)
   0x2b3d35ec <__fpcmp_parts_f+36>:     sw      a1,36(s8)
   0x2b3d35f0 <__fpcmp_parts_f+40>:     lw      a0,32(s8)
   0x2b3d35f4 <__fpcmp_parts_f+44>:     lw      v0,-32720(gp)
   0x2b3d35f8 <__fpcmp_parts_f+48>:     addiu   v0,v0,9456
   0x2b3d35fc <__fpcmp_parts_f+52>:     move    t9,v0
   0x2b3d3600 <__fpcmp_parts_f+56>:     jalr    t9
   0x2b3d3604 <__fpcmp_parts_f+60>:     nop
   0x2b3d3608 <__fpcmp_parts_f+64>:     lw      gp,16(s8)
   0x2b3d360c <__fpcmp_parts_f+68>:     bnez    v0,0x2b3d3638 <__fpcmp_parts_f+112>
   0x2b3d3610 <__fpcmp_parts_f+72>:     nop
   0x2b3d3614 <__fpcmp_parts_f+76>:     lw      a0,36(s8)
   0x2b3d3618 <__fpcmp_parts_f+80>:     lw      v0,-32720(gp)
   0x2b3d361c <__fpcmp_parts_f+84>:     addiu   v0,v0,9456
   0x2b3d3620 <__fpcmp_parts_f+88>:     move    t9,v0
   0x2b3d3624 <__fpcmp_parts_f+92>:     jalr    t9
   0x2b3d3628 <__fpcmp_parts_f+96>:     nop
   0x2b3d362c <__fpcmp_parts_f+100>:    lw      gp,16(s8)
   0x2b3d3630 <__fpcmp_parts_f+104>:    beqz    v0,0x2b3d3644 <__fpcmp_parts_f+124>
   0x2b3d3634 <__fpcmp_parts_f+108>:    nop
   0x2b3d3638 <__fpcmp_parts_f+112>:    li      v0,1
   0x2b3d363c <__fpcmp_parts_f+116>:    b       0x2b3d3980 <__fpcmp_parts_f+952>
   0x2b3d3640 <__fpcmp_parts_f+120>:    nop
   0x2b3d3644 <__fpcmp_parts_f+124>:    lw      a0,32(s8)
   0x2b3d3648 <__fpcmp_parts_f+128>:    lw      v0,-32720(gp)
   0x2b3d364c <__fpcmp_parts_f+132>:    addiu   v0,v0,9560
   0x2b3d3650 <__fpcmp_parts_f+136>:    move    t9,v0
   0x2b3d3654 <__fpcmp_parts_f+140>:    jalr    t9
   0x2b3d3658 <__fpcmp_parts_f+144>:    nop
   0x2b3d365c <__fpcmp_parts_f+148>:    lw      gp,16(s8)
   0x2b3d3660 <__fpcmp_parts_f+152>:    beqz    v0,0x2b3d36a8 <__fpcmp_parts_f+224>
   0x2b3d3664 <__fpcmp_parts_f+156>:    nop
   0x2b3d3668 <__fpcmp_parts_f+160>:    lw      a0,36(s8)
   0x2b3d366c <__fpcmp_parts_f+164>:    lw      v0,-32720(gp)
   0x2b3d3670 <__fpcmp_parts_f+168>:    addiu   v0,v0,9560
   0x2b3d3674 <__fpcmp_parts_f+172>:    move    t9,v0
   0x2b3d3678 <__fpcmp_parts_f+176>:    jalr    t9
   0x2b3d367c <__fpcmp_parts_f+180>:    nop
   0x2b3d3680 <__fpcmp_parts_f+184>:    lw      gp,16(s8)
   0x2b3d3684 <__fpcmp_parts_f+188>:    beqz    v0,0x2b3d36a8 <__fpcmp_parts_f+224>
   0x2b3d3688 <__fpcmp_parts_f+192>:    nop
   0x2b3d368c <__fpcmp_parts_f+196>:    lw      v0,36(s8)
   0x2b3d3690 <__fpcmp_parts_f+200>:    lw      v1,4(v0)
   0x2b3d3694 <__fpcmp_parts_f+204>:    lw      v0,32(s8)
   0x2b3d3698 <__fpcmp_parts_f+208>:    lw      v0,4(v0)
   0x2b3d369c <__fpcmp_parts_f+212>:    subu    v0,v1,v0
   0x2b3d36a0 <__fpcmp_parts_f+216>:    b       0x2b3d3980 <__fpcmp_parts_f+952>
   0x2b3d36a4 <__fpcmp_parts_f+220>:    nop
   0x2b3d36a8 <__fpcmp_parts_f+224>:    lw      a0,32(s8)
   0x2b3d36ac <__fpcmp_parts_f+228>:    lw      v0,-32720(gp)
   0x2b3d36b0 <__fpcmp_parts_f+232>:    addiu   v0,v0,9560
   0x2b3d36b4 <__fpcmp_parts_f+236>:    move    t9,v0
   0x2b3d36b8 <__fpcmp_parts_f+240>:    jalr    t9
   0x2b3d36bc <__fpcmp_parts_f+244>:    nop
   0x2b3d36c0 <__fpcmp_parts_f+248>:    lw      gp,16(s8)
   0x2b3d36c4 <__fpcmp_parts_f+252>:    beqz    v0,0x2b3d36f4 <__fpcmp_parts_f+300>
   0x2b3d36c8 <__fpcmp_parts_f+256>:    nop
(gdb) p/x $ra
$1 = 0x2b03e494

 

[RalfFriedl]

Die Funktionen __gtsf2 und __nesf2 sind fast identisch aufgebaut, sie vergleichen zwei Fließkommazahlen auf größer als (GT) oder ungleich (NE). Dazu wird zweimal die Funktion __unpack_f aufgerufen, für jede Zahl einmal, und dann __fpcmp_parts_f. DIe Funktionen __gtsf2 und __nesf2 sind entweder länger als bei mir oder ich habe nicht richtig gerechnet, jedenfalls sind es mehr als die 40 Anweisungen, die ich genannt hatte. Die anderen Funktionen sind auch länger und daher hier nicht vollständig.
Die Adresse von __unpack_f befinden sich in -32680(gp) oder (gp-32680), ("lw v0,-32680(gp)"), die Adresse von __fpcmp_parts_f in -32696(gp). Die Funktionen __unpack_f und __fpcmp_parts_f rufen jeweils keine andere Funktion mehr auf.
In $ra steht, zu welcher Adresse die aktuelle Funktion zurück kehren sollte (Return Address). Das liegt in keiner der hier angezeigten Funktionen. Es fällt aber auf, dass __unpack_f bei 0x491030 anfängt, während die anderen drei Funktionen ab 0x2b03e398 liegen. Vermutlich ist __unpack_f im Hauptprogramm und die anderen drei Funktionen in libgcc_s (info files). Vermutlich gibt es auch in libgcc_s die Funktion __unpack_f, aber gdb zeigt eben diese an. Versuche, herauszufinden, wohin 0x2b03e494 gehört (x/40i 0x2b03e494).
Du kannst außerdem einen Breakpoint auf __gtsf2 und/oder __nesf2 setzen. Dann kannst Du sehen, wohin die Funktionsaufrufe gehen. (x/x $gp-32680 , x/x $gp-32606). Dabei bekommst Du jeweils sowohl die Adresse als auch den Inhalt angezeigt. Wenn Du nachher die Breakpoints deaktivierst und das Programm weiter laufen lässt, kannst Du nachher überprüfen, ob sich diese Werte geändert haben. Als Adresse nimmst Du aber nicht mehr $gp-32680, sondern den Wert,der vorher ausgerechnet wurde. Wenn zum Beispiel dies angezeigt wird, dann gibt Du beim nächsten Mal ein "x/x 0x12345678". Außerdem "x/60i 0x80402010", um anzuzeigen, welche Funktion sich hinter der Adresse verbirgt. Wenn der Inhalt sich geändert hat, ist etwas schief gelaufen.

x/x $gp-32680
0x12345678 <xyz>: 0x80402010

Nachdem das Programm beim ersten Breakpoint stehen geblieben ist, kannst Du mit ni (Next Instruction) die Funktion Schritt für Schritt durchgehen. Wenn schon beim ersten Mal etwas schief geht, dann ist etwas sehr verkehrt. Ich halte es für wahrscheinlicher, dass die Funktion beim ersten mal (und auch später) noch durchläuft und erst irgendwann im Laufe der Programmausführung ein Wert überschrieben wird, der bewirkt, dass nicht die richtige Funktion aufgerufen wird.

 

[kmeleon]

Hallo Ralf!

Sorry für die Verzögerung, aber ich bin hier leider nicht weiter gekommen. Ich kann nachvollziehen, was Du in Deiner Nachrichten oben beschrieben hast. Ich habe oben die Funktionen so weit verlängert, dass man sehen kann, wohin 0x2b03e494 zeigt: Die Stelle gehört immer noch zur Funktion __nesf2. Wird der davorliegende nop-Befehl einfach so übersprungen? Da fehlt mir einfach die Erfahrung mit gdb und den mips-Prozessoren. Ich habe auch mal versucht einen Breakpoint zu setzen. Der wird auch angesprungen

Breakpoint 1, __nesf2 (arg_a=0.100000024, arg_b=0)

aber die Werte von -32680(gp) verändern sich im Betrieb nicht. Steppe ich nach Erreichen des Breakpoints weiter, erreiche ich irgendwann den Punkt, wo gdb den nächsten Breakpoint nicht mehr setzen (vermutlich hängt das mit dem SegFault zusammen)

(gdb) print/x $pc
$23 = 0x2b03e474
(gdb) print/x $ra
$24 = 0x2b03e45c
(gdb) step
0x2b03e48c in __nesf2 (arg_a=0.100000024, arg_b=0)
    at /home/freetz/fritzbox/freetz/freetz-devel/source/toolchain-mipsel_gcc-4.7.3_uClibc-0.9.32.1/gcc-4.7.3/libgcc/fp-bit.c:1221
1221    in /home/freetz/fritzbox/freetz/freetz-devel/source/toolchain-mipsel_gcc-4.7.3_uClibc-0.9.32.1/gcc-4.7.3/libgcc/fp-bit.c
Could not insert single-step breakpoint at 0x0
(gdb)

(gdb) x/x $gp-32680
0x2b05cfa8:     0x2b03e150
(gdb) x/x $gp-32696
0x2b05cf98:     0x2b03a000
(gdb) x/x 0x2b05cf98
0x2b05cf98:     0x2b03a000
(gdb) x/x 0x2b05cfa8
0x2b05cfa8:     0x2b03e150

Hier komme ich dann leider nicht mehr weiter :-(. Ich bin glücklich, dass es läuft und kann nur hoffen, dass mir die versch. uclibc-Versionen nicht irgendwann das svn-Repository zerschießen. Bisher läuft die Fritzbox seit einer Woche absolut ohne Probleme.

 

[RalfFriedl]

   0x2b03e474 <__nesf2+220>:    addiu   v0,s8,40
   0x2b03e478 <__nesf2+224>:    addiu   v1,s8,24
   0x2b03e47c <__nesf2+228>:    move    a0,v1
   0x2b03e480 <__nesf2+232>:    move    a1,v0
   0x2b03e484 <__nesf2+236>:    lw      v0,-31684(gp)
   0x2b03e488 <__nesf2+240>:    move    t9,v0
   0x2b03e48c <__nesf2+244>:    jalr    t9
   0x2b03e490 <__nesf2+248>:    nop
   0x2b03e494 <__nesf2+252>:    lw      gp,16(s8)

Das ist ein Ausschnitt aus der Funktion __nesf2 in der Shared Library, im Gegensatz zur gleichen Funktion im Hauptprogramm. Hier liegt der Eintrag für __fpcmp_parts_f an $gp-31684. Und $Ggp hat in der Library einen anderen Wert als im Hauptprogramm.

Du darfst an der Stelle nicht "step" verwenden, damit wird zu viel auf einmal ausgeführt. Verwende statt dessen "si". Wenn Du bei 0x2b03e48c angekommen bist, schaue Dir den Wert von $t9 an, ob der tatsächlich auf die Funktion __fpcmp_parts_f zeigt.