1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
<chapter id="debugger">
<title>Fejlsøgergrænsefladen</title>
<indexterm zone="debugger"><primary>fejlsøgere</primary></indexterm>
<para>&tdevelop; indeholder en intern fejlsøger for C og C++, som er direkte integreret med editoren. Teknisk set er den implementeret som en grænseflade som bruger den flytbare &GNU;-fejlsøger <application>gdb</application> via en pipe. Fejlsøgeren kan startes på flere måder: </para>
<itemizedlist>
<listitem>
<para>Hovedprogrammet i projektet indlæses i fejlsøgeren med <menuchoice><guimenu>Fejlsøg</guimenu><guimenuitem>Start</guimenuitem></menuchoice>. </para>
</listitem>
<listitem>
<para>Ved at bruge <menuchoice><guimenu>Fejlsøg</guimenu> <guimenuitem>Start (andet)</guimenuitem> <guimenuitem>Undersøg hukommelsesdump</guimenuitem></menuchoice>, indlæser du et hukommelsesdump til hukommelsen, som blev lavet af operativsystemets kerne da programmet brød sammen. (At lave hukommelsesdump kan være slået fra på systemet, se <application>ulimit(1)</application>). Dette er nyttigt for en post-mortem analyse af et program. </para>
</listitem>
<listitem>
<para>Du starter fejlsøgeren for et program som allerede kører med <menuchoice><guimenu>Fejlsøg</guimenu><guimenuitem>Start (andet)</guimenuitem> <guimenuitem>Forbind til proces</guimenuitem></menuchoice>. En procesliste vises hvor du kan vælge processen som fejlsøgeren skal overtage. </para>
</listitem>
<listitem>
<para>Bemærk at fejlsøgning kun er mulig hvis projektet er kompileret med fejlsøgningsinformation aktiveret. Den kan aktiveres i dialogen <guibutton>Oversætterindstillinger</guibutton>. Når dette er aktiveret, laver oversætteren yderligere informationer som lader fejlsøgeren associere filnavne og linjenumre med adresser i det kørbare program. </para>
</listitem>
</itemizedlist>
<para>Grænsefladen til fejlsøgeren tilbyder flere visninger <quote>ind i</quote> processen: </para>
<para>Hvis du forsøger at fejlsøge et projekt uden fejlsøgningsinformation, får du meddelelsen <computeroutput>Ingen kildekode...</computeroutput> i statuslinjen. Hvis du forsøger at sætte stoppunkter, vises de som <computeroutput>Hvilende (tilføj)</computeroutput> i stoppunktsvinduet (se nedenfor). </para>
<variablelist>
<varlistentry>
<term>Variabler</term>
<listitem>
<indexterm zone="debugger"><primary>overvågningsvariabler</primary></indexterm>
<para>Dette vindue viser værdier for alle lokale variabler på det nuværende sted i programmet. Det dækker variablerne i oversætterens kaldstak, &ie; funktionen hvor processen blev afbrudt, funktionen som kaldte denne funktionen, og så videre hele vejen til funktionen <function>main()</function>. </para>
<para>En anden gren i variabelvinduet indeholder overvågningsvariabler. Du kan selv indstille hvilke variabler som ses her. Både lokale og globale variabler kan overvåges. Du kan enten tilføje en variabel ved at klikke på knappen <guibutton>Tilføj</guibutton> eller trykke på returtasten når punktet <keycap>Overvåg</keycap> er markeret. Variablerne kan fjernes igen med den sammenhængsafhængige menuen. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Rammestak</term>
<listitem>
<indexterm zone="debugger"><primary>rammestak</primary></indexterm>
<para>(... endnu ikke skrevet ...) </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Stoppunkter</term>
<listitem>
<indexterm zone="debugger"><primary>stoppunkter</primary></indexterm>
<para>Vinduet lader dig se og behandle stoppunkterne. Husk at &tdevelop; bruger <application>GDB</application>, så for at forstå &tdevelop;s fejlsøgningsfunktioner fuldstændigt, skal du vide en lille smule om <ulink url="http://www.gnu.org/software/gdb">GDB</ulink>. </para>
<para>Hvis du vil kigge på kildekoden, defineres stoppunkter i <filename>tdevelop/languages/cpp/debugger/breakpoint.h</filename>. </para>
<para>I venstre kant har vinduet knapper for at:</para>
<itemizedlist>
<listitem><para>Tilføj et tomt breakpoint</para></listitem>
<listitem><para>Redigér det markerede stoppunkt</para></listitem>
<listitem><para>Sletter det valgte breakpoint</para></listitem>
<listitem><para>Fjern alle breakpoints</para></listitem>
</itemizedlist>
<para>Hoveddelen af vinduet er en tabel med syv søjler. Hver linje i tabellen er et stoppunkt. Søjlerne er:</para>
<orderedlist>
<listitem><para>Markeringsafkrydsningsfelt</para></listitem>
<listitem><para>Type: en af: Ugyldig, Fil:Linje, Overvågningspunkt, Adresse, Funktion</para></listitem>
<listitem><para>Status. Værdierne er:</para>
<itemizedlist>
<listitem><para>Aktiv</para></listitem>
<listitem><para>Deaktiveret: Hvert stoppunkt kan <quote>aktiveres</quote> eller <quote>deaktiveres</quote>. Hvis det er deaktiveret har det ingen effekt på programmet indtil det aktiveres igen.</para></listitem>
<listitem><para>Hvilende (tilføj): En stoppunkt er markeret sådan her hvis ingen fejlsøgningsinformation er tilgængelig. Fra GDB's informationsside: <blockquote><para>Hvis et specificeret stoppunktssted ikke kan findes, kan det skyldes det faktum at stedet er i et delt bibliotek som endnu ikke er indlæst. I et sådant tilfælde, kan du ville at GDB laver et specielt stoppunkt (kendt som et <quote>hvilende stoppunkt</quote>) som forsøger at løse sig selv op i fremtiden når et passende delt bibliotek indlæses.</para></blockquote> </para></listitem>
</itemizedlist>
</listitem>
<listitem><para>Hvilende (rydning)</para></listitem>
<listitem><para>Hvilende (ændring)</para></listitem>
<listitem><para>Sted på formatet filnavn:linjenummer</para></listitem>
<listitem><para>Betingelse</para></listitem>
<listitem><para>Ignorér antal: Hvis det er et tal <varname>ANTAL</varname> større end nul, stoppes programmets kørsel ikke før følgende <varname>ANTAL</varname> gange som stoppunktet nås. Udover at mindske antallet at ignorere, udfører <application>gdb</application> ingen handling.</para></listitem>
<listitem><para>Træffere: Regner ud hvor mange gange et stoppunkt er truffet.</para></listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry>
<term>Vis assemblerkode</term>
<listitem>
<indexterm zone="debugger"><primary>vis assemblerkode</primary></indexterm>
<para>(... endnu ikke skrevet ...)</para>
</listitem>
</varlistentry>
</variablelist>
<sect1 id="settingbreakpoints">
<title>Sæt stoppunkter</title>
<para>(... endnu ikke skrevet ...) </para>
</sect1> <!-- settingbreakpoints -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1 id ="debuggeroptions">
<title>Tilvalg</title>
<variablelist>
<varlistentry>
<term>Vis behandlede navne</term>
<listitem>
<indexterm zone="debugger"><primary>navnebehandling</primary></indexterm>
<indexterm zone="debugger"><primary>behandling</primary><secondary>navn</secondary></indexterm>
<para>Funktionsnavne i det kørbare program er <quote>behandlede</quote> for C++, &ie; funktionsnavnet indeholder information om argumenternes typer. Dette er nødvendigt for at støtte overbelastede funktioner. Behandlingsalgoritmen er ikke standardiseret, og adskiller sig til og med mellem forskellige udgaver af &GNU;'s C++ oversætter. </para>
<para>I assemblerkodevinduet vises normalt ubehandlede navne, så funktionssignaturer ligner udseendet i kildekoden, og er let læsbare. Alternativt, kan du vælge at se behandlede navne. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Forsøg at sætte stoppunkter når biblioteker indlæses</term>
<listitem>
<indexterm zone="debugger"><primary>dovne stoppunkter</primary></indexterm>
<indexterm zone="debugger"><primary>stoppunkter</primary><secondary>doven</secondary></indexterm>
<para>Fejlsøgerens baggrundsprogram <application>gdb</application> tillader ikke at stoppunkter sættes i kode som ikke for øjeblikket er indlæst. I et rigtigt modulært program, hvor kode ofte kun indlæses efter behov såsom plugin (med brug af C-bibliotekets funktion <function>dlopen(3)</function>), kan dette være besværligt. Derfor håndterer &tdevelop; selv støtte for stoppunkter i delte biblioteker. Hvis du aktiverer dette, kan du sætte stoppunkter i biblioteker som ikke er indlæst. Derefter, så snart <application>gdb</application> fortæller at et bibliotek er indlæst, forsøger &tdevelop; at sætte de hvilende stoppunkter. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Aktivér flydende værktøjslinje</term>
<listitem>
<indexterm zone="debugger"><primary>fejlsøgningsværktøjslinje</primary></indexterm>
<indexterm zone="debugger"><primary>værktøjslinje</primary><secondary>fejlsøger</secondary></indexterm>
<para>(... endnu ikke skrevet ...) </para>
</listitem>
</varlistentry>
</variablelist>
</sect1> <!-- debuggeroptions -->
</chapter> <!-- debugger -->
|
