User Details
- User Since
- Sep 2 2014, 12:05 PM (402 w, 5 d)
Fri, May 20
Ah, good catch!
Mon, May 16
Update to address Jonas' comments.
Sat, May 14
Thu, May 12
Yeah, you're right. And as I walk through in my head what I'm solving with this -- it's not the really expensive part of this whole operation, I don't think. I should check more carefully but it's the stat's over NFS partitions that are impacting performance, and I doubt the realpath() to expand the tilde's is a significant factor (the kernel should cache all of these inodes anyway if we're doing it in a hot fashion). I'll probably abandon this altogether unless I can prove to myself that it's important, and hoist it into the base class.
This is a nice piece of work, and a good cleanup, LGTM.
Thu, May 5
update to incorporate dave's suggestions.
Accidentally included an unrelated change in the last update.
Update to address Greg's feedback.
Wed, May 4
Ah, I can't share the binary/corefile that led me to this issue but I can show what it looks like. I have a function with a noreturn call, it's a crashing scenario where (as always) this is the most important bit to get right, to show the crash,
Tue, May 3
LGTM. I see how your workflow is set up. Yeah, you return an error if someone tries to run debugserver in translation (and the inferior isn't x86_64) - that's what we need to do, a translated debugserver won't be able to debug arm64 processes.
Mon, May 2
(tbh every case I've seen, it's someone who checked "Run in Rosetta" on the Xcode.app bundle with Finder, and are running their entire IDE as x86_64....)
Ah, I see what you're doing. You've got a shell running x86_64 or something (maybe started lldb as x86_64) so everything that is spawned from that is x86_64 -- debugserver and the inferior process -- and so you hit this. let me look more closely later tonight, but I didn't take that scenario into account. Normally when people are running debugserver as x86_64 it's because they unintentionally ran a parent as x86_64 and are paying an unintended perf hit across the debug session and part of this error reporting was to say "hey, you probably didn't mean to do this".
Fri, Apr 29
Thu, Apr 28
cleanup patch to remove an unintended diff.
Tue, Apr 26
Thanks! Yeah, I only noticed because lldb-dotest threw an error when I was trying to run a test case earlier.
Hi, I noticed that we have two tests with the same name,
Mon, Apr 25
Hi all, getting back to this one after six months, hah. Reading through Jim's thoughts on this, I think we're OK to add this refinement. Tatyana also thought that removing this altogether would be an option, but this has been sitting unfixed for a while and I'd like to land the fix to it. Jim wishes for a world where HandleCommand requires an SBExecutionContext, or one in which we had an established way of deprecating old SB API. Given that we can't address that at the moment, I'm going to land this patch finally so we're not carrying the problem around for the foreseeable future.
Apr 21 2022
I guess the other comment I would make is whether we should have a new ivar, instead of using the unused 0th bit of search_offset.
This is obviously building on Pavel's work of https://reviews.llvm.org/D66638 for Win32 systems. What problem with that existing patchset is this addressing? Pavel's original patch assumes that we can retrieve a function's expected stack frame size, and the size of the caller's arguments on the stack, plus a bit of searching around that location, as he describes. It seems like in ABIWindows_x86_64::CreateStackWalkingUnwindPlan you're adding a scheme that tries to look at the area directly around $sp for a return pc? This seems quite fragile by itself.
Apr 14 2022
LGTM.
Apr 12 2022
Sounds good. I think it's test-and-use for lldb, and debugserver ended up structure the same way.
fwiw,
commit 681f6c2f552fb9b57380f4bfd453e1fc9b6a099e Author: Jason Molenda <jmolenda@apple.com> Date: Tue Dec 18 22:21:48 2018 +0000
I think we only support building debugserver on macOS systems that have libcompression. Was there a configuration where this resulted in an error? lldb needs to test for libcompression and use it if available, but with debugserver we assume it is available iirc. I'm fine with the patch, but I'm curious how it came up. It used to be tested before use etc but I removed that a couple of years ago when our minimum deployment target was high enough that it was always available.
Apr 6 2022
Apr 5 2022
Apr 4 2022
LGTM but unobfuscated is a uint64_t, does this cast do anything now?
Update patch to remove unnecessary temporary std::string when dumping a string into its JSON representation.
Apr 1 2022
Mar 31 2022
Address Jonas' feedback by removing the parts of the patch that freed the ostringstream's after binary-escaped versions of them had been generated. Instead I'll add DumpEscaped methods to the JSONGenerator class.
I was chatting with Jonas about this a bit. The part of this patch which fixes all of the SendPacket(outbuf.c_str()) calls, to avoid a temporary copy of the std::string, is clearly necessary and correct. The changes to clear the ostringstreams eagerly after we've escaped the data is noisy, and I'll remove those and look at updating JSONGenerator to print escaped string representations directly, to eliminate the unescaped copy & the escaped copy duplication. I'll update the patch in a bit.
Mar 24 2022
Mar 23 2022
Ah, good catch. Yes this looks correct to me.
Mar 21 2022
LGTM.
Mar 10 2022
Ach, that's unfortunate. So a caller can allocate space for the return object, pass that address to a callee in x8, but when callee returns, x8 has been overwritten. Agree that this is the only right way to behave.
Mar 2 2022
Mar 1 2022
Integrate Jonas' suggestion, update the disassemble shell test to match the new error messages.
Feb 25 2022
Feb 24 2022
Feb 22 2022
Feb 21 2022
Nice. tbh when I'm SB API scripting, I am often sitting in include/lldb/API and grepping for keywords, because I can't remember exactly which class provides the API, or what arguments it takes or whatever.
Feb 14 2022
Feb 11 2022
Fix typeo in comment.
Feb 7 2022
Feb 4 2022
Update to address Jonas' feedback.
Feb 3 2022
Feb 2 2022
FWIW I started updating my implementation by reading through all the changes to the docs, and implementing them. Then I went back and looked at the patches and found some small changes that were made but without documentation being updated, or the documentation not being specific about expected details.
Jan 14 2022
I see what you're doing, yeah, this makes sense. Sometimes with firmware debugging, we pick a random platform (basically) and this might change which platform gets picked, host versus remote-ios, but I don't think it will matter for them.