Ping.

@labath In the meantime, a lot of time passed and someone patched it in D120690, but the order on the documentation is wrong and the Python bindings need swig definitions. This patch introduces those, after rebasing with main.

Sorry for leaving this hanging for a long time. Feel free to leave feedback if I'm missing something, in the meantime.

Thanks for adding this, I ended up forgoting, since I don't use PDB.

Meanwhile, a commit will land Linux stable branches soon to fix this issue: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=44cad52cc14ae10062f142ec16ede489bccf4469 . Do we have an alternative way to fix this, e.g. a custom XFAIL flag for specific linux versions?

In D117928#3265583, @mgorny wrote:

Could you try replacing the new function with the old one and seeing if that helps? Or alternatively, trying to build a kernel from the commit just before that change and with that change.

In D117928#3263992, @mgorny wrote:

Thank you. Yes, please test on an older kernel, in case it's specifically a kernel regression.

In D117928#3263319, @mgorny wrote:

Ok, so to summarize: there's some CPU families where setting xmm2..xmm9 via ptrace doesn't work for some reason? That's quite weird. Could it be an xsave bug perhaps?

In D117928#3262874, @jingham wrote:

Ah, I think your confusion is that you missed the “Remote” part of all the classes in lldb that start with “GDB”. They are so called because they use the “gdb remote serial protocol” to communicate with the debug monitor, not because they have anything to do with gdb the debugger. That’s a protocol for communication between a debugger and a debug monitor of some sort, devised by people working on gdb aeons ago:

https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html

In lldb’s case, that debug monitor can be debugserver (the default on Darwin systems) lldb-server (the default on Linux systems) or anything else that speaks the gdb remote protocol (a lot of JTAG parts come with a gdb remote protocol stub) including potentially gdb’s implementation of the monitor: gdbserver...

But there’s no shared code between gdb & lldb, just a shared communication protocol.

Jim

In D117928#3262710, @jingham wrote:

I guess we're just all confused that you are mentioning GDB at all, and the only thing I could think of is gdbserver, since that's the only way anything GDB could get mixed with anything LLDB...

In D117928#3262689, @jingham wrote:

In D117928#3262656, @JDevlieghere wrote:

Why are we disabling a lldb test because of a bug in GDB?

Maybe somebody is running the lldb testsuite with gdbserver? That seems a legit thing to do, but if so, we should make an xfail category for gdbserver and xfail with that.

In D117928#3262656, @JDevlieghere wrote:

Why are we disabling a lldb test because of a bug in GDB?

Ping @shafik @bulbazord . Can you re-review?

I had to look into the documentation to understand how comdat works. Compared to the diffs I generated early this seems fine. I also did a full bootstrap multi-stage build of clang with this patch and the patches and flags used by my host clang. I can't reproduce the issue I described on D102453, so it seems fixed. Thanks!

Looks good. Isn't this supposed to stack with D117190? I often use the Phabricator related patches feature to stack patches and avoid merging them in the wrong order :)

In D117144#3239523, @MaskRay wrote:

The exact issue is -fsanitize=fuzzer-no-link -fno-semantic-interposition -fPIC. The -O level does not matter.

In D102453#3239524, @MaskRay wrote:

We need to understand the precise condition and exclude the exact case.
-fno-semantic-interposition is used by projects like CPython. It's important to know what issues Clang has.

OK, I can reproduce now.

Ok, digging a bit more, I found out that this is a downstream issue and somehow the patch to enforce stack protection and fPIE is probably triggering this. See https://github.com/archlinux/svntogit-packages/blob/packages/clang/trunk/enable-SSP-and-PIE-by-default.patch and https://bugs.llvm.org/show_bug.cgi?id=13410 . I'm going to add a bug report on the Arch Linux bug tracker. Do you have any idea to correctly handle this when sanitization is on?

In D102453#3239347, @MaskRay wrote:

Take this as an example:

ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol lto_module_is_object_file_for_target; recompile with -fPIC                              
>>> defined in tools/lto/CMakeFiles/LTO.dir/lto.cpp.o                                                                                                         
>>> referenced by lto.cpp:175 (/mnt/Workspace/Repos/collab/github/llvm/llvm-project/llvm/tools/lto/lto.cpp:175)                                               
>>>               tools/lto/CMakeFiles/LTO.dir/lto.cpp.o:(lto_module_is_object_file_for_target)

You can delete lto.cpp.o, rerun ninja with -v to get the compiler command line. You can then remove unneeded options and then add -S to get the assembly.
Check which instruction generates something like R_X86_64_PC32 (you may need to compile with -c and compare .o output with .s)

In D113420#3151549, @pmatos wrote:

After closing D111420, I moved the implementation of all intrinsics to this revision without the need for the polymorphic llvm_anyref_ty type.

In D102453#3238656, @MaskRay wrote:

What's your Clang version? Clang -DLLVM_USE_SANITIZER=Address works well for me (and sanitizer* build bots) with both Debug and Release.
If it's problems in older Clang versions, we can just disable the older versions.

This patch makes compilation fail when running with sanitization and debug mode, it seems. Brief log here:

I also added another test to include invalid back reference position with _D8demangle3fooQXXXx.

Added final dots on unit test comments.

I added comments to the test cases and fixed C like comments, ++I instead of I++ and other requested changes on previous patches. Can you please re-review it?

I simplified the symbol back referencing. I thought that referencing a back reference was permitted by the ABI spec, but it was pointing to the same position, so it is redundant to add two back-references. I also added a comment on the nullptr tests to describe what it is testing. In the case of Qa, it references itself and hangs.

In D111416#3233116, @dblaikie wrote:

In D111416#3223399, @ljmf00 wrote:

@dblaikie I removed all the uncovered types and added just minimal support just to prove type parsing functionality. I change the name of the patch to reflect the changes. I still have Demangled << "int"; and Demangled << "void"; that are covered but with untested behaviour. I can add a comment explaining why or remove it completely if you prefer.

Yeah, I think best to remove them for now - introduce them when they're testable. Not sure what the minimal functionality si for now - if you need one of them, but to do nothing, could just have "case 'v': ++Mangled; return Mangled;" or the like.

Added comment on nullptr testcases.

@dblaikie I removed all the uncovered types and added just minimal support just to prove type parsing functionality. I change the name of the patch to reflect the changes. I still have Demangled << "int"; and Demangled << "void"; that are covered but with untested behaviour. I can add a comment explaining why or remove it completely if you prefer.

In D116279#3214270, @MaskRay wrote:

If you don't contribute to llvm-project, LLVM_TARGETS_TO_BUILD=host or just X86 is fine. For contribution, it's a good idea to enable all targets, otherwise some tests may be skipped.

In D115662#3211312, @labath wrote:

I don't have any issues with this, if everything still works. I hoped there would be more of a discussion on this (I was hoping I'd maybe learn something from it). That obviously didn't happen, but I don't think it needs to hold this back.

I finally reproduced this locally. The buildbot is configured with BUILD_SHARED_LIBS and my builds are built without it and use LLVM_LINK_LLVM_DYLIB and CLANG_LINK_CLANG_DYLIB respectively. Since I made lld::demangle symbol inline, Demangle LLVM component was missing on MachO. I added that component to the link list on CMakeLists.txt.

In D116279#3214173, @MaskRay wrote:

The failure before the revert was:

tools/lld/MachO/CMakeFiles/lldMachO.dir/Symbols.cpp.o: In function `lld::demangle(llvm::StringRef, bool)':

This affects common code and all ports may be affected. You can use ninja check-lld to test all ports. not just check-lld-wasm or check-lld-elf

I reverted this to not congestionante other builds and described the reason on the revert commit. I will do a clean build with all targets and try to reproduce this. I only tested this on x86 and WebAssembly targets since I haven't seen target specific code here. Additionally, I've tested this on an x86_64 environment.

Squashed with D113633 and therefore superseded by D113633.

Added tests and squashed documentation as requested.

I built and checked with x86 and experimental WASM target locally on a Linux environment.