llvm.org GIT mirror llvm / a0a6883
[docs] Fix some typos. NFC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285772 91177308-0d34-0410-b5e6-96231b3b80d8 Vedant Kumar 2 years ago
1 changed file(s) with 14 addition(s) and 15 deletion(s). Raw diff Collapse all Expand all
6363 code.
6464
6565 Currently, there are two backend consumers of debug info: DwarfDebug and
66 CodeViewDebug. DwarfDebug produces DWARF sutable for use with GDB, LLDB, and
66 CodeViewDebug. DwarfDebug produces DWARF suitable for use with GDB, LLDB, and
6767 other DWARF-based debuggers. :ref:`CodeViewDebug ` produces CodeView,
6868 the Microsoft debug info format, which is usable with Microsoft debuggers such
6969 as Visual Studio and WinDBG. LLVM's debug information format is mostly derived
9191 as setting program variables, or calling functions that have been
9292 deleted.
9393
94 * As desired, LLVM optimizations can be upgraded to be aware of the LLVM
95 debugging information, allowing them to update the debugging information
96 as they perform aggressive optimizations. This means that, with effort,
97 the LLVM optimizers could optimize debug code just as well as non-debug
98 code.
94 * As desired, LLVM optimizations can be upgraded to be aware of debugging
95 information, allowing them to update the debugging information as they
96 perform aggressive optimizations. This means that, with effort, the LLVM
97 optimizers could optimize debug code just as well as non-debug code.
9998
10099 * LLVM debug information does not prevent optimizations from
101100 happening (for example inlining, basic block reordering/merging/cleanup,
112111 "``-O3 -g``" gives you full debug information that is always available and
113112 accurate for reading (e.g., you get accurate stack traces despite tail call
114113 elimination and inlining), but you might lose the ability to modify the program
115 and call functions where were optimized out of the program, or inlined away
114 and call functions which were optimized out of the program, or inlined away
116115 completely.
117116
118 :ref:`LLVM test suite ` provides a framework to test
117 The :ref:`LLVM test suite ` provides a framework to test
119118 optimizer's handling of debugging information. It can be run like this:
120119
121120 .. code-block:: bash
828827
829828 The problem with this layout for debuggers is that we need to optimize for the
830829 negative lookup case where the symbol we're searching for is not present. So
831 if we were to lookup "``printf``" in the table above, we would make a 32 hash
832 for "``printf``", it might match ``bucket[3]``. We would need to go to the
833 offset 0x000034f0 and start looking to see if our 32 bit hash matches. To do
834 so, we need to read the next pointer, then read the hash, compare it, and skip
835 to the next bucket. Each time we are skipping many bytes in memory and
836 touching new cache pages just to do the compare on the full 32 bit hash. All
837 of these accesses then tell us that we didn't have a match.
830 if we were to lookup "``printf``" in the table above, we would make a 32-bit
831 hash for "``printf``", it might match ``bucket[3]``. We would need to go to
832 the offset 0x000034f0 and start looking to see if our 32 bit hash matches. To
833 do so, we need to read the next pointer, then read the hash, compare it, and
834 skip to the next bucket. Each time we are skipping many bytes in memory and
835 touching new pages just to do the compare on the full 32 bit hash. All of
836 these accesses then tell us that we didn't have a match.
838837
839838 Name Hash Tables
840839 """"""""""""""""