I'm not convinced this is the right solution. First of all I don't think embedding a build path in LLDB in acceptable. Swift uses the standalone builds and with this change the linux toolchain will have some random CI path embedded in LLDB, which based on the comment above it wouldn't even need. The existing code implies that this should work once LLDB is installed. If this issue is indeed limited in scope to the build directory, I think we should either create a symlink or copy over the resource directory. An alternative, more general approach might be to make the source directory configurable through a setting so that this could work wherever LLDB lives and then have the test suite populate that setting based on the location of the resource directory in the clang build dir.
Thanks for updating the comment in dsymutil!
Mon, Sep 28
Instead of copy-pasting this code can we extract a helper and call it with g_register_infos_mips64 and g_register_infos respectively?
Fri, Sep 25
Thanks for the thorough explanation. LGTM.
Thu, Sep 24
I don't mind keeping it around, but I also haven't used the manual steps since the script's inception, so LGTM. We can always reinstate it if someone complains.
I meant to accept this, we can land this and deal with my suggestion as a follow up. LGTM.
Good catch, thank you! I wanted to suggest making the SBAddress constructor take the Address by const-reference but wanted to see how much work that'd be which resulted in D88249.
Wed, Sep 23
maybe slightly long test case - could do this with the CU DIE itself? (perhaps a case where hand-crafted/substantially hand-modified assembly is OK, because it can be made /so/ simple - or maybe yaml2obj dwarf support is adequate for this use case?)
Hi, currently, obj2yaml doesn't work properly when dumping the .debug_abbrev/__debug_abbrev section. We might not be able to get the correct output when there are multiple DIEs in one abbrev table. D87179 has fixed it but hasn't been landed yet. I've created one test case for this patch. Hope it works :-)
Based on the signature of the call below this LGTM.
I'm very excited about this feature. Great job on the documentation, both in the help output as for the website. Do you have a potential use case in mind that we could add to the examples?
This is the same change as we did on Github, right? If so this LGTM.
Tue, Sep 22
@labath @jrtc27 @clayborg Now that we have at least 3 open-source debug servers that we can use to test this with (OpenOCD, QEMU gdbstub, gdbserver) perhaps this can be merged? I had very good results using this patch with OpenOCD. This patch doesn't include automated tests, but I'm not sure what tests would be required for this patch, or that it makes sense to require them at this point. I'll be doing more work for LLDB RISC-V support, and I'll provide tests for specific fixes going forward.
Mon, Sep 21
does this classify as a warning? Is there a distinction between ill-formed DWARF and "this is valid, but unlikely to be great"?
The change to use the configuration looks good, but I think Pavel raised a good point. Which tests are affected by this? How much work would it be to convert them as suggested?
What's the scenario where you run the DWARF linker with already-linked binaries?
Wed, Sep 16
I think this will be very useful. LGTM!
Tue, Sep 15
Mon, Sep 14
Fri, Sep 11
Remove spurious change
The reproducer instrumentation part LGTM.
Thu, Sep 10
LGTM. This must've been broken for a while. I'll re-enable running the API tests on http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/ so we can catch this earlier.
Thanks! I'll land it for you.
Wed, Sep 9
Tue, Sep 8
I believe the issue was with people having a modified version that replaces localhost with some other IP address.
I didn't even realize that was an option. Yes, this patch would break that. I'll have to take another approach, then.
You might check the "git log" on any files that have "127.0.0.1" in them for details.
Do you happen to have any references (bugs etc.) for those kinds of issues?
Looks like rLLDB202424 is the patch that did most of this. There may be more context in rdar://problem/16154630 but I don't have access to that.
If an LLVM install disabled LLVM_ENABLE_WARNINGS, should other builds inherit that? I would think no, but is there a precedent for that that to be the case?
Sounds reasonable to me. I'll split it up in two patches. I'll update this one to use the double dashes so we can land the functionality and keep things consistent with the rest of LLDB. I'll create another patch to do the handling of raw commands to use a heuristic.
You need to add LLVM_ENABLE_WARNINGS to LLVMConfig.cmake.in so that the standalone builds know what value was set in the LLVM build. I think with the current patch the other projects won't inherit the value and just default to ON?
Wed, Sep 2
Thanks, should be fixed by 426fa35b655ffb8647d9d69580a69627c0d19024
I agree that silly, but maybe the same fix should then be applied to the expr command (and any other command with similar behavior).
So CommandObjectRaw does support arguments, but they way it works is that you need to have a delimiter for the 'raw' part which is --. If you have that, then you can just use invoke the normal option parsing like CommandObjectExpression does. The handcrafted implementation here adds a completely new lldb command syntax which has a 'raw' part without the -- which seems inconsistent (not saying that the syntax here is worse or better than script --language foo --, but it's just inconsistent with the way the rest of LLDB works). It's obviously also missing the other quirky things that are part of the command syntax (e.g., quoting arguments isn't supported and so on).
- Remove custom parsing and use the command options insofar possible.
- Require -- as a delimiter when language and code are specified together.
Tue, Sep 1
This is great, thanks for taking the time to fix all this.
Other than a small style nit this LGTM
Hello. I have an auto-bisecting multi-stage bot that has identified this change as breaking release (without assertions) testing on Fedora 33 x86-64. Can we get a quick fix or revert this change for now?FAIL: lldb-shell :: Reproducer/Functionalities/TestImageList.test (68782 of 69683) ******************** TEST 'lldb-shell :: Reproducer/Functionalities/TestImageList.test' FAILED ******************** Script: -- : 'RUN: at line 6'; /tmp/_update_lc/r/bin/clang --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-unknown-linux-gnu -pthread -fmodules-cache-path=/tmp/_update_lc/r/lldb-test-build.noindex/module-cache-clang/lldb-shell /home/dave/ro_s/lp/lldb/test/Shell/Reproducer/Functionalities/Inputs/stepping.c -g -o /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.out : 'RUN: at line 8'; rm -rf /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.txt : 'RUN: at line 10'; echo "CAPTURE" >> /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.txt : 'RUN: at line 11'; /tmp/_update_lc/r/bin/lldb --no-lldbinit -S /tmp/_update_lc/r/tools/lldb/test/Shell/lit-lldb-init -x -b --capture --capture-path /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.repro -o 'run' -o 'image list' -o 'reproducer generate' /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.out >> /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.txt 2>&1 : 'RUN: at line 17'; echo "REPLAY" >> /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.txt : 'RUN: at line 18'; /tmp/_update_lc/r/bin/lldb --no-lldbinit -S /tmp/_update_lc/r/tools/lldb/test/Shell/lit-lldb-init -x -b --replay /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.repro >> /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.txt 2>&1 : 'RUN: at line 20'; cat /tmp/_update_lc/r/tools/lldb/test/Reproducer/Functionalities/Output/TestImageList.test.tmp.txt | /tmp/_update_lc/r/bin/FileCheck /home/dave/ro_s/lp/lldb/test/Shell/Reproducer/Functionalities/TestImageList.test -- Exit Code: 1 Command Output (stderr): -- clang-12: warning: argument unused during compilation: '-fmodules-cache-path=/tmp/_update_lc/r/lldb-test-build.noindex/module-cache-clang/lldb-shell' [-Wunused-command-line-argument] -- ******************** Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. ******************** Failed Tests (1): lldb-shell :: Reproducer/Functionalities/TestImageList.test Testing Time: 125.54s Unsupported : 10774 Passed : 58806 Expectedly Failed: 102 Failed : 1 FAILED: CMakeFiles/check-all