[Problem] gdb 7.8 aus dem trunk funktioniert auf 7490 wohl nicht

[PeterPawn]

Hi,
hat irgendjemand den gdb 7.8 auf der 7490 funktionsfähig im Einsatz ?

Bei mir wird nach dem Laden des gdb und des debuggee alles normal angezeigt, nach einem Start des debuggee bleiben dann auch zwei gdb-Threads im Status "traced" stehen (nach meiner Interpretation einer für die Behandlung des Breakpoint-Traps, der dann seinerseits irgendeinen Trap verursacht, den der zweite behandeln sollte und der kommt dann wg. irgendeiner gelockten Resource nicht richtig zum Zug, weil er auf deren Freigabe durch den ersten wartet, klassisches Deadlock), ohne daß der gdb (dessen (Konsolen?-)Thread ist "runnable") irgendeine Reaktion beim Erreichen des ersten Breakpoints zeigt. Es bleibt nur das sehr unsanfte Killen des gdb mit sighalt (sigterm reicht nicht, da er dann wohl auf die Childs wartet), dann stirbt der debuggee auch ohne probleme. Das sieht für mich irgendwie nach Deadlock o.ä. aus, ausgelöst von einem nicht richtig behandelten Trace-Trap im debuggee (den der gdb ja zu verantworten hat), da der gdb-Primärthread ja immer noch arbeiten kann.

Ich würde ja glatt den gdb auf der Box debuggen, wenn ich denn einen funktionsfähigen gdb auf der Box hätte.

root@FB7490:/var/media/ftp $ gdb --args leds -l
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from leds...done.
(gdb) start
Temporary breakpoint 1 at 0x401f48: file leds.c, line 465.
Starting program: /var/media/ftp/leds -l
^Z

Das Ctrl-Z wirkt schon nicht mehr, da ist kein TTY-read aktiv (auf ein extern ausgelöstes TSTP-Signal reagiert der gdb aber ganz normal und geht ins "suspend"). Die Prozessliste sieht dann (auszugsweise und ohne suspend für den gdb) so aus:

S     0  7749  2264  1512   280 0:0   22:44 00:00:00 {busybox} sleep 10
R     0  7750  2207  1516   392 pts1  22:44 00:00:00 {busybox} ps l
R     0 29285  2065  7724  4896 pts0  22:18 00:26:01 gdb --args leds -l
T     0 29360 29285   144    20 pts0  22:18 00:00:00 /var/media/ftp/leds -l
T     0 29361 29285  7724  2324 pts0  22:18 00:00:00 gdb --args leds -l
T     0 29362 29361  7724  2208 pts0  22:18 00:00:00 gdb --args leds -l
S     0 30050  1969  1756   716 0:0   21:03 00:00:10 /var/media/ftp/bin/dropbear

Ich gebe aber zu, daß es kein Freetz-Image ist, nur die Binaries wurden mit dem gdb-Paket aus dem Trunk erstellt (allerdings mit angepaßtem lib-Verzeichnis) und auf die Box kopiert, aber inkl. libelf.so (weitere Abhängigkeiten gibt es für den gdb offenbar nicht) ... und ich sehe einfach keinen Fehler. Bei einem Vx180 (7390) klappt dieselbe Vorgehensweise problemlos, natürlich mit den passenden Binaries und Libs.

Der debuggee ist mit der Freetz-Toolchain (gcc 4.8.3, libc 0.9.33.2) und -ggdb und -O0 kompiliert, die Symbole sind auch da und die Zuordnung zum Source klappt (sieht man ja auch in der gdb-Ausgabe).

Das gesamte System dreht am Breakpoint irgendwie durch, nach "echo STD_PRINTK >/dev/debug" (also nach Umschaltung auf "normales" printk) wird - nach meiner Interpretation - der vergebliche Versuch des Aktivierens eines Threads protokolliert (leider nicht welches, ich tippe eben auf den Breakpoint-Handler):

[13681.190000] ------------[ cut here ]------------
[13681.190000] WARNING: at kernel/sched.c:2624 wake_up_process+0x48/0x60()
[13681.190000] Modules linked in: ifx_ppa_mini_qos(P) ifx_ppa_mini_sessions ifxmips_ppa_hal_vr9_e5 userman_mod(P) ulpcmlink(P) sch_sfq sch_llq sch_tbf atd(P) fwd(P) athlogger hif_gmac adf(P) aae(P) kspeedtest usb_storage sd_mod scsi_mod kdsldmod(P) ifxmips_ppa_datapath_vr9_e5 dsl_vr9 mei_vr9 xhci usbcore dect_io(P) avm_dect(P) capi_codec(P) isdn_fbox_fon5(P) pcmlink(P) Piglet_noemif(P) rtc_avm led_modul_Fritz_Box_HW185(P)
[13681.190000] Call Trace:
[13681.190000] [<800296a8>] dump_stack+0x8/0x40
[13681.190000] [<80060524>] warn_slowpath_common+0x84/0xc0
[13681.190000] [<80053f88>] wake_up_process+0x48/0x60
[13681.190000] [<80025a1c>] arch_ptrace+0x29c/0xa20
[13681.190000] [<8006fd98>] sys_ptrace+0xb8/0x340
[13681.190000] [<800059dc>] stack_done+0x20/0x40
[13681.190000]
[13681.190000] ---[ end trace aa5e5922aed8431d ]---

in unendlicher Schleife.

Eigentlich kann es auch nicht wirklich an meinem debuggee liegen, denn es sieht bei jedem anderen Binary ebenso trübe aus mit dem Debuggen, selbst bei blkid o.ä.

Irgendwelche Kommentare/Ideen/Erfahrungsberichte ?
Hat schon mal jemand den gdb 7.8 auf einer 7490 getestet ? Das Testen mit printf-Ausgaben ist etwas sehr mühsam.

 

[er13]

@Peter: könntest Du bitte testen, ob sich nach r12738 etwas geändert/gebessert hat? Mein rudimentärer Test zeigt, dass gdb auf einer gefreetz'ten Box läuft.

In 7.8.1 wurden u.a. diese zwei Bug behoben: PR 17247, PR 17347.

 

[PeterPawn]

Nein, tut mir leid, der Fehler ist nach wie vor derselbe.

root@FB7490:~ $ gdb --args leds -l
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from leds...done.
(gdb) break getLedEntries
Breakpoint 1 at 0x40159c: file leds.c, line 298.
(gdb) start
Temporary breakpoint 2 at 0x401f88: file leds.c, line 465.
Starting program: /var/media/ftp/root/leds -l
^Z
Killed
root@FB7490:~ $
root@FB7490:~ $ Parameters: -l
Parse pointer at 0x0x414070, value 0x00000038
Returned value 0x0x806ffad0
avm_current_hw_config found at 0x0x806ffad0
Map 1320 bytes at real address 0x0x6ffad0

gdb hängt am Breakpoint (Threads wie oben beschrieben) und muß gekillt werden.

Mein rudimentärer Test zeigt, dass gdb auf einer gefreetz'ten Box läuft.

Da das natürlich auch daran liegen kann, daß ich kein komplettes Freetz-Image verwendet habe (die Bedingungen sollten ja konstant sein), wäre die entscheidende Frage, ob der rudimentäre Test Breakpoints (Symbol oder Adresse ist egal, geht bei mir beides nicht) beinhaltete und am Ende auch nicht nur das Setzen eines solchen, sondern die Behandlung des zugehörigen Traps.

Ich habe auch das Senden von SIGCONT getestet, wie es in einem der Threads zu den Bugs als möglicher Workaround beschrieben ist ... keine Reaktion meines Debuggers.

Ich gehe wieder auf den 6.8 zurück und schaue dort mal, ob es geht ... dazu bin ich bisher noch gar nicht gekommen.

 

[er13]

Hi,

ich habe Breakpoints an zwei Symbolen gesetzt, an beiden hat GDB angehalten ohne dabei hängen zu bleiben, war dabei weiterhin ansprechbar, hat auf alle meine Befehle entsprechend meinen Erwartungen reagiert, ich konnte "durchsteppen", es weiter bis zum nächsten Breakpoint laufen lassen, usw.

Das einzige - mein Test erfolgte auf einer 7170 (0.9.33.x-non-NPTL). Um rauszufinden, ob NPTL relevant ist, muss ich es noch auf meiner 7490 testen.

Hat es denn früher schon mal bei Dir funktioniert? Auch in der Variante "original firmware mit freetz-gdb"? Wenn ja, welche Version war die letzte, wo es noch ging. Ich könnte den Support für diese wiederherstellen bis die Probleme mit 7.8.x behoben sind.

Grüße,
Gene

 

[PeterPawn]

Das einzige - mein Test erfolgte auf einer 7170 (0.9.33.x-non-NPTL). Um rauszufinden, ob NPTL relevant ist, muss ich es noch auf meiner 7490 testen.

Auf der 7390 läuft das vollkommen problemlos ... das fand ich ja auch etwas komisch, da der Unterschied nicht so riesig sein dürfte (imho kleiner als bei 7170<->7490).

Hat es denn früher schon mal bei Dir funktioniert? Auch in der Variante "original firmware mit freetz-gdb"?

7390 problemlos, 7490 noch nie. Daher hatte/habe ich auch nicht auf einen generellen gdb-Fehler getippt und war von dem Bugfix in den offiziellen Quellen eher überrascht.

Ich probiere es bei der nächstbesten Gelegenheit mal mit der 6.8 ... vielleicht klappt es damit. Ein Rollback im Trunk halte ich nicht für sinnvoll - außer es kommen andere und wollen auch unbedingt mit dem gdb auf der 7490 "spielen". Die anderen Möglichkeiten (nur die Stub auf der Box und den Debugger auf einem anderen Host) habe ich auch nicht probiert, vielleicht klappt da ja eine (wenn der Thread zur Anzeige am Breakpoint außerhalb des gdb-Hauptprozesses liegt).