- User Since
- Jun 4 2013, 6:02 AM (198 w, 2 d)
Does anyone object to me landing this? I am going to be careful and wait for the change to trickle through CI before submitting any followup changes.
Ah, that explains it, thanks.
Thank you for that.
BTW, thank you for adding the test. It's not obvious from the patch: how big are the core files?
Tue, Mar 21
I think you should group these "add netbsd to a list" type of changes into single diff. There's not point in reviewing each separately.
Heh... I did not expect it would get this small, but ok. :)
At one point we will need to come up with a better way to control these features.
I like the idea of adding boilerplate first, so that we can than better focus on the important stuff later. However, I think you've have gone a bit too far with it -- you introduce a lot of functions I am pretty sure will not be necessary for your case, or that should be handled differently (software single stepping stuff, handling of linux thread stopping, ...).
Mon, Mar 20
Looks like a great start. If you want to continue and get live process debugging working as well, you should definitely sync up with kamil (i.e. don't start from ProcessFreeBSD, his process plugin should be a much better starting point).
Fri, Mar 17
Cool. Nevermind me then.
I think you missed one occurence in ModuleCache.cpp. This one creates a full directory structure, so you will probably need recursion there (unlike in the rest of these cases, which seem fine). Also unlike the rest of these cases, that one is actually covered by a unit test, so you should be able to verify that. :)
Thu, Mar 16
Wed, Mar 15
looks good to me, but please give Greg a chance to respond first.
Tue, Mar 14
Ok, that makes sense. I guess we can pull FileSpec down to llvm if/when another user of the functionality comes up.
@zturner said (in email)
I actually think that should live in lldb. All of llvm's path handling code is stateless which makes the most sense from an api perspective. Lldb is just "special" in that regard
I've updated the code as suggested. For the "fudge factor" I chose one, so that
this at least works in the fairly common case where you put an empty line
between two tiny functions. The "breakpoint on return type" case should still
work as long as the retyrn type does not span multiple lines, which I think is a
Mon, Mar 13
Yes, that's what I meant. :)
I like the idea of using the function declaration line, as it will solve a couple of other corner cases also (we've had one user try to set a breakpoint on a macro definition and expect that to work). I'll try to implement that instead.
We need the getter code to get the name of the threads of the process we are debugging, so this cannot go away. It also probably does not make sense to move this code into llvm, as it is quite debugger-specific and very unportable.
Lldb has a copy of a part of this code with the same type of #ifdef -> if changes applied, so it would be great it we could get rid of that.
Fri, Mar 10
Seems very reasonable. A couple of details I noticed are in the inline comments.
Thu, Mar 9
looks good to me, thank you for the patience. BTW I accidentally stumbled onto this https://docs.python.org/2/library/os.path.html#os.path.expanduser yesterday, so it looks like supporting tilde expressions on windows is not without precedent.
Wed, Mar 8
Sounds reasonable to me, but I'd wait for others' opinion.
I've repurposed the stream mutex to protect the entirety of enable/disable
operations. To make this flow better, I've also gotten rid of the LogAndChannel
struct and make Channel a member of Log directly (which required moving some
declarations from the cpp file to the header).