not sure how this will be useful: the debugger will flag the exception
when it happens, and in Xcode anyway, you can invoke fix-and-continue
and move without starting over (I've actually never tried it, but from
what I read).
Peter
On 4/9/07, William Squires <[EMAIL PROTECTED]> wrote:
> Okay, I just had an LED moment (light bulbs are so passe' now...)!
> What if you could use the other Intel Core 2 Duo processor to
> mirror/emulate the other when debugging a program?
> Clearly, both processors are the same, right? So what if you could
> use the 2nd processor to 'pre-step' into a line of code and see if it
> blows up BEFORE you execute the same line of code on the 1st
> processor? For example, take the following C bit of code...
>
> #include <stdio.h>
>
> int main(int argc, char *argv[])
> {
> int *ptr, myArray[0, 1, 3, 2];
>
> init(); // some sort of setup
> ptr = myArray;
> // deliberate bug here...
> ptr++;
> while (*ptr)
> {
> printf("*ptr = %d\n", *ptr);
> printf("ptr = %x\n", ptr);
> ptr++;
> }
> }
>
> While we know this will blow up (it'll step off the end of
> 'myArray'), the computer doesn't... until its too late. But let's
> step into this using our fictitious, new version of gdb. We step up
> to the first "ptr++;" line. So far, so good. Now we single-step over
> it. Both processors execute the instruction, but - while the first
> stops, the second one goes ahead and pre-executes the next
> instruction for us (while (*ptr), to be exact.) Again, so far, so good.
> We now step through the loop a few times. Once the 2nd "ptr++;"
> line executes the third time, gdb will now present us with a warning
> before stepping back to the while statement:
>
> **gdb: EXC_NO_ACCESS will occur on next statement unless *ptr
> modified to point into 'myArray'.**
>
> Now we can see what the machine (processor) state is BEFORE it
> blows up, not just after (when we get the "Your Application has
> crashed..." dialog, and its core dump.) Of course, this could be
> extended to pre-execute any number of machine instructions (those
> making up a line of RB code, for example...), stopping as before on
> the statement prior to the problem.
> Another advantage: since the processor mirrors the other, we can
> dump its locals/call stack/etc... without modifying the one in the
> main processor (in other words, we can measure without disturbing
> what we're measuring.)
> Anyway, just dreaming... carry on.
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
>
--
-------------------------------------------------------------------------------
Peter K. Stys, MD
Professor of Medicine(Neurology), Senior Scientist
Ottawa Health Research Institute, Div. of Neuroscience
Ottawa Hospital / University of Ottawa
Ontario, CANADA
tel: (613)761-5444
fax: (613)761-5330
http://www.ohri.ca/profiles/stys.asp
-------------------------------------------------------------------------------
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
