[DebugInfo] -gpubnames option support in Driver #24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(cherry picked from commit 92e82a2)
(cherry picked from commit 44613bb)
This reverts commit 844f018.
(cherry picked from commit 13796d1)
… when the loc VT is a different size than the original element. For example a v4f16 argument is scalarized to 4 i32 values. So the values are spread out instead of being packed tightly like in the original vector. Fixes PR47000. (cherry picked from commit 08b2d0a)
Differential Revision: https://reviews.llvm.org/D85977
(cherry picked from commit 4eb4ebf)
(cherry picked from commit f4aba9d)
(cherry picked from commit f5fdb61)
Although it works fine with glibc, as currently implemented the frameheader cache is incompatible with certain platforms with slightly different locking semantics inside dl_iterate_phdr. Therefore only enable it when it is turned on explicitly with a configure-time option. Differential Revision: https://reviews.llvm.org/D86163 (cherry picked from commit a20f5fe)
…ze of DIVariables When turning on -debug-info-kind=constructor we ran into a "fragment covers entire variable" error during thinlto. The fragment is currently always emitted if there is no type size, but sometimes the variable has a forward declared struct type which doesn't have a size. This changes the code to get the type size from the GlobalVariable instead. Differential Revision: https://reviews.llvm.org/D85572 (cherry picked from commit 54b6cca)
(cherry picked from commit d9ff48d)
(cherry picked from commit 592b899)
This fixes the "Unable to insert indirect branch" fatal error sometimes seen when generating position-independent code. Patch by msizanoen1 Reviewed By: jrtc27 Differential Revision: https://reviews.llvm.org/D84833 (cherry picked from commit 5f9ecc5)
(cherry picked from commit 5fe1713)
Summary: Fixes bug : https://bugs.llvm.org/show_bug.cgi?id=46931 This commit add a new flag -DLLVM_ENABLE_SPHINX=ON to cmake command to generate sphinx documentation, along with new cmake targets `docs-flang-html`. `ninja docs-flang-html` - generates sphinx documentation. Generated release notes are present in <builddir>/tools/flang/docs/html/ folder. Reviewers: richard.barton.arm, DavidTruby Tags: #flang Differential Revision: https://reviews.llvm.org/D85470 (cherry picked from commit 2fc86cc)
Otherwise the docs-lld-html target fails to build using recent Sphinx with the following not very helpful error message: An error happened in rendering the page index. Reason: TemplateNotFound() It turns out the values in the html_sidebars dictionary always need to be lists now. See sphinx-doc/sphinx#6186
D80298 made Timer::total atomic, but this requires linking libatomic on some targets. Reviewed By: aaronpuchert Differential Revision: https://reviews.llvm.org/D85691 (cherry picked from commit b26b32b)
The global variable outputSections in the COFF writer was not cleared between runs which caused successive calls to lld::coff::link to generate invalid binaries. These binaries when loaded would result in "invalid win32 applications" and/or "bad image" errors. Differential Revision: https://reviews.llvm.org/D86401 (cherry picked from commit 54f5a4e)
We're (temporarily) disabling ExtInt for the '__atomic' builtins so we can better design their behavior later. The idea is until we do an audit/design for the way atomic builtins are supposed to work with _ExtInt, we should leave them restricted so they don't limit our future options, such as by binding us to a sub-optimal implementation via ABI.
Example after this change:
$ cat test.c
void f(_ExtInt(64) *ptr) {
__atomic_fetch_add(ptr, 1, 0);
}
$ clang -c test.c
test.c:2:22: error: argument to atomic builtin of type '_ExtInt' is not supported
__atomic_fetch_add(ptr, 1, 0);
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D84049
(cherry picked from commit ca77ab4)
D77531 has a type for mfsprg, it should be mtsprg. This patch is to fix this typo. (cherry picked from commit 95e18b2)
… anything (cherry picked from commit ac46bc3)
PR46970: for `alias = aliasee`, the alias can be used in relocation processing and on ARM st_type does affect Thumb interworking. It is thus desirable for the alias to get the same st_type. Note that the st_size field should not be inherited because some tools use st_size=0 as a heuristic to detect aliases. Retaining st_size can thwart such heuristics and cause aliases to be preferred over the original symbols. Differential Revision: https://reviews.llvm.org/D86263 (cherry picked from commit 9670029) The test symbol-assign-type.s was rewritten to not depend on 'split-file'.
When `Target::GetEntryPointAddress()` calls `exe_module->GetObjectFile()->GetEntryPointAddress()`, and the returned `entry_addr` is valid, it can immediately be returned. However, just before that, an `llvm::Error` value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: ``` * thread flang-compiler#1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 flang-compiler#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 flang-compiler#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 flang-compiler#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 flang-compiler#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 flang-compiler#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 flang-compiler#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 flang-compiler#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 flang-compiler#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 flang-compiler#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 flang-compiler#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 flang-compiler#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 flang-compiler#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 flang-compiler#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 flang-compiler#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 flang-compiler#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 flang-compiler#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 flang-compiler#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 flang-compiler#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 flang-compiler#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 flang-compiler#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 flang-compiler#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 flang-compiler#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 flang-compiler#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 flang-compiler#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 flang-compiler#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890``` Fix the incorrect error catch by only instantiating an `Error` object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 (cherry picked from commit 1ce07cd)
…Support for the OpenBSD clang driver. If not overridden, AddClangSystemIncludeArgs's implementation is empty, so by default, no system include args are added to the Clang driver. This means that invoking Clang without the frontend must include a manual -I/usr/include flag, which is inconsistent behavior. Therefore, override and implement this method to match. Some boilerplate is also borrowed for handling of the other driver flags. While we are here, also override and enable HasNativeLLVMSupport. Patch by: 3405691582 (dana koch) Differential Revision: https://reviews.llvm.org/D86412 (cherry picked from commit 2b37174)
… the OpenBSD clang driver. (cherry picked from commit bf3577e)
Add a new lit feature tag "classic_flang" to select which tests can or cannot be run when the driver is built for classic Flang. Handle LLVM_ENABLE_CLASSIC_FLANG in llvm/cmake/modules/HandleLLVMOptions.cmake instead of clang/CMakeLists.txt so that macro works in both clang and llvm.
…f-X options (flang-compiler#92) * Support for -gdwarf-5 option in Flang driver. Summary: FLANG driver doesnt pass -gdwarf-4/5 to flang1 in form of xbits, while it passes for -gdwarf-2/3 -gdwarf-2 => -x 120 0x200 -gdwarf-3 => -x 120 0x4000 Due to this -gdwarf-5 is never honored and default option -gdwarf-4 is taken. # flang -gdwarf-5 test.f90 # llvm-dwarfdump a.out | grep version 0x00000000: Compile Unit: length = 0x0000008e version = 0x0004 Now 0x1000000/0x2000000 will be passed for -gdwarf-4/5 -gdwarf-4 => -x 120 0x1000000 -gdwarf-5 => -x 120 0x2000000 Testing: - GNU gdb fortran testsuite - check-llvm - check-debuginfo * Flang doenst choose correct dwarf version when multiple -g/-gdwarfN mentioned Summary: When multiple -g/-gdwarfN options are passed together at compile time, flang chooses the least one. Clang/gfortran etc choose the last one. -gdwarf-5 -gdwarf-3 => flang chooses 5 while clang/gfortran choose 3 -gdwarf-5 -g => flang choses the default while clang/gfortran choose 5 Testing: - check-llvm - check-debuginfo * Default dwarf version should be 4 for -g with flang Currently flang dumps dwarf version 2 for -g and 4 for absence of -g ------------------------- $ flang my.f90 $ llvm-dwarfdump a.out | grep version 0x00000000: Compile Unit: length = 0x0000003d version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x00000041) $ flang -g my.f90 $ llvm-dwarfdump a.out | grep version 0x00000000: Compile Unit: length = 0x00000047 version = 0x0002 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0000004b) ------------------------- It should be 4 for -g as it is the case with clang.
This commit is motivated by reducing the merge burden by shrinking the diff between llvm upstream and classic-flang-llvm-project. Outside of Flang, Fortran code is fed through the Compile phase, and the appropriate tooling is picked up through ToolChain::SelectTool. Classic Flang introduced a FortranFrontend, but these days this seems unnecessary. Fortran can go through the same machinery as everything else. * Use the Preprocess phase to preprocess Fortran code. This phase is always combined with the Compile phase. * Use the Compile phase to lower Fortran code to LLVM IR, and use the Backend phase to compile and optimize the IR. These phases are never combined. * Remove FortranFrontendJobClass. * Remove FortranFrontend tool (instead it's just the Flang tool, which in Classic Flang mode is Classic Flang). * Update tests which inspect the output of the Classic Flang tooling, and ensures that the driver does the right thing for various types of inputs. Based on a patch from Peter Waller <[email protected]>.
release_100 is still built as it was. Artifacts names include the branch name.
Revert values in CXCursorKind as they were before CXCursor_CXXAddrspaceCastExpr was introduced in a6a237f ([OpenCL] Added addrspace_cast operator in C++ mode., 2020-05-18). Insert CXCursor_CXXAddrspaceCastExpr after the last expression in CXCursorKind using the next available value. Reviewed By: akyrtzi, svenvh Differential Revision: https://reviews.llvm.org/D90385 (cherry picked from commit bbdbd02)
This patch is for the release/11.x branch. We need to bump the SONAME, because the ABI of the shared library is changing Reviewed By: sylvestre.ledru, cuviper Differential Revision: https://reviews.llvm.org/D94941
Fix fallout caused by D89156 on 11.0.1 for MacOS Differential Revision: https://reviews.llvm.org/D95683
A bug was introduced in 82b38d2 while cherry-picking a DIGlobalVariable-related patch.
Summary:
This support is needed for the Fortran array variables with pointer/allocatable
attribute. This support enables debugger to identify the status of variable
whether that is currently allocated/associated.
for pointer array (before allocation/association)
without DW_AT_associated
(gdb) pt ptr
type = integer (140737345375288:140737354129776)
(gdb) p ptr
value requires 35017956 bytes, which is more than max-value-size
with DW_AT_associated
(gdb) pt ptr
type = integer (:)
(gdb) p ptr
$1 = <not associated>
for allocatable array (before allocation)
without DW_AT_allocated
(gdb) pt arr
type = integer (140737345375288:140737354129776)
(gdb) p arr
value requires 35017956 bytes, which is more than max-value-size
with DW_AT_allocated
(gdb) pt arr
type = integer, allocatable (:)
(gdb) p arr
$1 = <not allocated>
Testing
- unit test cases added
- check-llvm
- check-debuginfo
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D83544
This is needed to support assumed size array of fortran which can have missing upperBound/count , contrary to current DISubrange support. Example: subroutine sub (array1, array2) integer :: array1 (*) integer :: array2 (4:9, 10:*) array1(7:8) = 9 array2(5, 10) = 10 end subroutine Now the validation check is relaxed for fortran. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D87500
This patch adds support for DWARF attribute DW_AT_rank. Summary: Fortran assumed rank arrays have dynamic rank. DWARF attribute DW_AT_rank is needed to support that. Testing: unit test cases added (hand-written) check llvm check debug-info Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D89141
LLVM rejects DWARF operator DW_OP_over. This DWARF operator is needed for Flang to support assumed rank array. Summary: Currently LLVM rejects DWARF operator DW_OP_over. Below error is produced when llvm finds this operator. [..] invalid expression !DIExpression(151, 20, 16, 48, 30, 35, 80, 34, 6) warning: ignoring invalid debug info in over.ll [..] There were some parts missing in support of this operator, which are now completed. Testing -added a unit testcase -check-debuginfo -check-llvm Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D89208
This is needed to support fortran assumed rank arrays which have runtime rank. Summary: Fortran assumed rank arrays have dynamic rank. DWARF TAG DW_TAG_generic_subrange is needed to support that. Testing: unit test cases added (hand-written) check llvm check debug-info Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D89218
These extensions are no more required after merge of below PR. flang-compiler#8
SouraVX
force-pushed
the
fix_debug_names
branch
2 times, most recently
from
5265904 to
cfbe7fc
Compare
This option controls the production of .debug_names section (in DWARFv5) and .debug_pubnames section (in DWARFv4). Flang side support is provided in flang-compiler/flang#934
SouraVX
force-pushed
the
fix_debug_names
branch
from
cfbe7fc to
c85bf16
Compare
|
Will try with, fresh new branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This option controls the production of .debug_names section (in DWARFv5)
and .debug_pubnames section (in DWARFv4).
Flang side support is provided in
flang-compiler/flang#934