- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
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.
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:
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):
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.
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.
Code:
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
Code:
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/dropbearDer 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):
Code:
[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 ]---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.
