forked from OSchip/llvm-project
6825fb64e9
The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522 |
||
|---|---|---|
| .. | ||
| CommandGuide | ||
| Frontend | ||
| HistoricalNotes | ||
| PDB | ||
| Proposals | ||
| TableGen | ||
| _ocamldoc | ||
| _static | ||
| _templates | ||
| _themes/llvm-theme | ||
| tutorial | ||
| AMDGPUUsage.rst | ||
| ARM-BE-bitcastfail.png | ||
| ARM-BE-bitcastsuccess.png | ||
| ARM-BE-ld1.png | ||
| ARM-BE-ldr.png | ||
| AdvancedBuilds.rst | ||
| AliasAnalysis.rst | ||
| Atomics.rst | ||
| BigEndianNEON.rst | ||
| BitCodeFormat.rst | ||
| BlockFrequencyTerminology.rst | ||
| BranchWeightMetadata.rst | ||
| Bugpoint.rst | ||
| CMake.rst | ||
| CMakeLists.txt | ||
| CMakePrimer.rst | ||
| CodeGenerator.rst | ||
| CodeOfConduct.rst | ||
| CodingStandards.rst | ||
| CommandLine.rst | ||
| CompileCudaWithLLVM.rst | ||
| CompilerWriterInfo.rst | ||
| Coroutines.rst | ||
| CoverageMappingFormat.rst | ||
| DebuggingJITedCode.rst | ||
| DeveloperPolicy.rst | ||
| Dummy.html | ||
| ExceptionHandling.rst | ||
| ExtendedIntegerResults.txt | ||
| ExtendingLLVM.rst | ||
| Extensions.rst | ||
| FAQ.rst | ||
| FaultMaps.rst | ||
| GarbageCollection.rst | ||
| GetElementPtr.rst | ||
| GettingStarted.rst | ||
| GettingStartedVS.rst | ||
| GlobalISel.rst | ||
| GoldPlugin.rst | ||
| HowToAddABuilder.rst | ||
| HowToBuildOnARM.rst | ||
| HowToCrossCompileLLVM.rst | ||
| HowToReleaseLLVM.rst | ||
| HowToSetUpLLVMStyleRTTI.rst | ||
| HowToSubmitABug.rst | ||
| HowToUseAttributes.rst | ||
| HowToUseInstrMappings.rst | ||
| InAlloca.rst | ||
| LLVMBuild.rst | ||
| LLVMBuild.txt | ||
| LangRef.rst | ||
| Lexicon.rst | ||
| LibFuzzer.rst | ||
| LinkTimeOptimization.rst | ||
| MCJIT-creation.png | ||
| MCJIT-dyld-load.png | ||
| MCJIT-engine-builder.png | ||
| MCJIT-load-object.png | ||
| MCJIT-load.png | ||
| MCJIT-resolve-relocations.png | ||
| MCJITDesignAndImplementation.rst | ||
| MIRLangRef.rst | ||
| Makefile.sphinx | ||
| MarkedUpDisassembly.rst | ||
| MemorySSA.rst | ||
| MergeFunctions.rst | ||
| NVPTXUsage.rst | ||
| OptBisect.rst | ||
| Packaging.rst | ||
| Passes.rst | ||
| Phabricator.rst | ||
| ProgrammersManual.rst | ||
| Projects.rst | ||
| README.txt | ||
| ReleaseNotes.rst | ||
| ReleaseProcess.rst | ||
| ReportingGuide.rst | ||
| ScudoHardenedAllocator.rst | ||
| SegmentedStacks.rst | ||
| SourceLevelDebugging.rst | ||
| SphinxQuickstartTemplate.rst | ||
| StackMaps.rst | ||
| Statepoints.rst | ||
| SystemLibrary.rst | ||
| TableGenFundamentals.rst | ||
| TestSuiteMakefileGuide.rst | ||
| TestingGuide.rst | ||
| TypeMetadata.rst | ||
| Vectorizers.rst | ||
| WritingAnLLVMBackend.rst | ||
| WritingAnLLVMPass.rst | ||
| XRay.rst | ||
| XRayExample.rst | ||
| YamlIO.rst | ||
| conf.py | ||
| doxygen-mainpage.dox | ||
| doxygen.cfg.in | ||
| gcc-loops.png | ||
| index.rst | ||
| linpack-pc.png | ||
| make.bat | ||
| re_format.7 | ||
| yaml2obj.rst | ||
README.txt
LLVM Documentation
==================
LLVM's documentation is written in reStructuredText, a lightweight
plaintext markup language (file extension `.rst`). While the
reStructuredText documentation should be quite readable in source form, it
is mostly meant to be processed by the Sphinx documentation generation
system to create HTML pages which are hosted on <http://llvm.org/docs/> and
updated after every commit. Manpage output is also supported, see below.
If you instead would like to generate and view the HTML locally, install
Sphinx <http://sphinx-doc.org/> and then do:
cd <build-dir>
cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true <src-dir>
make -j3 docs-llvm-html
$BROWSER <build-dir>/docs//html/index.html
The mapping between reStructuredText files and generated documentation is
`docs/Foo.rst` <-> `<build-dir>/docs//html/Foo.html` <-> `http://llvm.org/docs/Foo.html`.
If you are interested in writing new documentation, you will want to read
`SphinxQuickstartTemplate.rst` which will get you writing documentation
very fast and includes examples of the most important reStructuredText
markup syntax.
Manpage Output
===============
Building the manpages is similar to building the HTML documentation. The
primary difference is to use the `man` makefile target, instead of the
default (which is `html`). Sphinx then produces the man pages in the
directory `<build-dir>/docs/man/`.
cd <build-dir>
cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_MAN=true <src-dir>
make -j3 docs-llvm-man
man -l >build-dir>/docs/man/FileCheck.1
The correspondence between .rst files and man pages is
`docs/CommandGuide/Foo.rst` <-> `<build-dir>/docs//man/Foo.1`.
These .rst files are also included during HTML generation so they are also
viewable online (as noted above) at e.g.
`http://llvm.org/docs/CommandGuide/Foo.html`.
Checking links
==============
The reachability of external links in the documentation can be checked by
running:
cd docs/
make -f Makefile.sphinx linkcheck