[DebugInfo] Backporting multiple upstream commits supporting fortran array debuggability #8

alokkrsharma · 2020-11-23T11:46:49Z

This pull request is for back-porting already committed patches to upstream LLVM.

https://reviews.llvm.org/D79306 ([DebugInfo] llvm rejects DWARF operator DW_OP_push_object_address)
https://reviews.llvm.org/D79592 ([DebugInfo] support for DW_AT_data_location in llvm)
https://reviews.llvm.org/D80197 ([DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays)
https://reviews.llvm.org/D83544 ([DebugInfo] Support for DW_AT_associated and DW_AT_allocated.)
https://reviews.llvm.org/D87500 ([DebugInfo] DISubrange support for fortran assumed size array)
https://reviews.llvm.org/D89141 [DebugInfo] Support for DWARF attribute DW_AT_rank
https://reviews.llvm.org/D89208 [DebugInfo] Support for DWARF operator DW_OP_over
https://reviews.llvm.org/D89218 [DebugInfo] Support for DW_TAG_generic_subrange

kiranchandramohan · 2020-11-23T16:53:34Z

@alokkrsharma CI is enabled (make check-llvm, make check-clang) for this repository. Can you rebase and check if it passes?

llvm rejects DWARF operator DW_OP_push_object_address.This DWARF operator is needed for Flang to support allocatable array. Summary: Currently llvm rejects DWARF operator DW_OP_push_object_address. below error is produced when llvm finds this operator. [..] invalid expression !DIExpression(151) warning: ignoring invalid debug info in pushobj.ll [..] There are some parts missing in support of this operator, need to be completed. Testing -added a unit testcase -check-debuginfo -check-llvm Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D79306

This patch adds support for DWARF attribute DW_AT_data_location. Summary: Dynamic arrays in fortran are described by array descriptor and data allocation address. Former is mapped to DW_AT_location and later is mapped to DW_AT_data_location. Testing: unit test cases added (hand-written) check llvm check debug-info Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D79592

This patch upgrades DISubrange to support fortran requirements. Summary: Below are the updates/addition of fields. lowerBound - Now accepts signed integer or DIVariable or DIExpression, earlier it accepted only signed integer. upperBound - This field is now added and accepts signed interger or DIVariable or DIExpression. stride - This field is now added and accepts signed interger or DIVariable or DIExpression. This is required to describe bounds of array which are known at runtime. Testing: unit test cases added (hand-written) check clang check llvm check debug-info Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D80197

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

alokkrsharma · 2020-11-24T06:28:16Z

@alokkrsharma CI is enabled (make check-llvm, make check-clang) for this repository. Can you rebase and check if it passes?

Thanks @kiranchandramohan . It could be run. I can see one failure in LLVM Test (ubuntu-latest) with below failure message.

go build runtime/cgo: invalid flag in go:cgo_ldflag: -Wl,-allow-shlib-undefined

Primarily it does not look like due to my changes. Can I ignore this ?

kiranchandramohan · 2020-11-25T21:13:23Z

I believe the following three are in llvm-11, rest will come in llvm-12. Is that correct?
https://reviews.llvm.org/D79306 ([DebugInfo] llvm rejects DWARF operator DW_OP_push_object_address)
https://reviews.llvm.org/D79592 ([DebugInfo] support for DW_AT_data_location in llvm)
https://reviews.llvm.org/D80197 ([DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays)

alokkrsharma · 2020-11-26T05:13:42Z

I believe the following three are in llvm-11, rest will come in llvm-12. Is that correct?
https://reviews.llvm.org/D79306 ([DebugInfo] llvm rejects DWARF operator DW_OP_push_object_address)
https://reviews.llvm.org/D79592 ([DebugInfo] support for DW_AT_data_location in llvm)
https://reviews.llvm.org/D80197 ([DebugInfo] Upgrade DISubrange to support Fortran dynamic arrays)

Yes, Correct.

kiranchandramohan · 2020-12-01T00:57:50Z

Which ones are the flang PRs that should go along with these? Would those be suitable candidates for consideration during the next two weeks? @alokkrsharma @shivaramaarao

alokkrsharma · 2020-12-01T04:50:47Z

Which ones are the flang PRs that should go along with these? Would those be suitable candidates for consideration during the next two weeks? @alokkrsharma @shivaramaarao

The sequence should be

Current one should go first
[DebugInfo] Backporting multiple upstream commits supporting fortran array debuggability #8
then port to LLVM 9.
[DebugInfo] Backporting multiple upstream commits supporting fortran array debuggability llvm#86
Once LLVM side changes are in, we can move to Flang PRs
flang gen-exec doesnt show assumed shape array in debugger flang#901
flang gen-exec doesnt print allocatable array in debugger flang#902
flang gen-exec does not generate DW_AT_associated or DW_AT_allocated flang#913
[DebugInfo] Flang should generate correct IR for assumed size array flang#925
[DebugInfo] Support for non-contiguous assumed shape array flang#926
[DebugInfo] Array debugging support with upgraded DISubrange flang#952

Please note that 3 to 8 each pull request is super set of previous one so after (2) we can directly jump to (8) which contains all commits from 3 to 8.

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

bryanpkc · 2020-12-03T19:06:16Z

Once these patches are merged into classic-flang-llvm-project/release_100, can we update ClassicFlang.cpp in release_100 to inform flang1/flang2 that the LLVM version has support for new (post-11.0) debuginfo?

gklimowicz

This passes our tests on OpenPOWER for LLVM 10.

alokkrsharma · 2020-12-05T10:21:20Z

This passes our tests on OpenPOWER for LLVM 10.

Thanks for approving this. Can you please also have a look at flang-compiler/llvm#86

gklimowicz · 2020-12-05T20:25:26Z

This passed our tests alone, but when I combine it with the changes in #952 (#901, #902, #913, #925, #926), I get failures in LLVM 10 builds. I'm going to backtrack and look at those individually with LLVM 10 and OpenPOWER.

For LLVM 9, I'm going to look at flang-compiler/llvm#86 with #952, and perhaps the individual PRs if that has failures. Stay tuned.

(I haven't tried testing against x86 or Arm.)

bryanpkc · 2020-12-06T22:21:48Z

@alokkrsharma Let me rephrase my question. Currently, the release_100 branch still pretends to be LLVM 9:

https://github.com/flang-compiler/classic-flang-llvm-project/blob/release_100/clang/lib/Driver/ToolChains/ClassicFlang.cpp#L958

This causes Flang to emit DebugInfo metadata as if the LLVM 9 is being used. After these patches are merged, the driver may need another command-line option to tell Flang that the LLVM being used has the latest DebugInfo patches applied. The same problem affects release_90 as well.

kiranchandramohan · 2020-12-07T10:16:10Z

Do you know where we set the arrays in fortran to column-major? Is it in Flang or LLVM?

alokkrsharma · 2020-12-07T10:33:37Z

Do you know where we set the arrays in fortran to column-major? Is it in Flang or LLVM?

AFAIK, Flang and LLVM dont set it and debugger decides it based on DW_AT_language attribute (DW_ORD_col_major for fortran and row major for c/c++).
Reference: http://www.dwarfstd.org/doc/DWARF5.pdf (section 5.5)
If no ordering attribute is present, the default ordering for the source language
(which is indicated by the DW_AT_language attribute of the enclosing
compilation unit entry) is assumed.

alokkrsharma · 2020-12-07T10:41:20Z

@alokkrsharma Let me rephrase my question. Currently, the release_100 branch still pretends to be LLVM 9:

https://github.com/flang-compiler/classic-flang-llvm-project/blob/release_100/clang/lib/Driver/ToolChains/ClassicFlang.cpp#L958

This causes Flang to emit DebugInfo metadata as if the LLVM 9 is being used. After these patches are merged, the driver may need another command-line option to tell Flang that the LLVM being used has the latest DebugInfo patches applied. The same problem affects release_90 as well.

Thanks, I was not aware of this. Though our planned order of merges should take care of this but it would be good to implement the option you are suggesting.
Our planned order of merges is
a) port to LLVM 10
b) port to LLVM 9
c) Flang changes assuming new debug info is available LLVM 9 onward

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

alokkrsharma · 2020-12-11T18:22:17Z

This passed our tests alone, but when I combine it with the changes in #952 (#901, #902, #913, #925, #926), I get failures in LLVM 10 builds. I'm going to backtrack and look at those individually with LLVM 10 and OpenPOWER.

For LLVM 9, I'm going to look at flang-compiler/llvm#86 with #952, and perhaps the individual PRs if that has failures. Stay tuned.

(I haven't tried testing against x86 or Arm.)

I have fixed the issue with Flang side of changes (build with FLANG_LLVM_EXTENSIONS), can you please try the build now?

alokkrsharma · 2020-12-16T12:07:43Z

Hi @kiranchandramohan and @bryanpkc,

Do you have any comment on this ?

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

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 #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 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #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)

bryanpkc

This built fine and passed tests for us.

bryanpkc · 2021-01-05T11:54:31Z

Will you submit another PR to remove the DIFortranSubrange code?

alokkrsharma · 2021-01-06T06:42:44Z

Will you submit another PR to remove the DIFortranSubrange code?

Sure. I'll do that.

kiranchandramohan

LGTM.

alokkrsharma · 2021-01-06T16:31:51Z

LGTM.

Thanks @kiranchandramohan . There was an unrelated test failure. Which is blocking the merge. Any suggestion ?

kiranchandramohan · 2021-01-06T19:04:00Z

@alokkrsharma I have merged this now. Will create a separate PR to disable the go bindings test as discussed in the previous call.

These extensions are no more required after merge of below PR. flang-compiler#8

alokkrsharma · 2021-01-07T08:35:15Z

Will you submit another PR to remove the DIFortranSubrange code?

I have raised PR #10 for this. Should I raise one for release_90 as well ?

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

These extensions are no more required after merge of below PR. flang-compiler#8

These extensions are no more required after merge of below PR. #8

Andrei Matei reported a llvm11 core dump for his bpf program https://bugs.llvm.org/show_bug.cgi?id=48578 The core dump happens in LiveVariables analysis phase. flang-compiler#4 0x00007fce54356bb0 __restore_rt flang-compiler#5 0x00007fce4d51785e llvm::LiveVariables::HandleVirtRegUse(unsigned int, llvm::MachineBasicBlock*, llvm::MachineInstr&) flang-compiler#6 0x00007fce4d519abe llvm::LiveVariables::runOnInstr(llvm::MachineInstr&, llvm::SmallVectorImpl<unsigned int>&) flang-compiler#7 0x00007fce4d519ec6 llvm::LiveVariables::runOnBlock(llvm::MachineBasicBlock*, unsigned int) flang-compiler#8 0x00007fce4d51a4bf llvm::LiveVariables::runOnMachineFunction(llvm::MachineFunction&) The bug can be reproduced with llvm12 and latest trunk as well. Futher analysis shows that there is a bug in BPF peephole TRUNC elimination optimization, which tries to remove unnecessary TRUNC operations (a <<= 32; a >>= 32). Specifically, the compiler did wrong transformation for the following patterns: %1 = LDW ... %2 = SLL_ri %1, 32 %3 = SRL_ri %2, 32 ... %3 ... %4 = SRA_ri %2, 32 ... %4 ... The current transformation did not check how many uses of %2 and did transformation like %1 = LDW ... ... %1 ... %4 = SRL_ri %2, 32 ... %4 ... and pseudo register %2 is used by not defined and caused LiveVariables analysis core dump. To fix the issue, when traversing back from SRL_ri to SLL_ri, check to ensure SLL_ri has only one use. Otherwise, don't do transformation. Differential Revision: https://reviews.llvm.org/D97792 (cherry picked from commit 51cdb78)

Andrei Matei reported a llvm11 core dump for his bpf program https://bugs.llvm.org/show_bug.cgi?id=48578 The core dump happens in LiveVariables analysis phase. #4 0x00007fce54356bb0 __restore_rt #5 0x00007fce4d51785e llvm::LiveVariables::HandleVirtRegUse(unsigned int, llvm::MachineBasicBlock*, llvm::MachineInstr&) #6 0x00007fce4d519abe llvm::LiveVariables::runOnInstr(llvm::MachineInstr&, llvm::SmallVectorImpl<unsigned int>&) #7 0x00007fce4d519ec6 llvm::LiveVariables::runOnBlock(llvm::MachineBasicBlock*, unsigned int) #8 0x00007fce4d51a4bf llvm::LiveVariables::runOnMachineFunction(llvm::MachineFunction&) The bug can be reproduced with llvm12 and latest trunk as well. Futher analysis shows that there is a bug in BPF peephole TRUNC elimination optimization, which tries to remove unnecessary TRUNC operations (a <<= 32; a >>= 32). Specifically, the compiler did wrong transformation for the following patterns: %1 = LDW ... %2 = SLL_ri %1, 32 %3 = SRL_ri %2, 32 ... %3 ... %4 = SRA_ri %2, 32 ... %4 ... The current transformation did not check how many uses of %2 and did transformation like %1 = LDW ... ... %1 ... %4 = SRL_ri %2, 32 ... %4 ... and pseudo register %2 is used by not defined and caused LiveVariables analysis core dump. To fix the issue, when traversing back from SRL_ri to SLL_ri, check to ensure SLL_ri has only one use. Otherwise, don't do transformation. Differential Revision: https://reviews.llvm.org/D97792 (cherry picked from commit 51cdb78)

@yrnkrn

This patch re-introduces the fix in the commit llvm/llvm-project@66b0cebf7f736 by @yrnkrn > In DwarfEHPrepare, after all passes are run, RewindFunction may be a dangling > > pointer to a dead function. To make sure it's valid, doFinalization nullptrs > RewindFunction just like the constructor and so it will be found on next run. > > llvm-svn: 217737 It seems that the fix was not migrated to `DwarfEHPrepareLegacyPass`. This patch also updates `llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` to include `-run-twice` to exercise the cleanup. Without this patch `llvm-lit -v llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` fails with ``` -- Testing: 1 tests, 1 workers -- FAIL: LLVM :: CodeGen/X86/dwarf-eh-prepare.ll (1 of 1) ******************** TEST 'LLVM :: CodeGen/X86/dwarf-eh-prepare.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice < /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -S | /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- Exit Code: 2 Command Output (stderr): -- Referencing function in another module! call void @_Unwind_Resume(i8* %ehptr) #1 ; ModuleID = '<stdin>' void (i8*)* @_Unwind_Resume ; ModuleID = '<stdin>' in function simple_cleanup_catch LLVM ERROR: Broken function found, compilation aborted! PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice -S 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Module Verifier' on function '@simple_cleanup_catch' #0 0x000056121b570a2c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:0 #1 0x000056121b56eb64 llvm::sys::RunSignalHandlers() /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Signals.cpp:97:0 #2 0x000056121b56f28e SignalHandler(int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:397:0 #3 0x00007fc7e9b22980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980) #4 0x00007fc7e87d3fb7 raise /build/glibc-S7xCS9/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x00007fc7e87d5921 abort /build/glibc-S7xCS9/glibc-2.27/stdlib/abort.c:81:0 #6 0x000056121b4e1386 llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl<char>&) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:674:0 #7 0x000056121b4e1386 llvm::report_fatal_error(llvm::Twine const&, bool) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/ErrorHandling.cpp:114:0 #8 0x000056121b4e1528 (/home/arakaki/build/llvm-project/main/bin/opt+0x29e3528) #9 0x000056121adfd03f llvm::raw_ostream::operator<<(llvm::StringRef) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:218:0 FileCheck error: '<stdin>' is empty. FileCheck command line: /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- ******************** ******************** Failed Tests (1): LLVM :: CodeGen/X86/dwarf-eh-prepare.ll Testing Time: 0.22s Failed: 1 ``` Reviewed By: loladiro Differential Revision: https://reviews.llvm.org/D110979 (cherry picked from commit e8806d7)

We experienced some deadlocks when we used multiple threads for logging using `scan-builds` intercept-build tool when we used multiple threads by e.g. logging `make -j16` ``` (gdb) bt #0 0x00007f2bb3aff110 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 flang-compiler#1 0x00007f2bb3af70a3 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 flang-compiler#2 0x00007f2bb3d152e4 in ?? () flang-compiler#3 0x00007ffcc5f0cc80 in ?? () flang-compiler#4 0x00007f2bb3d2bf5b in ?? () from /lib64/ld-linux-x86-64.so.2 flang-compiler#5 0x00007f2bb3b5da27 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 flang-compiler#6 0x00007f2bb3b5dbe0 in exit () from /lib/x86_64-linux-gnu/libc.so.6 flang-compiler#7 0x00007f2bb3d144ee in ?? () flang-compiler#8 0x746e692f706d742f in ?? () flang-compiler#9 0x692d747065637265 in ?? () flang-compiler#10 0x2f653631326b3034 in ?? () flang-compiler#11 0x646d632e35353532 in ?? () flang-compiler#12 0x0000000000000000 in ?? () ``` I think the gcc's exit call caused the injected `libear.so` to be unloaded by the `ld`, which in turn called the `void on_unload() __attribute__((destructor))`. That tried to acquire an already locked mutex which was left locked in the `bear_report_call()` call, that probably encountered some error and returned early when it forgot to unlock the mutex. All of these are speculation since from the backtrace I could not verify if frames 2 and 3 are in fact corresponding to the `libear.so` module. But I think it's a fairly safe bet. So, hereby I'm releasing the held mutex on *all paths*, even if some failure happens. PS: I would use lock_guards, but it's C. Reviewed-by: NoQ Differential Revision: https://reviews.llvm.org/D118439 (cherry picked from commit d919d02)

alokkrsharma added 8 commits November 23, 2020 22:32

alokkrsharma force-pushed the fortranDynamicArray_rel100 branch from f0e9e4c to e9b69b7 Compare November 23, 2020 18:01

alokkrsharma mentioned this pull request Dec 3, 2020

[DebugInfo] Array debugging support with upgraded DISubrange flang-compiler/flang#952

Merged

alokkrsharma added a commit to alokkrsharma/flang that referenced this pull request Dec 3, 2020

[DebugInfo] Array debugging support with version 9

b0eec73

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

gklimowicz requested review from bryanpkc and gklimowicz and removed request for bryanpkc December 5, 2020 07:02

gklimowicz approved these changes Dec 5, 2020

View reviewed changes

alokkrsharma added a commit to alokkrsharma/flang that referenced this pull request Dec 11, 2020

[DebugInfo] Array debugging support with version 9

19e48bb

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

alokkrsharma added a commit to alokkrsharma/flang that referenced this pull request Dec 23, 2020

[DebugInfo] Array debugging support with version 9

b4ef0fd

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

bryanpkc self-requested a review January 5, 2021 04:27

bryanpkc approved these changes Jan 5, 2021

View reviewed changes

bryanpkc mentioned this pull request Jan 5, 2021

[ClassicFlang] Fix DIFortranSubrange.getLowerBound assert failure #9

Closed

kiranchandramohan approved these changes Jan 6, 2021

View reviewed changes

kiranchandramohan merged commit 325f097 into flang-compiler:release_100 Jan 6, 2021

alokkrsharma added a commit to alokkrsharma/classic-flang-llvm-project that referenced this pull request Jan 7, 2021

[DebugInfo] Removal of DIFortranArrayType and DIFortranSubrange

cfedf76

These extensions are no more required after merge of below PR. flang-compiler#8

alokkrsharma mentioned this pull request Jan 7, 2021

[DebugInfo] Removal of DIFortranArrayType and DIFortranSubrange #10

Merged

alokkrsharma added a commit to alokkrsharma/flang that referenced this pull request Jan 29, 2021

[DebugInfo] Array debugging support with version 9

7b2c286

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

alokkrsharma added a commit to alokkrsharma/flang that referenced this pull request Jan 29, 2021

[DebugInfo] Array debugging support with version 9

2a60425

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

alokkrsharma added a commit to alokkrsharma/flang that referenced this pull request Feb 9, 2021

[DebugInfo] Array debugging support with version 9

06f40ea

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

alokkrsharma added a commit to alokkrsharma/flang that referenced this pull request Feb 20, 2021

[DebugInfo] Array debugging support with version 9

6277f8d

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

bryanpkc pushed a commit to flang-compiler/flang that referenced this pull request Feb 21, 2021

[DebugInfo] Array debugging support with version 9

1234d52

This commit is valid only after below PRs are merged. LLVM10: flang-compiler/classic-flang-llvm-project#8 LLVM9: flang-compiler/llvm#86

alokkrsharma added a commit to alokkrsharma/classic-flang-llvm-project that referenced this pull request Feb 21, 2021

[DebugInfo] Removal of DIFortranArrayType and DIFortranSubrange

801f09b

These extensions are no more required after merge of below PR. flang-compiler#8

alokkrsharma added a commit to alokkrsharma/classic-flang-llvm-project that referenced this pull request Feb 23, 2021

[DebugInfo] Removal of DIFortranArrayType and DIFortranSubrange

da76cb9

These extensions are no more required after merge of below PR. flang-compiler#8

alokkrsharma added a commit to alokkrsharma/classic-flang-llvm-project that referenced this pull request Feb 23, 2021

[DebugInfo] Removal of DIFortranArrayType and DIFortranSubrange

65860df

These extensions are no more required after merge of below PR. flang-compiler#8

kiranchandramohan pushed a commit that referenced this pull request Mar 14, 2021

[DebugInfo] Removal of DIFortranArrayType and DIFortranSubrange

a052247

These extensions are no more required after merge of below PR. #8

kiranchandramohan pushed a commit that referenced this pull request Mar 14, 2021

[DebugInfo] Removal of DIFortranArrayType and DIFortranSubrange

88d242c

These extensions are no more required after merge of below PR. #8

bryanpkc mentioned this pull request Jun 22, 2022

[DebugInfo] Reduce downstream delta in DIGlobalVariable #112

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DebugInfo] Backporting multiple upstream commits supporting fortran array debuggability #8

[DebugInfo] Backporting multiple upstream commits supporting fortran array debuggability #8

alokkrsharma commented Nov 23, 2020

kiranchandramohan commented Nov 23, 2020

alokkrsharma commented Nov 24, 2020

kiranchandramohan commented Nov 25, 2020

alokkrsharma commented Nov 26, 2020

kiranchandramohan commented Dec 1, 2020

alokkrsharma commented Dec 1, 2020

bryanpkc commented Dec 3, 2020

gklimowicz left a comment

alokkrsharma commented Dec 5, 2020

gklimowicz commented Dec 5, 2020

bryanpkc commented Dec 6, 2020

kiranchandramohan commented Dec 7, 2020

alokkrsharma commented Dec 7, 2020

alokkrsharma commented Dec 7, 2020

alokkrsharma commented Dec 11, 2020

alokkrsharma commented Dec 16, 2020

bryanpkc left a comment

bryanpkc commented Jan 5, 2021

alokkrsharma commented Jan 6, 2021

kiranchandramohan left a comment

alokkrsharma commented Jan 6, 2021

kiranchandramohan commented Jan 6, 2021

alokkrsharma commented Jan 7, 2021

[DebugInfo] Backporting multiple upstream commits supporting fortran array debuggability #8

[DebugInfo] Backporting multiple upstream commits supporting fortran array debuggability #8

Conversation

alokkrsharma commented Nov 23, 2020

kiranchandramohan commented Nov 23, 2020

alokkrsharma commented Nov 24, 2020

kiranchandramohan commented Nov 25, 2020

alokkrsharma commented Nov 26, 2020

kiranchandramohan commented Dec 1, 2020

alokkrsharma commented Dec 1, 2020

bryanpkc commented Dec 3, 2020

gklimowicz left a comment

Choose a reason for hiding this comment

alokkrsharma commented Dec 5, 2020

gklimowicz commented Dec 5, 2020

bryanpkc commented Dec 6, 2020

kiranchandramohan commented Dec 7, 2020

alokkrsharma commented Dec 7, 2020

alokkrsharma commented Dec 7, 2020

alokkrsharma commented Dec 11, 2020

alokkrsharma commented Dec 16, 2020

bryanpkc left a comment

Choose a reason for hiding this comment

bryanpkc commented Jan 5, 2021

alokkrsharma commented Jan 6, 2021

kiranchandramohan left a comment

Choose a reason for hiding this comment

alokkrsharma commented Jan 6, 2021

kiranchandramohan commented Jan 6, 2021

alokkrsharma commented Jan 7, 2021