Home printf-Hello-world Debug-Session printf-Hello-world Debug-Session Liste der Makes
 

8.3.1 Benutzung des GDB-Servers

Zuerst eine Debug-Fassung von unserm Testprogramm erstellen! Dazu erweitere ich in meinem Makefile den gcc-Aufruf um die Option "-g". Nach Aufruf von "make testprg" entsteht:

andreas@gericom:~/Development/driver> ls -lt
insgesamt 789
-rwxr--r--  1 andreas users  21140 2008-04-13 11:58 readqadc-2_1
-rwxr-xr-x  1 andreas users  86158 2008-04-13 11:58 readqadc-2_1.gdb
-rw-r--r--  1 andreas users    938 2008-04-13 11:57 Makefile
-rw-r--r--  1 andreas users   2239 2008-04-13 11:55 readqadc-2_1.c
-rw-r--r--  1 andreas users   2218 2008-04-13 11:54 readqadc-2_1.c~
-rw-r--r--  1 andreas users  68573 2008-04-13 11:32 myreadme-driver_iso.txt
-rw-r--r--  1 andreas users  68541 2008-04-13 11:31 myreadme-driver_iso.txt~
drwxr-xr-x  2 andreas users   3552 2008-04-12 16:24 html
drwxr-xr-x  4 andreas users    176 2008-04-10 14:49 von_Psion

Der Start auf dem COBRA-Board:

/usr> insmod qadc-2_0.o
Using qadc-2_0.o
QADC Driver 2.0
/usr> ls -l
-rw-r--r--    1 1000     100          4337 Mar  4  2005 boot_linux.cap
-rw-r--r--    1 1000     100        135796 Jun 29  2005 hello-4.o
drwxr-xr-x    2 1000     100           432 Mar  4  2005 led_test_cobra5282-20040324
-r-xr-xr-x    1 1000     100          3028 Mar  4  2005 led_test_cobra5282-20040324.tar.gz
-rw-r--r--    1 1000     100        139752 Aug 28  2005 qadc-1_0.o
-rw-r--r--    1 1000     100        139752 Nov  1  2005 qadc-1_1.o
-rw-r--r--    1 1000     100        138540 Mar 28  2008 qadc-2_0.o
-rw-r--r--    1 1000     100        138572 Apr 10  2008 qadc-2_1.o
-rwxrwxrwx    1 0        0           20740 Jul  5  2005 readqadc-1_0
-rwxrwxrwx    1 0        0           20888 Nov  1  2005 readqadc-1_1
-rwxrwxrwx    1 0        0           21116 Mar 28  2008 readqadc-2_0
-rwxrwxrwx    1 0        0           21140 Apr 13  2008 readqadc-2_1
/usr> gdbserver 192.168.178.27:2345 readqadc-2_1
Process readqadc-2_1 created; pid = 30
code at 0x690040 - 0x693dc0, data at 0x693dc4

sieht erstmal ganz anständig aus.

Jetzt Start des Host:

andreas@gericom:~/Development/driver> gdb readqadc-2_1.gdb
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
Couldn't establish connection to remote target
Remote communication error: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt.
(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
Couldn't establish connection to remote target
Reply contains invalid hex digit 59
(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
Couldn't establish connection to remote target
Reply contains invalid hex digit 59
(gdb) target remote 192.168.178.11:2345
192.168.178.11:2345: Verbindungsaufbau abgelehnt.
(gdb)

Hier noch das entsprechende Bild auf der Target-Seite:

/usr> ls -l
-rw-r--r--    1 1000     100          4337 Mar  4  2005 boot_linux.cap
-rw-r--r--    1 1000     100        135796 Jun 29  2005 hello-4.o
drwxr-xr-x    2 1000     100           432 Mar  4  2005 led_test_cobra5282-20040324
-r-xr-xr-x    1 1000     100          3028 Mar  4  2005 led_test_cobra5282-20040324.tar.gz
-rw-r--r--    1 1000     100        139752 Aug 28  2005 qadc-1_0.o
-rw-r--r--    1 1000     100        139752 Nov  1  2005 qadc-1_1.o
-rw-r--r--    1 1000     100        138540 Mar 28  2008 qadc-2_0.o
-rw-r--r--    1 1000     100        138572 Apr 10  2008 qadc-2_1.o
-rwxrwxrwx    1 0        0           20740 Jul  5  2005 readqadc-1_0
-rwxrwxrwx    1 0        0           20888 Nov  1  2005 readqadc-1_1
-rwxrwxrwx    1 0        0           21116 Mar 28  2008 readqadc-2_0
-rwxrwxrwx    1 0        0           21140 Apr 13  2008 readqadc-2_1
-rwxrwxrwx    1 0        0           86158 Apr 13  2008 readqadc-2_1.gdb
/usr> gdbserver 192.168.178.27:2345 readqadc-2_1.gdb
BINFMT_FLAT: bad magic/rev (0x1020100, need 0x4)
BINFMT_FLAT: bad magic/rev (0x1020100, need 0x4)
Cannot exec readqadc-2_1.gdb
Process readqadc-2_1.gdb created; pid = 33

Child exited with retcode = 7f
code at 0xffffffff - 0xffffffff, data at 0xffffffff

Remote debugging using 192.168.178.27:2345

Child exited with status 21
GDBserver exiting
/usr> /usr> gdbserver 192.168.178.27:2345 readqadc-2_1
Process readqadc-2_1 created; pid = 35
code at 0x650040 - 0x653dc0, data at 0x653dc4
Remote debugging using 192.168.178.27:2345
readchar: Got EOF
Remote side has terminated connection.  GDBserver will reopen the connection.
Remote debugging using 192.168.178.27:2345
readchar: Got EOF
Remote side has terminated connection.  GDBserver will reopen the connection.
pid 34: failed 2
/usr>

Man sieht erstmal, daß auf der Hostseite die gdb-Fassung gestartet werden muß Im Target dagegen die pure Run-Fassung ohne "*.gdb".

Zwei Versuche startete ich, eine Verbindung vom Host zum Target aufzubauen. Auf der Hostseite wurde gemeldet:

(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
Couldn't establish connection to remote target
Reply contains invalid hex digit 59
(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
Couldn't establish connection to remote target
Reply contains invalid hex digit 59

Auf der Targetseite wurde dann entsprechend zweimal gemeldet:

Remote debugging using 192.168.178.27:2345
readchar: Got EOF
Remote side has terminated connection.  GDBserver will reopen the connection.
Remote debugging using 192.168.178.27:2345
readchar: Got EOF
Remote side has terminated connection.  GDBserver will reopen the connection.

Daraufhin unterbrach ich den Target-Server gewaltsam mit CTRL-C:

pid 34: failed 2
/usr>

Ein hierauf neuer Versuch vom Host wurde dann stattdessen so beantwortet:

(gdb) target remote 192.168.178.11:2345
192.168.178.11:2345: Verbindungsaufbau abgelehnt.
(gdb)

Also reden die zwei Rechner Host und Target durchaus miteinander. Nur scheint das Protokoll nicht wirklich identisch zu sein.

Per Google fand ich erstmal:

[PDF] Remote Debbuging mittels GNU Remote Debbuging mittels GNU GDB

Dateiformat: PDF/Adobe Acrobat - HTML-Version
kleines Programm, der GDBServer,. zur Ausführung gebracht werden ... Das Remote Serial Protocol arbeitet. auf Basis von ASCII-Zeichen und ist ...
www.informatik.fh-wiesbaden.de/ ~linn/vpdv03/tillinger_gleichmann/remote_debug.pdf - Ähnliche Seiten

welches ich unter: file:/home/andreas/Development/Literatur/remote_debug.pdf

ablegte. Hinweis darin auf "Remote Serial Protocol (RSP)". Es wird erklärt, wie das Protokoll funktioniert!

Desweiteren fand ich:

[PDF] Embedding with GNU: the gdb Remote Serial Protocol, 11/99

Dateiformat: PDF/Adobe Acrobat - HTML-Version
basic Remote Serial Protocol messages. is all you need to get your embedded. system talking to gdb. The protocol defined. The GDB Remote Serial Protocol ...
www.huihoo.org/mirrors/pub/ embed/document/debugger/ew_GDB_RSP.pdf -

welches ich ebenfalls unter: file:/home/andreas/Development/Literatur/

ablegte. Dort steht weit mehr zum "Remote Serial Protocol (RSP)".

Unter anderem wird der Tipp gegeben, die Kommunikation zu loggen. Hierzu diene ein File ".gdbinit" mit dem Inhalt:

set debug remote 1
set remotelogfile gdb_logfile

Damit erweiterte sich die Ausgabe zu:

andreas@gericom:~/Development/driver> gdb readqadc-2_1.gdb
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received: Text=6e0040;Data=6e0044;Bss=6e0044;
Sending packet: $?#3f...Ack
Packet received: T0511:006e0048;0e:0076ff2c;0f:006e7f84;
Couldn't establish connection to remote target
Reply contains invalid hex digit 59
(gdb)

Und das so entstandene Logfile:

andreas@gericom:~/Development/driver> cat gdb_logfile

w +$Hc-1#09
r +$OK#9a
w +$qC#b4
r +$#00
w +$qOffsets#4b
r +$Text=6e0040;Data=6e0044;Bss=6e0044;#d4
w +$?#3f
r +$T0511:006e0048;0e:0076ff2c;0f:006e7f84;#9e
w +
End of log
andreas@gericom:~/Development/driver>

Der Satz:

This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

macht mich stutzig. Kann es sein, daß ich den GDB auf den Coldfire umkonfigurieren muß?

andreas@gericom:~/Development/driver> rpm -qf /lib/tls/libthread_db.so.1
glibc-2.3.3-97
andreas@gericom:~/Development/driver> whereis gdb
gdb: /usr/bin/gdb /usr/share/man/man1/gdb.1.gz
andreas@gericom:~/Development/driver> rpm -qf /usr/bin/gdb
gdb-6.1-1
andreas@gericom:~/Development/driver>

Die verantwortlichen Files stammen allerdings aus zwei verschiedenen Archiven.

andreas@gericom:~/Development/driver> rpm -ql gdb-6.1-1
/usr/bin/gdb
/usr/bin/gdbserver
/usr/bin/gdbtui
/usr/share/doc/packages/gdb
/usr/share/doc/packages/gdb/COPYING
/usr/share/doc/packages/gdb/COPYING.LIB
/usr/share/doc/packages/gdb/NEWS
/usr/share/doc/packages/gdb/README
/usr/share/info/annotate.info.gz
/usr/share/info/gdb.info-1.gz
/usr/share/info/gdb.info-2.gz
/usr/share/info/gdb.info-3.gz
/usr/share/info/gdb.info.gz
/usr/share/info/gdbint.info.gz
/usr/share/info/stabs.info.gz
/usr/share/man/man1/gdb.1.gz
/usr/share/man/man1/gdbserver.1.gz
/usr/share/man/man1/gdbtui.1.gz
andreas@gericom:~/Development/driver>

Die Suche nach dem Quellcode zum obigen RPM-Archiv gestaltet sich schon etwas mühsam. Unter:

ftp://bo.mirror.garr.it/pub/1/suse/discontinued/i386/9.1/suse/src/gdb-6.1-1.src.rpm

finde ich diesen dann schließlich und lege diesen unter:

andreas@gericom:~/Documents/rpm/installed> ls
automake-1.8.3-23.i586.rpm  kdiff3-0.9.86-3.i586.rpm         m4-1.4o-622.i586.rpm    udo-6.4.0-1.i386.rpm
gdb-6.1-1.src.rpm           kernel-source-2.6.4-52.i586.rpm  make-3.80-184.i586.rpm
andreas@gericom:~/Documents/rpm/installed> ls -l gdb-6.1-1.src.rpm
-rw-r--r--  1 andreas users 12552326 2008-04-24 11:30 gdb-6.1-1.src.rpm
andreas@gericom:~/Documents/rpm/installed>

ab. Allerdings gibt mir dieser Aufwand zu denken! Ich beschließe, doch den Umweg über den Umstieg der Weiterentwicklung unter SuSE 10.2 schrittweise anzupacken. Erster Schritt: unter SuSE 10.2 den dort aktuellen GDB anschauen und mit diesem einen Coldfire-Debugger hinbekommen.

Siehe auch Notiz hierzu unter:

andreas@gericom:~/Development/my_gdb>

Unter SuSE 10.2:

andreas@gericom:/suse9.1/home/andreas/Development/driver> rpm -qf /usr/bin/gdb
gdb-6.5-28

Beim Umstieg auf 10.2 und der Neu-Installation sehe ich:

andreas@gericom:/etc> cd /usr/local/bin
andreas@gericom:/usr/local/bin> ls -l
insgesamt 8196
-rwxr-xr-x  1 root users  415764 2001-12-19 12:36 elf2flt
-rwxr-xr-x  1 root users  237044 2001-12-19 12:36 flthdr
-rwxr-xr-x  1 root users   11476 2003-10-03 14:01 genromfs
-rwxr-xr-x  1 root root       94 2005-04-13 20:10 gimp
-rwxr-xr-x  1 root users 1442008 2003-10-03 14:01 m68k-bdm-elf-gdb
-rwxr-xr-x  1 root users  349660 2003-10-03 14:01 m68k-elf-addr2line
-rwxr-xr-x  2 root users  328176 2003-10-03 14:01 m68k-elf-ar
-rwxr-xr-x  2 root users  540728 2003-10-03 14:01 m68k-elf-as
-rwxr-xr-x  2 root users   78768 2003-10-03 14:01 m68k-elf-c++
-rwxr-xr-x  1 root users  348508 2003-10-03 14:01 m68k-elf-c++filt
-rwxr-xr-x  1 root users  615040 2003-10-03 14:01 m68k-elf-elf2flt
-rwxr-xr-x  1 root users  322236 2003-10-03 14:01 m68k-elf-flthdr
-rwxr-xr-x  2 root users   78768 2003-10-03 14:01 m68k-elf-g++
-rwxr-xr-x  1 root users   39788 2003-10-03 14:01 m68k-elf-gasp
-rwxr-xr-x  1 root users   76752 2003-10-03 14:01 m68k-elf-gcc
lrwxrwxrwx  1 root users      31 2005-02-24 18:51 m68k-elf-gdb -> /usr/local/bin/m68k-bdm-elf-gdb
-rwxr-xr-x  1 root users    4637 2003-10-03 14:01 m68k-elf-ld
-rwxr-xr-x  2 root users  403196 2003-10-03 14:01 m68k-elf-ld.real
-rwxr-xr-x  2 root users  359004 2003-10-03 14:01 m68k-elf-nm
-rwxr-xr-x  1 root users  476084 2003-10-03 14:01 m68k-elf-objcopy
-rwxr-xr-x  1 root users  528472 2003-10-03 14:01 m68k-elf-objdump
-rwxr-xr-x  1 root users   36832 2003-10-03 14:01 m68k-elf-protoize
-rwxr-xr-x  2 root users  328176 2003-10-03 14:01 m68k-elf-ranlib
-rwxr-xr-x  1 root users  184012 2003-10-03 14:01 m68k-elf-readelf
-rwxr-xr-x  1 root users  306920 2003-10-03 14:01 m68k-elf-size
-rwxr-xr-x  1 root users  307192 2003-10-03 14:01 m68k-elf-strings
-rwxr-xr-x  2 root users  476084 2003-10-03 14:01 m68k-elf-strip
-rwxr-xr-x  1 root users   31808 2003-10-03 14:01 m68k-elf-unprotoize
andreas@gericom:/usr/local/bin>

Damit rufe ich also:

andreas@gericom:~/Development/driver> m68k-elf-gdb readqadc-2_1.gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf"...
(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received: Text=6e0040;Data=6e0044;Bss=6e0044;
Sending packet: $?#3f...Ack
Packet received: T0511:006e0048;0e:0076ff2c;0f:006e7f84;
0x6e0048 in _start ()
(gdb) l
Sending packet: $m6e005c,2#5e...Ack
Packet received: 4e56
Sending packet: $m6e0060,2#2c...Ack
Packet received: 4eb9
10      #include <unistd.h>
11
12      static char device[]="/dev/qadc0";
13
14      void wait_in_sec(unsigned int seconds);
15      void read_one_value(void);
16
17      main()
18      {
19              printf("Hello!\n");
(gdb)

Das sieht also schon weit besser aus!

andreas@gericom:~/Development/driver> m68k-elf-gdb readqadc-2_1.gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf"...
(gdb) target remote 192.168.178.11:2345

192.168.178.11:2345: Bad file descriptor.
(gdb)
(gdb) target remote 192.168.178.11:2345
Remote debugging using 192.168.178.11:2345
0x6e0048 in _start ()
(gdb) l
10      #include <unistd.h>
11
12      static char device[]="/dev/qadc0";
13
14      void wait_in_sec(unsigned int seconds);
15      void read_one_value(void);
16
17      main()
18      {
19              printf("Hello!\n");
(gdb) i li 19
Line 19 of "readqadc-2_1.c" starts at address 0x6e0066 <main+10> and ends at 0x6e0074 <main+24>.
(gdb) i li 18
Line 18 of "readqadc-2_1.c" starts at address 0x6e005c <main> and ends at 0x6e0066 <main+10>.
(gdb) disas 0x6e0066 0x6e0074
Dump of assembler code from 0x6e0066 to 0x6e0074:
0x6e0066 <main+10>:     pea 0x6e3de4 <data_start+32>
0x6e006c <main+16>:     jsr 0x6e02ec <printf>
0x6e0072 <main+22>:     addql #4,%sp
End of assembler dump.
(gdb) i li *0x6e02ec
No line number information available for address 0x6e02ec <printf>
(gdb)

In dieser Sitzung erkennt man, daß leider kein Quellcode zur Funktion printf existiert.

Deshalb muß ich versuchen, irgendwie die hier:

andreas@gericom:~/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324 \
/uClibc/libc> find . -name "*" | xargs -n3 grep ' printf('
./inet/rpc/ruserpass.c:                               printf(_("out of memory"));
./inet/rpc/ruserpass.c:                             printf(_("out of memory"));
./misc/regex/regex.c:         printf("/%lx", (long int) *p++);
./misc/regex/regex.c:         printf("[:%lx:]", (long int) *p++);
./misc/regex/regex.c:         printf("%C", *p++);
./stdio/stdio.c:int printf(const char * __restrict format, ...);
./stdio/printf.c:int printf(const char * __restrict format, ...)
./stdio/old_vfprintf.c: *    1) printf("%c",0) returned 0 instead of 1.
andreas@gericom:~/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/uClibc/libc>

gefundene Datei /stdio/printf.c mit "-g" oder "-ggdb3" (siehe Beispiel im Buch Linux-UNIX-Programmierung S.1035) in die "libc" hinein zu übersetzen.

Im Makefile finden sich diese Passagen:

...
MSRC2= printf.c
MOBJ2=  vsnprintf.o vdprintf.o vasprintf.o vprintf.o vsprintf.o \
        fprintf.o  snprintf.o  dprintf.o  asprintf.o  printf.o  sprintf.o \
        _store_inttype.o _load_inttype.o
...
$(MOBJ2): $(MSRC2)
        $(CC) $(CFLAGS) -DL_$* $< -c -o $*.o
        $(STRIPTOOL) -x -R .note -R .comment $*.o
...

Ich sichere das Original-Makefile:

andreas@gericom:~/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/uClibc/libc/stdio> less Makefile
andreas@gericom:~/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/uClibc/libc/stdio> cp Makefile Makefile.orig

Und modifiziere es zu:

...
MSRC2= printf.c
MOBJ2=  vsnprintf.o vdprintf.o vasprintf.o vprintf.o vsprintf.o \
        fprintf.o  snprintf.o  dprintf.o  asprintf.o  printf.o  sprintf.o \
        _store_inttype.o _load_inttype.o
...
$(MOBJ2): $(MSRC2)
        $(CC) $(CFLAGS) -ggdb3 -DL_$* $< -c -o $*.o
#        $(STRIPTOOL) -x -R .note -R .comment $*.o
...

Allerdings nach Durchlauf des Make und Neuerzeugung von:

andreas@gericom:~/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/lib/uClibc/lib> ls -l
insgesamt 15979
-rw-r--r--  1 andreas users      992 2008-04-24 20:48 crt0.o
-rw-r--r--  1 andreas users      992 2008-04-24 20:48 crt1.o
-rw-r--r--  1 andreas users      751 2005-06-12 15:35 crti.o
-rw-r--r--  1 andreas users      751 2005-06-12 15:35 crtn.o
-rw-r--r--  1 andreas users 15108452 2008-04-24 20:48 libc.a
-rw-r--r--  1 andreas users    70262 2008-04-24 20:48 libcrypt.a
-rw-r--r--  1 andreas users  1034060 2008-04-24 20:48 libm.a
-rw-r--r--  1 andreas users     3064 2008-04-24 20:48 libnsl.a
-rw-r--r--  1 andreas users     3080 2008-04-24 20:48 libresolv.a
-rw-r--r--  1 andreas users   100248 2008-04-24 20:48 libutil.a
andreas@gericom:~/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/lib/uClibc/lib>

wird aber nichts am Ende-File "image.bin" geändert.

Im Make-Output-File findet sich dieser Ausschnitt:

for i in $dirs ; do  make -C $i || exit  ; done
make[2]: Leaving directory `/home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/vendors/senTec/COBRA5282'
make[1]: Leaving directory `/home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/user'
for dir in  lib user ; do [ ! -d $dir ] || make ARCH=m68knommu CROSS_COMPILE=m68k-elf- -C $dir romfs || exit 1 ; done
make[1]: Entering directory `/home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/lib'
for i in uClibc libnet libcrypt_old /home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/prop libg ; do \
        [ ! -d $i ] || make -C $i romfs || exit $? ; \
done
make[2]: Entering directory `/home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/uClibc'
make[2]: Leaving directory `/home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/uClibc'
make[2]: Entering directory `/home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/lib/libnet'
make[2]: Für das Ziel »romfs« ist nichts zu tun.
make[2]: Leaving directory `/home/andreas/Development/COBRA_rot/uClinux/uClinux-dist-20040218-cobra-20040324/lib/libnet'
out_test9.txt lines 619-658/1315 55%

Da ist offensichtlich für das Ziel "romfs" im Fall "uClibc" absolut nichts geschehen.

Es ist schleierhaft, warum überhaupt das "image.bin" so gut bzgl. des "printf" funktioniert.





Copyright © Andreas Birkert
Letzte Aktualisierung am 20. Dezember 2013
Home printf-Hello-world Debug-Session printf-Hello-world Debug-Session Liste der Makes