Debugge med GDB - print af matricer

Jeg roder en hel del C og C++ kode på mine Linux-bokse, og ofte anvender jeg dobbelt hægtede matricer med dynamisk hukommelsesallokering. Det er standard indenfor digital signalbehandling og især billedbehandling.

En af de ting, som altid har irriteret mig er debugging med GDB-debuggeren af disse matricer. Jeg fik et hul igennem for noget tid siden, hvilket jeg gerne vil dele med jer. Måske I har flere ideer til at perfektionere det :)

int **b;  
int *a;

/* Allokering af a */  
a=(int *)malloc(3*sizeof(int));

/* Manuel initialisering af a */  
a[0] = 1;  
a[1] = 6;  
a[2] = 8;

/* Allokering af b */  
b=(int **)malloc(2*sizeof(int*));  
b[0]=(int *)malloc(3*sizeof(int));  
b[1]=(int *)malloc(3*sizeof(int));

/* Manuel initialisering af b */  
b[0][0] = 2;  
b[0][1] = -2;  
b[0][2] = 22;  
b[1][0] = 12;  
b[1][1] = -12;  
b[1][2] = 212;

Fint nok. Min C kodestump ovenfor kan jeg debugge med GDB.
Mht. "a"-vektoren, kan jeg få fat i indholdet i GDB via

  • (gdb) print *[a@3](mailto:a@3)
  • $1 = {1, 6, 8}

men for "b"-matricen, så er gdb ikke nær så hjælpsom.

Efter lidt diskussion på gdb-postlisten, fik jeg brygget en ~/.gdbinit-fil sammen med lidt udvidet funktionalitet.

define matprint
set $i = 0
print
printf "{{"
while $i< $arg1
set $j = 0
printf "%d",$arg0[$i][$j++]
while $j< $arg2
printf ", %d",$arg0[$i][$j++]
end
printf "}"
set $i = 1+$i
if $i < $arg1
printf ", {"
end
end
printf "}\n"
end

Men den ovenstående ~/.gdbinit kan jeg nu starte min kode, lave et breakpoint efter at b-matricen er lavet og få indholdet printet af c-matricen;

  • (gdb) matprint b 2 3
  • {{2, -2, 22}, {12, -12, 212}}

Jeg tror ikke jeg kan udgå at skulle have styr på hvor stor min matrice er, som jeg printer via "matprint"-funktionen.

Hvad jeg ikke kan pt. er at koble den data ind mod en udprintinings-funktion. DDD kan vist noget af dette, men jeg har ikke forstået endnu hvordan det kaldes. DDD ser desværre også ud til at være et skib, der er uden styring. Øv, det program holder ellers ret godt.

Alternativt er Octave 2.9.13 værd at kigge på, da det kan plotte både kurver og billeder - om den kan interfaces til GDB ved jeg heller ikke endnu. Hvis nogen af jer ved mere er jeg meget interesseret i dette.

Har I ideer til at give nemmere datatilgang til matricer, når man debugger? Ofte er mine vektorer og matricer store og med fordel kan de plottes fremfor printes.

/pto

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jørgen Henningsen

Jeg ville nok nærmere undgå at skulle debugge matricealgoritmer i C. Min erfaring er at det smart at bruge et støtteværktøj, så man kan få algoritmen testet i et miljø hvor man kan overskue matricerne (matlab f.eks.). Der har du alle muligherne for at plotte på kryds og tværs. Når det så fungere i matlab, er det et trivielt stykke tastearbejde at omsætte det til C. Bagefter kan man så holde algoritmerne op imod hinanden for at se om man har fået tastet rigtigt og det er ret let at debugge.
De projekter som jeg har været rodet ind i har så også involveret komplexe matricer. Det gør bestemt ikke tingene nemmere at overskue i C, men matlab klare det som en mis.
Dengang jeg havde snuden i det her (ca. 1998) var jeg på jagt efter metoder til at håndtere komplexe matricer i objekt orienteret C, men jeg fandt ikke rigtigt noget brugbart. Ved du om der er nogen som der har lavet klasser til det?
-Jørgen

  • 0
  • 0
Anonym

Som du allerede gør: printf virker altid og er en stor hjælp til debug. Skriv selv et simpelt debug program for udprintning; det er let. Det brugte jeg selv for 12 år siden eller længere, da jeg dengang "rodede rundt" i en hel del multi-dimentionnelle matricer for div. logik-algoritmer til deduktion, induktion, og bla, bla.

Med venlig hilsen

  • 0
  • 0
Peter Toft

Klart at printf/fprintf er gode, men det er også ufatteligt irriterende at man skal redigere koden om , oversætte, se udskrift og om igen.
Styrken er der, men jeg holder meget mere på at GDB evt. med overbygning er bedre.

Mht. Jørgen, enig og faktisk er Octave ved at være rigtig god.

  • 0
  • 0
Anonym

Troede egentlig Octave var mest til FIR filtre beregninger for BruteFIR under Linux, sorry :-)

(Octave skal da ha' en prøve i efteråret vedr. andre formål end digitale delefiltre.)

  • 0
  • 0
Peter Holm Jensen

Ja det gør jeg, og er yderst tilfreds, laver bl.a. signalbehandling og dataanalyse. Jeg bruger det også ofte til visualisering af store datamængder.

Det er blevet forbedret en del her på det sidste og efter hvad jeg kan vurdere bliver der udviklet særdeles seriøst på det for tiden.

  • 0
  • 0
Michael Deichmann

Synd at APL ikke rigtigt er moderne mere, for det er jo skabt til at arbejde med matricer i n-dimensioner.
Alle de forhold, der gjorde APL lidt tungs på datidens komputere er jo fortid idag. Med 3GHz CPU'er og gigabytes RAM burde der jo være rigeligt at gøre godt med. Og der blev jo i sin tid lavet APL kompilere (for de yngre - APL er et fortolker sprog af natur) som vel med morderne compiler teknologi burde kunne optimere koden godt nok.

Man kan faktisk stadig købe APL2 - for eksempel til workstations:
http://www-111.ibm.com/ecatalog/Detail.wss?locale=en_DK&synkey=N818704U1...

  • 0
  • 0
Log ind eller Opret konto for at kommentere