- User Since
- Dec 28 2012, 2:34 PM (378 w, 4 d)
Fri, Mar 27
It looks like this change broke the sanitizer-x86_64-linux-autoconf buildbot.
/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_clock.cpp:190:13: error: use of undeclared identifier 'dst' DCHECK_LE(dst->size_, kMaxTid); ^ 1 error generated.
Can you please take a look?
Thu, Mar 26
This change broke the sanitizer-x86_64-linux bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/26313
Please take a look.
Mon, Mar 23
Having given this some more thought, I'm still not in favour of this change even with start/stop symbols excluded, since there are other cases where enumeration of SHF_LINK_ORDER sections may be possible/desirable. To give one example, imagine that you have .init_array sections linked to the globals that they initialize (this may be possible if you can prove that the constructor has no side effects other than initializing the object). With this change we may for example have multiple .init_array sections for .bss and .data, which would need to be accounted for when computing DT_INIT_ARRAY/DT_INIT_ARRAY_SZ. There are various ways that you could deal with this sort of situation, but it seems like the simplest one would be to stick with one output section per file.
This change broke the msan buildbot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/39755
==70358==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5a602b2 in deleteParallelRegions /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/IPO/OpenMPOpt.cpp:127:9 #1 0x5a602b2 in (anonymous namespace)::OpenMPOpt::run() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/IPO/OpenMPOpt.cpp:116:16 #2 0x5a94252 in (anonymous namespace)::OpenMPOptLegacyPass::runOnSCC(llvm::CallGraphSCC&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/IPO/OpenMPOpt.cpp:559:19 #3 0x3f53893 in RunPassOnSCC /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Analysis/CallGraphSCCPass.cpp:139:23
Fri, Mar 20
Thu, Mar 12
Thu, Mar 5
There is already a way to do this, with the attribute [[clang::lto_visibility_public]]. Why do you need another one?
Tue, Mar 3
Mon, Mar 2
Feb 24 2020
This should be fixed by rG0414c5694073de26fd33a0276c47c6adea5284cf.
Now that llvm-go has been brought back, I've reverted this change.
Feb 13 2020
Does it make sense to write a test for this?
This broke users of the go bindings who were using build.sh, and changed the import path for the bindings unnecessarily. Can we please just bring back llvm-go as I requested before?
Feb 11 2020
We should bring back llvm-go instead. That program doesn't depend on llgo, it's mostly a helper for building the Go bindings.
Feb 10 2020
- Adjust the test to use MaxSize-64
Feb 7 2020
- Zero initialize array
- Use heap
Feb 6 2020
Feb 5 2020
Feb 4 2020
Feb 3 2020
Jan 31 2020
Jan 30 2020
Jan 29 2020
Jan 27 2020
Jan 24 2020
I am suggesting that you wouldn't change this function at all but would hash getSourceFileName yourself. (You shouldn't use getModuleIdentifier for anything that affects the contents of the output file because it isn't serialized.)
If you don't need a guarantee of uniqueness wouldn't it be better to just take a hash of Module::getSourceFileName() instead of looking at the names of the globals?
Jan 21 2020
On Aarch64, right now only CALL26 and JUMP26 instructions generate PLT relocations, so we manifest them with stubs that are just jumps to the original function.
Jan 17 2020
- Add a non-GC-root dummy section. This is a bit awkward to implement in MC because we have to pick a section name. The section may be combined with other normal sections with the same name. We need to be careful and not cause an "incompatible section flags" error (lld specific).
Jan 16 2020
If we just want a quick fix then I would prefer if we consider strong hidden symbols to be non-preemptible. This just seems like it would cause our assembler to hide bugs of the sort that D72197 was intended to catch, while changing the behavior for hidden symbols would mean that we continue to catch those bugs.
Shouldn't we just implement support for the relocation instead?