Evan Teran
Evan Teran
There are a few things here, so they'll be addressed individually: ``` It should highlight different stack frames with different background colors, so that you easily see which things belong...
Heh, no they don't :-P. Either way, the current status of that part is "works like every other debugger, so won't fix"
So this bug currently basically boils down to two issues worth discussion: 1. logarithmic scrolling for large data/stack regions 2. stack frame outlining. The second is a effectively dupe of...
So, I think the way to do this most "correctly" would be do the following: 1. allocate a new page in the foreign process, probably by forcing a `mmap` call...
Good point, we'd probably want to find some pointer which is the most "fundamental" to work with then
@AaronOpfer yes, we do and that will cover setting environment variables for a process we are about to start. When I first wrote this FR, I was thinking more along...
The analyzer already does an MD5 of every region it analyzes (in particular to detect changes), so that could be used directly. Fortunately, it hasn't proven to be particularly time...
I think the first step in this, would be the make the analysis data store addresses relative to the module/region base instead of absolute like it is currently. That would...
Sure, that would work equally well.
Well, I think that will generally be a problem for any solution that is based on "did the data in this region change". I am of course open to alternatives....