The translation is temporarily closed for contributions due to maintenance, please come back later.
Context English Persian State
The described functionality is available starting with LLDB version 12.0.0. Users of FreeBSD releases containing an earlier LLDB version may wish to use the snapshot available in <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/ports-using.html">ports or packages</link>, as <package>devel/llvm-devel</package>.
Starting with LLDB 12.0.0, remote debugging is supported on FreeBSD. This means that <command>lldb-server</command> can be started to debug a program on one host, while the interactive <command>lldb</command> client connects to it from another one.
To launch a new process to be debugged remotely, run <command>lldb-server</command> on the remote server by typing
<prompt>%</prompt> <userinput>lldb-server g <replaceable>host:port</replaceable> -- <replaceable>progname</replaceable></userinput> <prompt>%</prompt> <userinput>comm -23 ../<replaceable>old</replaceable> ../<replaceable>new</replaceable></userinput>
The process will be stopped immediately after launching, and <command>lldb-server</command> will wait for the client to connect.
Start <command>lldb</command> locally and type the following command to connect to the remote server:
(lldb) <userinput>gdb-remote <replaceable>host:port</replaceable></userinput> (gdb) <userinput>attach <replaceable>pid</replaceable></userinput>
<command>lldb-server</command> can also attach to a running process. To do that, type the following on the remote server:
<prompt>%</prompt> <userinput>lldb-server g <replaceable>host:port</replaceable> --attach <replaceable>pid-or-name</replaceable></userinput> <prompt>%</prompt> <userinput>comm -23 ../<replaceable>old</replaceable> ../<replaceable>new</replaceable></userinput>
The image editor will read from the other pipe, connected to the <varname>fd.out</varname> of our filter so it can set the first row of the output image <emphasis>before</emphasis> it sends us the second row of the input.
The <emphasis>kernel</emphasis> suspends the image editor until it receives some output from our filter, so it can pass it on to the image editor.
At this point our filter waits for the image editor to send it more data to process, while the image editor is waiting for our filter to send it the result of the processing of the first row. But the result sits in our output buffer.
The filter and the image editor will continue waiting for each other forever (or, at least, until they are killed). Our software has just entered a <link linkend="secure-race-conditions">race condition</link>.
This problem does not exist if our filter flushes its output buffer <emphasis>before</emphasis> asking the <emphasis>kernel</emphasis> for more input data.
Strangely enough, most of assembly language literature does not even mention the existence of the <acronym>FPU</acronym>, or <emphasis>floating point unit</emphasis>, let alone discuss programming it.
Yet, never does assembly language shine more than when we create highly optimized <acronym>FPU</acronym> code by doing things that can be done <emphasis>only</emphasis> in assembly language.
Organization of the <acronym>FPU</acronym>
The <acronym>FPU</acronym> consists of 8 80–bit floating–point registers. These are organized in a stack fashion—you can <function>push</function> a value on <acronym>TOS</acronym> (<emphasis>top of stack</emphasis>) and you can <function>pop</function> it.
That said, the assembly language op codes are not <function role="opcode">push</function> and <function role="opcode">pop</function> because those are already taken.
You can <function>push</function> a value on <acronym>TOS</acronym> by using <function role="opcode">fld</function>, <function role="opcode">fild</function>, and <function role="opcode">fbld</function>. Several other op codes let you <function>push</function> many common <emphasis>constants</emphasis>—such as <emphasis>pi</emphasis>—on the <acronym>TOS</acronym>.