- User Since
- Feb 12 2014, 9:18 AM (474 w, 5 d)
Dec 15 2016
@jingham, there may be some reconciliation needed between here and swift-lldb.
Looks reasonable to me.
This one needs more analysis.
Dec 12 2016
Nov 29 2016
I think this is a great approach. LGTM!
Nov 28 2016
Nov 18 2016
Thanks for working up the alternate solution, Mehdi!
Nov 16 2016
LGTM! All tests passed on macOS 10.12.2 public beta with Xcode 8.1.
I'm going to test this one now, stacked on top of the final macOS-working version of D26698. Tell me now if you want it tested independently of D26698.
Here is the adjusted patch that fixes the issue I was seeing on TestTerminal.py. My first set of changes had a lifetime issue where I needed a const char* that was synthesized on the fly and went away by the time I needed it.
TestTerminal.py's test_launch_in_terminal() is timing out consistently with the current change + my diff attached above.
Nov 15 2016
I can give this one a run though on macOS in the morning.
I can run this through in the morning on macOS.
Nov 14 2016
LGTM. Built and passed all existing tests.
I will give this a run a bit later this morning. Should be no later than early afternoon.
Nov 11 2016
Nov 10 2016
Looks fine to me pending that one question on the TSAN check (i.e. if the existing TSAN check is as good as your new ASAN check, LGTM).
Adding Jim, as I just want one of him or Greg to review.
Nov 9 2016
Looks good, @beanz!
Adjusted web docs.
Making changes to the text...
Nov 8 2016
Looks good, Tim!
Nov 1 2016
Can I have some background? What is the linking problem?
I'll let Greg comment on the public ABI expansion (i.e. including llvm of a specific version, which may differ from LLDB.framework clients that contain different versions of LLVM). My guess is this is not going to work for us, since we have long-lived frameworks shipped with Xcode that get used by clients where we cannot assume what they are or are not using. However, we could address that by adding the reverse flag, which would be "don't export LLVM", and have that be exported by default.
Oct 31 2016
Oct 29 2016
Here's what you get with the same codebase, but using this cmake line instead:
cmake -GNinja ../llvm -DCMAKE_BUILD_TYPE=Debug -DLLDB_EXPORT_ALL_SYMBOLS:BOOL=YES
Could you elaborate on this?
Sure, I'll see if I can reproduce the lack of backtrace symbol lookup that I was experiencing without exporting those symbols back in roughly Oct/Nov 2015. We've been using this flag ever since to address it.
I've been debugging lldb without this switch and everything seems to work fine
That definitely was not my experience when I added the flag. I am seeing if the old scenario holds true on 16.04 x86_64 with the current LLDB codebase. It is possible that the issue we saw manifest has been addressed.) I will make a best effort attempt this weekend, but it may be more like Monday when I will have dedicated time to repro it. If it is no longer an issue, I'd consider this flag deprecated as its initial purpose is no longer valid. If it is still an issue, it could be a config difference between stock Ubuntu and your setup (as we know is at least the case with kernel settings).
(modulo problems evaluating fancy expressions, but I don't think that is related to this. Or is it?).
At the time the issue was symbol lookup - we were somewhere short-circuiting so that we didn't consider debug symbols properly. While I didn't try it at the time as I wasn't aware of it, it is possible the issue may be related to needing the -fno-limit-debug-info flag. When I get to reproducing the original issue, if it does surface, I will try adding that flag as a second step to see if that addresses it.
For expressions that need to evaluate any symbols we were failing to resolve, I could imagine that being at least one factor. Not sure though without a specific case to look at.
More later when I have some results.
Oct 28 2016
I'm at a loss for the workflow to close this. I originally commandeered it to do an abort on it, but that didn't work. I'm going to abandon it, and see if I can kill it then.
The reason why it doesn't blow up in the hidden case is that liblldb.so has already internally resolved the storage, doesn't involve dynamic resolution, and has its own data location. Ditto for lldb-mi's copy. So they are separate islands.
Oct 25 2016
I am not that excited by this, but I don't see a much better way to achieve the result. :)
Possibly I'd consider making the variable name positive (instead of CFLAGS_NO_DEBUG, have a INCLUDES var, and then the test can use $(INCLUDES) $(TRIPLE_CFLAGS)).
Oct 24 2016
Oct 21 2016
@beanz and I discussed. This isn't needed here at all. The issue is entirely in the current manifestation of the GitHub side of swift-lldb.
Oct 20 2016
(It would be good to wait for feedback from the others, though).
Oct 18 2016
This seems fine, but @labath might want to weigh in if Android tools have a hard-baked assumption anywhere on lldb-launcher.
Yep, looks right. We shouldn't be assuming the shell.
Oct 13 2016
Okay. I think we need a minor tweak, to drop the REQUIRED on the Backtrace usage.
(Retro) Ah nice, I like the generator expression you put in there.
(Retro) yep, this looked fine.
Oct 11 2016
Oct 6 2016
Oct 5 2016
Oct 4 2016
Oct 3 2016
I also just added a test case to validate we get a non-None answer to test instance self.id() calls. We use it in several places, so might as well make that explicit.
Much better. I see you found test.id(), which gets the module.class.test_method setup. That will be unique.
That works fine.
I'm getting one test crash (segfault) in logging/TestLogging.py:
I will test this on macOS. I will have the results this afternoon.
@zturner , Greg is out this week (and was last Friday as well).
What is the motivation for this change? It looks like the existing code works based on file names, which are required to be unique in the system. It looks like you're attempting to move it over to a classname.method scheme. Is that right? If so, classname.method is not guaranteed to be unique, either. It would have to include the module name, which is essentially the file name, which is required to be unique. (Maybe when you said <TestCase>.<TestMethod>, your <TestCase> element is fully qualified, including the module name? If so, then that should be guaranteed to be unique).
Sep 30 2016
Sep 28 2016
Sep 27 2016
Sep 26 2016
BTW, regarding this part: