Portál AbcLinuxu, 6. června 2024 00:47
Vyšla nová verze debuggeru GDB, 6.8. Lze jej zkompilovat (do jedné binárky) tak, aby podporoval několik architektur (vzdálené cíle). Přidává podporu pro NetBSD/hppa a Xtensa GNU/Linux. Byla vylepšena podpora programovacího jazyka Ada a debugování optimalizovaného kódu. Připojování k programu pomocí přepínače '-c' již není podporováno, používá se '-p' (--pid).
Tiskni
Sdílej:
27.3.2008 23:28
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
void* print_pokus(void *unused)
{
while(1)
{
printf(" %s\n", (char *)unused);
}
return(NULL);
}
int main()
{
pthread_t thread_id1;
pthread_t thread_id2;
pthread_t thread_id3;
pthread_create(&thread_id1, NULL, &print_pokus, "1");
pthread_create(&thread_id2, NULL, &print_pokus, "2");
pthread_create(&thread_id3, NULL, &print_pokus, "3");
while(1)
{
sleep(1);
}
return(0);
}
28.3.2008 13:05
28.3.2008 13:10
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static pthread_mutex_t mutex;
void* print_pokus(void *unused)
{
while(1)
{
pthread_mutex_lock(&mutex);
printf(" %s\n", (char *)unused);
pthread_mutex_unlock(&mutex);
}
return(NULL);
}
int main()
{
pthread_t thread_id1;
pthread_t thread_id2;
pthread_t thread_id3;
pthread_mutex_init(&mutex, NULL);
pthread_create(&thread_id1, NULL, print_pokus, "1");
pthread_create(&thread_id2, NULL, print_pokus, "2");
pthread_create(&thread_id3, NULL, print_pokus, "3");
while(1)
{
sleep(1);
}
return(0);
}
char* string; ziskej_mutex() string = malloc(100); if (string != NULL) memcpy(string,zdroj,100); vrat_mutex(); ... ziskej_mutex(); free(string); vrat_mutex();Céčko by bylo zhola nepoužitelné, pokud by C knihovna nebyla vnitřně multithreadová.
pokud se zhroutí debugger u _jakéhokoli_ zdrojáku, pak je to špatný debuggerNebo je v něm prostě chyba, že?
Nezlobte se na mě, ale já u programovacích nástrojů trávím značný čas - a první, naprosto první požadavek na ně je spolehlivost. Nechci už zažít (jak se mi kdysi stávalo s Borlandskými kompilátory) situace, kdy chybu hledám nejen v sobě, ale také prověřuji vývojové nástroje a hraju si na jejich alfatestera. Raději oželím cokoli jen proto, abych se mohl na vývojové nástroje na 100% spolehnout.
A zde se rozmáhá nešvar na abclinuxu jásat nedávno nad linkerem, který linkuje několikrát rychleji - co na tom, že neumí spolehlivě linkovat - kdo by se zdržoval takovou maličkostí, že? Teď se propaguje debugger, který se hroutí při debugování.
Copak nikdo nechápe, že právě chyby ve vývojových nástrojích se promítají do spolehlivosti všech programů, které vyvíjíte? Třeba zlikvidovat celý Linux se vším všudy stačí malá dlouho neobjevená, ale přesto závažná chyba v gcc kompilátoru. Zvláště s linux tendencí vše znovu zkompilovat by to bylo zvláště efektivní a rychlé odstřelení celé linuxové srandy.
A zde se rozmáhá nešvar na abclinuxu jásat nedávno nad linkerem, který linkuje několikrát rychleji - co na tom, že neumí spolehlivě linkovat - kdo by se zdržoval takovou maličkostí, že?Jásalo se nad tím, že se novej a rychlej linker vyvíjí, nevím co je na tom za nešvar. Třeba já z něj mám radost, ale nepoběžím si ho hned nainstalovat.
Přemýšlím, jestli lze udělat debugger pro nativní kód, který přežije libovolně ošklivé chování laděného programu...pokud se zhroutí debugger u _jakéhokoli_ zdrojáku, pak je to špatný debuggerNebo je v něm prostě chyba, že?
Ale jinak, Miroslave, s tou spolehlivostí programátorských nástrojů, to máte pravdu. Kdysi jsem narazil na chybu v Borland C++ Builderu, kdy pořádně nefungovala šablona std::list, no to byl vomrd.
Proto mám rád GCC. Jistě má své chyby, ale žiju s vědomím, že když to přeloží kompletní linuxovou distribuci, tak to snad nezhučí na mém tic-tac-toe, alébrž vygeneruje validní kód
28.3.2008 15:15
0x080484f4 <print_pokus+0>: push %ebp
0x080484f5 <print_pokus+1>: mov %esp,%ebp
0x080484f7 <print_pokus+3>: sub $0x8,%esp
0x080484fa <print_pokus+6>: int3
0x080484fb <print_pokus+7>: add $0x24,%al
0x080484fd <print_pokus+9>: int3
0x080484fe <print_pokus+10>: xchg %eax,%edi
0x080484ff <print_pokus+11>: add $0x8,%al
0x08048501 <print_pokus+13>: call 0x8048440 <pthread_mutex_lock@plt>
0x08048506 <print_pokus+18>: int3
0x08048507 <print_pokus+19>: inc %ebp
0x08048508 <print_pokus+20>: or %cl,0xc7042444(%ecx)
0x0804850e <print_pokus+26>: add $0x24,%al
0x08048510 <print_pokus+28>: cwtl
0x08048511 <print_pokus+29>: xchg %al,(%eax,%ecx,1)
0x08048514 <print_pokus+32>: call 0x8048420 <printf@plt>
0x08048519 <print_pokus+37>: movl $0x80497cc,(%esp)
Pri debugovani debuger dava do strojoveho kodu int3, ked vsak prepne na nejake ine vlakno, zabude tuto intrukciu inemu vlaknu zobrat, cim sa poskodi kod. Ked kazde vlakno poziva svoju vlastnu funkciu, nie su v tej funkcii int3 z debugovani inych vlakien. Samozrejme debuger by mal podporovat debugovat funkcie, ktore su pozivane sucastne viac vlaknami
gdb --help|grep bugs Report bugs to "bug-gdb@gnu.org".
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.