FreeBSD Doc/books_developers-handbook — Portuguese (Brazil) @ Weblate: To step through the program a line at a time, …

Translation

Content

Source string comment

(itstool) path: sect3/para

English

To step through the program a line at a time, type <userinput>thread step-over</userinput>. When the program gets to a function call, step into it by typing <userinput>thread step-in</userinput>. Once in a function call, return from it by typing <userinput>thread step-out</userinput> or use <userinput>up</userinput> and <userinput>down</userinput> to take a quick look at the caller.

Portuguese (Brazil) 436/3850

Needs editing

Context	English	Portuguese (Brazil)	State
	This section is intended to be a quick introduction to using debuggers and does not cover specialized topics such as debugging the kernel. For more information about that, refer to <xref linkend="kerneldebug"/>.	Esta seção pretende ser uma introdução ao uso de <command> gdb </command> e não abrange tópicos especializados, como a depuração do kernel.
	The standard debugger supplied with FreeBSD 12.1 is called <command>lldb</command> (<application>LLVM debugger</application>). As it is part of the standard installation for that release, there is no need to do anything special to use it. It has good command help, accessible via the <userinput>help</userinput> command, as well as <link xlink:href="https://lldb.llvm.org/">a web tutorial and documentation</link>.
	The <command>lldb</command> command is available for FreeBSD 11.3 <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/ports-using.html">from ports or packages</link> as <package>devel/llvm</package>. This will install the default version of lldb (currently 9.0).
	The other debugger available with FreeBSD is called <command>gdb</command> (<application>GNU debugger</application>). Unlike lldb, it is not installed by default on FreeBSD 12.1; to use it, <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/ports-using.html">install</link> <package>devel/gdb</package> from ports or packages. The version installed by default on FreeBSD 11.3 is old; instead, install <package>devel/gdb</package> there as well. It has quite good on-line help, as well as a set of info pages.
	Which one to use is largely a matter of taste. If familiar with one only, use that one. People familiar with neither or both but wanting to use one from inside <application>Emacs</application> will need to use <command>gdb</command> as <command>lldb</command> is unsupported by <application>Emacs</application>. Otherwise, try both and see which one you prefer.
	Using lldb
	Starting lldb
	Start up lldb by typing
	<prompt>%</prompt> <userinput>lldb -- <replaceable>progname</replaceable></userinput>	<prompt>%</prompt> <userinput>gdb <replaceable>progname</replaceable></userinput>
	Running a Program with lldb	Executando um programa no depurador
	Compile the program with <option>-g</option> to get the most out of using <command>lldb</command>. It will work without, but will only display the name of the function currently running, instead of the source code. If it displays a line like:	Você precisará ter compilado o programa com o <option value=-g> -g </option> opção para tirar o máximo proveito do uso <command> gdb </command> . Ele funcionará sem, mas você verá apenas o nome da função em que está, em vez do código-fonte. Se você vir uma linha como:
	Breakpoint 1: where = temp`main, address = …
	(without an indication of source code filename and line number) when setting a breakpoint, this means that the program was not compiled with <option>-g</option>.	quando <command> gdb </command> inicia, você saberá que o programa não foi compilado com o <option value=-g> -g </option> opção.
	Most <command>lldb</command> commands have shorter forms that can be used instead. The longer forms are used here for clarity.
	At the <command>lldb</command> prompt, type <userinput>breakpoint set -n main</userinput>. This will tell the debugger not to display the preliminary set-up code in the program being run and to stop execution at the beginning of the program's code. Now type <userinput>process launch</userinput> to actually start the program— it will start at the beginning of the set-up code and then get stopped by the debugger when it calls <function>main()</function>.	No <command> gdb </command> prompt, digite <userinput> quebrar principal </userinput> . Isso dirá ao depurador que você não está interessado em observar o código de configuração preliminar no programa que está sendo executado e que ele deve interromper a execução no início de seu código. Agora digite <userinput> corre </userinput> para iniciar o programa - ele será iniciado no início do código de configuração e, em seguida, será interrompido pelo depurador quando ele for chamado <function> a Principal() </function> . (Se você já se perguntou onde <function> a Principal() </function> é chamado, agora você sabe!).
	To step through the program a line at a time, type <userinput>thread step-over</userinput>. When the program gets to a function call, step into it by typing <userinput>thread step-in</userinput>. Once in a function call, return from it by typing <userinput>thread step-out</userinput> or use <userinput>up</userinput> and <userinput>down</userinput> to take a quick look at the caller.	Agora você pode percorrer o programa, uma linha de cada vez, pressionando <command> n </command> . Se você chegar a uma chamada de função, poderá entrar nela pressionando <command> s </command> . Quando estiver em uma chamada de função, você pode retornar de uma chamada de função pressionando <command> f </command> . Você também pode usar <command> acima </command> e <command> baixa </command> para dar uma olhada rápida no chamador
	Here is a simple example of how to spot a mistake in a program with <command>lldb</command>. This is our program (with a deliberate mistake):	Aqui está um exemplo simples de como identificar um erro em um programa com <command> gdb </command> . Este é o nosso programa (com um erro deliberado):
	#include <stdio.h> int bazz(int anint); main() { int i; printf("This is my program\n"); bazz(i); return 0; } int bazz(int anint) { printf("You gave me %d\n", anint); return anint; }	#include <stdio.h> int bazz(int anint); main() { int i; printf("This is my program\n"); bazz(i); return 0; } int bazz(int anint) { printf("You gave me %d\n", anint); return anint; }
	This program sets <symbol>i</symbol> to be <literal>5</literal> and passes it to a function <function>bazz()</function> which prints out the number we gave it.	Este programa define <symbol> Eu </symbol> ser estar <literal> 5 </literal> e passa para uma função <function> bazz () </function> que imprime o número que demos a ele.
	Compiling and running the program displays	Quando compilamos e executamos o programa, recebemos
	<prompt>%</prompt> <userinput>cc -g -o temp temp.c</userinput> <prompt>%</prompt> <userinput>./temp</userinput> This is my program anint = -5360	<prompt>%</prompt> <userinput>cc -g -o temp temp.c</userinput> <prompt>%</prompt> <userinput>./temp</userinput> This is my program anint = 4231
	That is not what was expected! Time to see what is going on!	Isso não foi o que esperávamos! Hora de ver o que está acontecendo!
	<prompt>%</prompt> <userinput>lldb -- temp</userinput> (lldb) target create "temp" Current executable set to 'temp' (x86_64). (lldb) <userinput>breakpoint set -n main</userinput> <lineannotation>Skip the set-up code</lineannotation> Breakpoint 1: where = temp`main + 15 at temp.c:8:2, address = 0x00000000002012ef <lineannotation>lldb puts breakpoint at main()</lineannotation> (lldb) <userinput>process launch</userinput> <lineannotation>Run as far as main()</lineannotation> Process 9992 launching Process 9992 launched: '/home/pauamma/tmp/temp' (x86_64) <lineannotation>Program starts running</lineannotation> Process 9992 stopped * thread #1, name = 'temp', stop reason = breakpoint 1.1 <lineannotation>lldb stops at main()</lineannotation> frame #0: 0x00000000002012ef temp`main at temp.c:8:2 5 main() { 6 int i; 7 -> 8 printf("This is my program\n"); <lineannotation>Indicates the line where it stopped</lineannotation> 9 bazz(i); 10 return 0; 11 } (lldb) <userinput>thread step-over</userinput> <lineannotation>Go to next line</lineannotation> This is my program <lineannotation>Program prints out</lineannotation> Process 9992 stopped * thread #1, name = 'temp', stop reason = step over frame #0: 0x0000000000201300 temp`main at temp.c:9:7 6 int i; 7 8 printf("This is my program\n"); -> 9 bazz(i); 10 return 0; 11 } 12 (lldb) <userinput>thread step-in</userinput> <lineannotation>step into bazz()</lineannotation> Process 9992 stopped * thread #1, name = 'temp', stop reason = step in frame #0: 0x000000000020132b temp`bazz(anint=-5360) at temp.c:14:29 <lineannotation>lldb displays stack frame</lineannotation> 11 } 12 13 int bazz(int anint) { -> 14 printf("You gave me %d\n", anint); 15 return anint; 16 } (lldb)
	Hang on a minute! How did <symbol>anint</symbol> get to be <literal>-5360</literal>? Was it not set to <literal>5</literal> in <function>main()</function>? Let us move up to <function>main()</function> and have a look.	Espere um minuto! Como foi <symbol> não anint </symbol> chegar a ser <literal> 4231 </literal> ? Nós não definimos para sermos <literal> 5 </literal> dentro <function> a Principal() </function> ? Vamos subir para <function> a Principal() </function> e dê uma olhada.
	(lldb) <userinput>up</userinput> <lineannotation>Move up call stack</lineannotation> frame #1: 0x000000000020130b temp`main at temp.c:9:2 <lineannotation>lldb displays stack frame</lineannotation> 6 int i; 7 8 printf("This is my program\n"); -> 9 bazz(i); 10 return 0; 11 } 12 (lldb) <userinput>frame variable i</userinput> <lineannotation>Show us the value of i</lineannotation> (int) i = -5360 <lineannotation>lldb displays -5360</lineannotation>	(gdb) <userinput>up</userinput> <lineannotation>Move up call stack</lineannotation> #1 0x1625 in main () at temp.c:11 <lineannotation>gdb displays stack frame</lineannotation> (gdb) <userinput>p i</userinput> <lineannotation>Show us the value of i</lineannotation> $1 = 4231 <lineannotation>gdb displays 4231</lineannotation>
	Oh dear! Looking at the code, we forgot to initialize <symbol>i</symbol>. We meant to put	Oh querida! Olhando o código, esquecemos de inicializar <symbol> Eu </symbol> . Nós pretendíamos colocar
	<lineannotation>…</lineannotation> main() { int i; i = 5; printf("This is my program\n"); <lineannotation>…</lineannotation>	<lineannotation>…</lineannotation> main() { int i; i = 5; printf("This is my program\n"); <lineannotation>…</lineannotation>
	but we left the <literal>i=5;</literal> line out. As we did not initialize <symbol>i</symbol>, it had whatever number happened to be in that area of memory when the program ran, which in this case happened to be <literal>-5360</literal>.	mas deixamos o <literal> i = 5; </literal> line out. Como nós não inicializamos <symbol> Eu </symbol> , tinha qualquer número que estivesse naquela área de memória quando o programa rodava, o que neste caso aconteceu <literal> 4231 </literal>
	The <command>lldb</command> command displays the stack frame every time we go into or out of a function, even if we are using <userinput>up</userinput> and <userinput>down</userinput> to move around the call stack. This shows the name of the function and the values of its arguments, which helps us keep track of where we are and what is going on. (The stack is a storage area where the program stores information about the arguments passed to functions and where to go when it returns from a function call.)	<command> gdb </command> exibe o quadro da pilha toda vez que entramos ou saímos de uma função, mesmo se estivermos usando <command> acima </command> e <command> baixa </command> para percorrer a pilha de chamadas. Isso mostra o nome da função e os valores de seus argumentos, o que nos ajuda a saber onde estamos e o que está acontecendo. (A pilha é uma área de armazenamento onde o programa armazena informações sobre os argumentos passados às funções e para onde ir quando retorna de uma chamada de função).
	Examining a Core File with lldb	Examinando um arquivo principal
	A core file is basically a file which contains the complete state of the process when it crashed. In <quote>the good old days</quote>, programmers had to print out hex listings of core files and sweat over machine code manuals, but now life is a bit easier. Incidentally, under FreeBSD and other 4.4BSD systems, a core file is called <filename><replaceable>progname</replaceable>.core</filename> instead of just <filename>core</filename>, to make it clearer which program a core file belongs to.	Um arquivo principal é basicamente um arquivo que contém o estado completo do processo quando ele caiu. <quote> os bons velhos tempos </quote> os programadores tiveram que imprimir listas hexadecimais de arquivos principais e suar os manuais de códigos de máquina, mas agora a vida é um pouco mais fácil. Aliás, sob o FreeBSD e outros sistemas 4.4BSD, um arquivo principal é chamado <filename><replaceable> progname </replaceable> .testemunho </filename> em vez de apenas <filename> testemunho </filename> , para tornar mais claro qual programa um arquivo principal pertence.