Any way to make Windbg to break when a specific value is assigned to the eax register? I know one of the functions in my program is returning an specific error, it would be very fast to find the guilty this way.
You can set a breakpoint on all your suspect functions and then check the eax register value like so:
bp myAddress ".if (#retreg == dodgyVal) {walk the stack and do other cool stuff} .else {gc}"
See conditional breakpoints and also pseudo-register syntax for available register values
Related
I think the correct description for what I'm trying to do is be able to pass an expression or function/handler into another handler as a parameter/argument. Some code to be evaluated inside the receiving handler. Similar to Javascript callbacks, I think.
For example, something like this:
on waitFor(theConditionExpression)
timeout_start(5) -- start a 5 second timer
repeat until (theConditionExpression or timeout_isExpired())
delay 0.1
end repeat
return theConditionExpression
end waitFor
theConditionExpression should be some expression or function that evaluates to a boolean result.
not really relevant to the question, but just FYI, timeout_start(…) and timeout_isExpired() are two simple handlers I've written that do exactly what they say. (…start() doesn't return anything, …isExpired() returns a boolean).
Of course, typically if I pass in some boolean expression, it will evaluate that expression once, at the time I pass it in. But I want it to evaluate it every time it's referenced in the code inside the handler.
Some languages (not sure about AS) have some kind of eval() function that you can pass it some code as a string and it will execute that string as code. Theoretically that could solve this, but: (a) I don't know if AS has anything like that, but even if it does, (b) it's not desired for various reasons (performance, injection risks, etc.)
So I'm thinking something more like eg. JavaScript's ability to pass in a function (named or anonymous) as function parameter/argument that can be re-evaluated every iteration in a loop, etc. (eg. like the compareFn argument in JS's Array.sort(compareFn)).
Can AS do anything like this, and if so how?
Thanks!
I'm going to suggest (pro forma) that an AppleScript application with an on idle handler is generally a better solution for wait conditions than a repeat/delay loop. It's more efficient for the system, and doesn't freeze up the script. But that would involve reconceptualizing your script, and I'm not certain it would work in this case, given the way you formed the problem.
There's an old but good site called AppleScript Power Handlers that shows a bunch of nifty-neato tricks for sophisticated use of AppleScript handlers: passing handlers as values or parameters; creating Script Objects within handlers; making closures and constructors. I'm pretty sure the answer to your request is in there. aLikely you'll want to set up a bunch of handlers that serve as condition expressions, then pass them as parameters to the evaluating handler. Or maybe you'll want to set up a script object containing the condition handlers and call it as needed?
At any rate, see what you can do with it, and ask more specific questions if you run into problems.
In the following RISC-V assembly code:
...
#Using some temporary (t) registers
...
addi a7,zero,1 #Printint system call code
addi a0,zero,100
ecall
...
Should any temporary (t) registers be saved to the stack before using ecall? When ecall is used, an exception occurs, kernel mode is on and code is executed from an exception handler. Some information is saved when exceptions occur, such as EPC and CAUSE , but what about the temporary registers? Environment calls are considered not to be like procedures for safety reasons, but they look like it. Do the procedure calling conventions still apply in this case?
You are correct that the hardware captures some information, such as the epc (if it didn't the interrupted pc would be lost during transfer of control to the exception handler).
However that's all the hardware does — the rest is up to software. Here, RARS is providing the exception handler for ecall.
RARS documentation states (from the help section on syscalls, which is what these are called on MIPS (and RARS came from MARS)):
Register contents are not affected by a system call, except for result registers as specified in the table below.
And below this quote in the help is ecall function code table labeled "Table of Available Services", in which 1 is PrintInt.
Should any temporary (t) registers be saved to the stack before using ecall?
No, it is not necessary, the $t registers will be unaffected by an ecall.
This also means that we can add ecalls to do printf-style debugging without concern for preserving the $t registers, which is nice. However, keeping that in mind, we might generally avoid $a0 and $a7 for our own variables, since putting in an ecall for debugging will need those registers.
In addition, you can write your own exception handler, and it would not have to follow any particular conventions for parameter passing or even register preservation.
I'm currently trying to learn some basis for a bigger project that will make a massive use of simulink.
Right now, I would like to code my own simulink block whith a feedback. It means that one of the inputs is also the output (with a 'memory' block between them to ensure everything goes right!).
My code looks like
function out = func(cmd,in)
if in == 0 && cmd == 1
out = 1;
elseif in == 1 && cmd == 0
out = 0;
else
disp('error')
end
As I said, 'in' is linked to 'out'. Unfortunatly, it is required to set an initial value for out otherwise I get some errors. Of course I can't do it in the code like that :
out = 0;
In that case, the value 'out' is set to 0 at each time step.
Have you any advice to do it ? I've read that S-functions and flag could be used, but I have no idea how it works.
Your function gets called during model initialization (t=0), and the value of out will be calculated based on the value of cmd and in value at t=0.
Hence you need to make sure cmd and in are initialized correctly you shouldn't be setting a value explicitly for out.
If you really need to (which you won't) then the simplest thing to do is use an Initial Condition block after this block.
Note that the above is only applicable to a block that has no states, as with your example. For your bigger project, you may have custom written blocks with states, in which case the approach to setting initial conditions for the states is different depending on whether you are using a MATLAB Function block or an S-Function.
Finally, note that if you want an error to be thrown then throw an error in the usual MATLAB way. Using disp as you are doing doesn't stop the simulation, but you haven't set a value for out, which is bad coding.
Well, I think that I've solve that issue. I put it here, I could help someone else
by adding a clock and initialize out with an if statement if time <=0 out = ...
However, it requires to add an extra input, which is not very convinient. Maybe someone could tell me how to solve that.
do the if properly and terminate it by else out = in;
I belive that was the main problem here. I've also placed my matlab-function block in a subsystem with a mask that initializes in and cmd.
Thanks again for your help, it helped a lot.
However, my problem is still unsolved since the statement if t<0 doesn't work for some reason.
I know that a variable value can be changed in the debug mode of Eclipse. But can I make that change happen every time a certain line is getting executed?
What I want to do is to make the change every time without manually having to do it.
If I got you right, I might have a solution that suits your needs here (or at least "might have suited", for I must admit this thread is pretty old by now ... ;-):
I had a similar issue this morning, detouring a "mailTo" (just a variable holding the recipients adress). I came to use a conditional breakpoint with the following condition:
"42" != (mailTo = "a#bc.de")
You always hit the breakpoint because "42" (or whatever value ;-) will never be equal to the assignment on the right - which yet does the main-job here.
Its also possible to make it "really conditional" (if needed) by using {real condition} && {fake condition} (because the fake is then depending on a preceding 'true')
In Eclipse, is there a way to disable a breakpoint until another breakpoint is hit first?
This is a big hack, but it is a functional workaround:
Call the 'trigger' location breakpoint 1 and the target location breakpoint 2. We want breakpoint 2 to fire if-and-only-if execution has passed breakpoint 1.
Set conditional breakpoints at each.
For breakpoint 1, set the condition as System.setProperty("breaknow", "breaknow") == "". This condition will never be true, but will set a system property which we can read at breakpoint 2.
For breakpoint 2, set the condition as System.clearProperty("breaknow") != null. This condition will trigger when the system property is set, and also clear it (so we can repeat if needed).
As I said, it's a hack, but it seems to work. I submitted an Eclipse enhancement request to implement linking or chaining breakpoints as a native feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=390590). Unfortunately, I don't have bandwidth to implement it myself, but perhaps we'll get support for a cleaner solution someday.
One caveat (which applies to all conditional breakpoints, not just to this trick): From my experience, it appears that a setting a conditional breakpoint prevents the JIT from compiling the method of interest, running it in interpreted mode instead. Or perhaps, it allows the first C1 JIT stage but prevents the second-stage C2 compiler from optimizing?
In either case, you should be aware that the method you’re debugging will run considerably slower with a conditional breakpoint in place. This isn’t usually a problem, but when debugging very tight inner loops, I’ve found it better to fall back to the (sloppy) if (x) { // Do somthing useless and set a breakpoint here} method.
No. But you can have conditional breakpoints. I guess that hitting the other breakpoint indicates some change of state.
So, Right click the breakpoint -> Breakpoint properties -> check "conditional"
If you know the condition at which the other break point will be hit, then you can add that condition to the new breakpoint.
Conditional breakpoints are one possibility, and you can also set a Hit Count so that the breakpoint is only triggered after being hit the specified number of times.
But no, there is no way to do what you are asking.
Another idea is to disable your breakpoint and enable it once the other breakpoint is hit.