RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-04-04 08:41:49 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[docs] Fix some typos. NFC.

Browse Source 
llvm-svn: 285772
This commit is contained in:
Vedant Kumar 2016-11-01 23:55:50 +00:00
parent 2903b8e615
commit f672212590
1 changed files with 14 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/SourceLevelDebugging.rst
View File

@ -64,7 +64,7 @@ user a relationship between generated code and the original program source
code. code.
Currently, there are two backend consumers of debug info: DwarfDebug and Currently, there are two backend consumers of debug info: DwarfDebug and
CodeViewDebug. DwarfDebug produces DWARF sutable for use with GDB, LLDB, and CodeViewDebug. DwarfDebug produces DWARF suitable for use with GDB, LLDB, and
other DWARF-based debuggers. :ref:`CodeViewDebug <codeview>` produces CodeView, other DWARF-based debuggers. :ref:`CodeViewDebug <codeview>` produces CodeView,
the Microsoft debug info format, which is usable with Microsoft debuggers such the Microsoft debug info format, which is usable with Microsoft debuggers such
as Visual Studio and WinDBG. LLVM's debug information format is mostly derived as Visual Studio and WinDBG. LLVM's debug information format is mostly derived
@ -92,11 +92,10 @@ information provides the following guarantees:
as setting program variables, or calling functions that have been as setting program variables, or calling functions that have been
deleted. deleted.
* As desired, LLVM optimizations can be upgraded to be aware of the LLVM * As desired, LLVM optimizations can be upgraded to be aware of debugging
debugging information, allowing them to update the debugging information information, allowing them to update the debugging information as they
as they perform aggressive optimizations. This means that, with effort, perform aggressive optimizations. This means that, with effort, the LLVM
the LLVM optimizers could optimize debug code just as well as non-debug optimizers could optimize debug code just as well as non-debug code.
code.
* LLVM debug information does not prevent optimizations from * LLVM debug information does not prevent optimizations from
happening (for example inlining, basic block reordering/merging/cleanup, happening (for example inlining, basic block reordering/merging/cleanup,
@ -113,10 +112,10 @@ the program as it executes from a debugger. Compiling a program with
"``-O3 -g``" gives you full debug information that is always available and "``-O3 -g``" gives you full debug information that is always available and
accurate for reading (e.g., you get accurate stack traces despite tail call accurate for reading (e.g., you get accurate stack traces despite tail call
elimination and inlining), but you might lose the ability to modify the program elimination and inlining), but you might lose the ability to modify the program
and call functions where were optimized out of the program, or inlined away and call functions which were optimized out of the program, or inlined away
completely. completely.
:ref:`LLVM test suite <test-suite-quickstart>` provides a framework to test The :ref:`LLVM test suite <test-suite-quickstart>` provides a framework to test
optimizer's handling of debugging information. It can be run like this: optimizer's handling of debugging information. It can be run like this:
.. code-block:: bash .. code-block:: bash
@ -829,13 +828,13 @@ for the current string value.
The problem with this layout for debuggers is that we need to optimize for the The problem with this layout for debuggers is that we need to optimize for the
negative lookup case where the symbol we're searching for is not present. So negative lookup case where the symbol we're searching for is not present. So
if we were to lookup "``printf``" in the table above, we would make a 32 hash if we were to lookup "``printf``" in the table above, we would make a 32-bit
for "``printf``", it might match ``bucket[3]``. We would need to go to the hash for "``printf``", it might match ``bucket[3]``. We would need to go to
offset 0x000034f0 and start looking to see if our 32 bit hash matches. To do the offset 0x000034f0 and start looking to see if our 32 bit hash matches. To
so, we need to read the next pointer, then read the hash, compare it, and skip do so, we need to read the next pointer, then read the hash, compare it, and
to the next bucket. Each time we are skipping many bytes in memory and skip to the next bucket. Each time we are skipping many bytes in memory and
touching new cache pages just to do the compare on the full 32 bit hash. All touching new pages just to do the compare on the full 32 bit hash. All of
of these accesses then tell us that we didn't have a match. these accesses then tell us that we didn't have a match.
Name Hash Tables Name Hash Tables
"""""""""""""""" """"""""""""""""