I have set a breakpoint which should print a pointer and then continue, because I don't want to stop there.
bu 410cc8 ".printf \"Class: %08lX Filebuffer: %08X\\n\", eax, edx; g"
The problem with this is now, when I singlestep and such a breakpoint is fired, like here:
1 mov eax, [ebp+var_10]
2 lea edx, [eax+2Ch]
3 mov eax, ebx
4 call ReadFileFkt_2
5 mov eax, [ebp+var_10]
So when I'm on line 4, and step over it, the above breakpoint is fired and the message is printed. But then the debugger never comes back, because in the breakpoint I use "g" to continue, so the single step is erased.
If I don't use "g" then the breakpoint will be hit and the debugger stops there, so I have to track my way back to where I came from. Of course I could set a breakpoint after the call, but then I would have to remember doing this in other parts of the code as well, because I don't know when the breakpoint is fired from deep within some calling hierarchy.
Use 'gc' (go from conditional breakpoint) instead of 'g' (go).
This command was designed specifically for the problem you have.
Related
It says that Jump out of range by 60 bytes
To solve my problem.
Conditional jumps in 8086 Assembly (and most assembly languages) have a limited distance they can jump. In other words, there's too much code between your jump instruction and the destination (in this case, 60 bytes too many). You didn't post your code so I can't tell you exactly what line to fix, but in general the solution is straightforward.
cmp ax,bx
jnz goHere
; more code is here than the conditional jump will allow
goHere:
; finish up what we were doing
ret
In order to fix the above code, we have to reverse the condition and JMP, since JMP isn't as limited as Jxx is.
cmp ax,bx
jz continue:
jmp goHere
continue:
; finish up what we were doing
ret
goHere:
; now we can get here even though we have too much code for a conditional jump
jmp continue ;this will also have enough range to go there.
There's several ways to re-arrange your code to allow conditional jumps to work as intended, and still get the desired outcome. This is just one technique for it.
Today I was wondering why the GFlags option Stop on hung GUI appears in the Kernel Flags tab of the GFlags user interface. Does the kernel have a GUI which could hang?
So I tried to get some information from Microsoft, but MSDN just says:
The Stop on hung GUI flag appears in GFlags, but it has no effect on Windows.
So I wonder even more: a kernel flag for a kernel which has a GUI, but it's not the Windows kernel?
Although it seems not of practical use, can anyone explain this?
I also tried to get more information from WinDbg .hh !gflag, but it doesn't even give the statement that this won't work on Windows.
Kernel flag indicates flag takes effect immediately without requiring a reboot
Registry flag requires a reboot for the flags to take effect
the kernel does not have any gui that could hang.
the term windows doesnt mean kernel but the gui windows of the running application
check NtSetSystemInformation in your os to understand why 0x8 does not take effect
basically there are a few hardcoded magic numbers inside this api which tests each request for GlobalFlag changes and allows them or disallows them
in xp-sp3 this magic value is 0B2319BF0 so any flag that is < 0x10 will be disallowed
and stop on hung gui is 0x8 so it isnt effective and you cant set this from registry tab
so effectively no way of setting this flag
nt!NtSetSystemInformation+0x193:
80606009 8b03 mov eax,dword ptr [ebx] ds:0023:001285f8=00000008 <---- +shg
8060600b 25f09b31b2 and eax,0B2319BF0h < magic value in nt
80606010 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606013 8b0d6c125580 mov ecx,dword ptr [nt!NtGlobalFlag (8055126c)] ds:0023:8055126c=00000000
80606019 81e10f64ce4d and ecx,4DCE640Fh <--another magic value both these magic values orred together
will be 0xffffffff covers the whole range of flags
8060601f 0bc1 or eax,ecx
80606021 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606024 a36c125580 mov dword ptr [nt!NtGlobalFlag (8055126c)],eax ds:0023:8055126c=00000000
When I run Windbg and it hits a breakpoint, then it prints the number of the breakpoint which triggered it. When I use a conditional breakpoint, I would want to print this as well. Is there some variable that holds the breakpoint number which triggered?
Because when I some ".printf" in the breakpoint condition, then only the stuff that I specify is printed (which is fine), but I would want to know which one it was as well.
When you define your breakpoints you can specify the ID value, you can then .echo this as a command string:
bp 42 myDLL!myClass::foo ".echo 'breakpoint 42 hit!!!';gc"
You will then know for sure which of your breakpoints was hit.
Alternatively you can list the current breakpoints using bl and this will list the breakpoints and display the ordinal number (actually the ID that is assigned if you didn't specify it when defining the breakpoint).
You can use this ordinal number and redefine you breakpoint and .echo the ordinal number the sam way as above.
I'm writing a compiler for a course. I've run into some optimization issues of which I am unsure how to handle optimally. Suppose there is a while loop from the input language that uses N local variables which must be held in registers (or should be, for fast computations). Suppose N > K, the number of registers. There is a chance of the conditional register being changed near the end of the while loop.
For example, suppose the register for x (let's say %eax on i386) was determined before the following statement:
while ( x ) { x = x - 1 ; /* more statements */ }
In the more statements code, it is possible for x to be spilled back onto the stack. When the code jumps back to the beginning of the while loop to re-evaluate x, it will try to use %eax--but this may not even be holding the value of x now. So we could have something like
movl -8(%ebp), %eax # eax <- x
.... # do stuff but let x stay in %eax
_LOOP1: cmpl $0, %eax
....
movl -12(%ebp), %eax #eax now holds something else
....
jmp _LOOP1
One solution I'm using is to force the code to spill all modified registers before the while statement (so the registers are viewed as empty from the code generator's perspective). After the label for the while loop, the code has to load everything into a register as necessary.
My solution is something like this:
movl -8(%ebp), %eax # eax <- x
.... # do stuff but let x stay in %eax
movl %eax, -8(%ebp) # spilling and clearing all registers
_LOOP1: movl -8(%ebp), %eax # get a register for x again
cmpl $0, %eax
....
movl -12(%ebp), %eax # eax now holds something else
....
movl %eax, -8(%ebp) # spill to prevent overwrite
jmp _LOOP1
It seems like my solution is a little extraneous or unnecessary. Is there some general optimization trick I am forgetting here?
EDIT: I would also like to note something similar occurs for conditionals such as if and if else. This occurs for them because a register may be allocated for a variable inside the block for the conditional, but the code generator assumes it was moved in there for everything else after. I have almost the same approach for dealing with that case.
The general technique you're looking for here is usually called "live range splitting". A Google Search for that term will give you pointers to a bunch of different papers. Basically the idea is that you want to split a single variable (x in your example) into multiple variables with disjoint live ranges each of which gets copied to the next at the splitting point. So you'd have x.0 before the loop, which is copied into x.1 just before the while and used as that in the loop. Then right after the loop, you'd copy x.1 into x.2 and use that after the loop. Each of the split vars would be potentially allocated to a different register (or stack slot).
There are a lot of tradeoffs here -- too much splitting leads to (many) more variables in the code, making register allocation much slower, and potentially leading to unnecessary copies.
I'd like to create a breakpoint such that it will create another one-time breakpoint that will 'dd' a certain memory address when that memory is written to.
So when the breakpoint is hit, I'd like to run a command like:
ba w4 #ESP+4 /1 ''dd [memory address of this breakpoint]''
Since this breakpoint is being created by another breakpoint (and could potentially be called several times), I can't specify the breakpoint number. Otherwise I could use a pseudo register like '$bp3' to get the memory address of breakpoint #3
Would anyone have any thoughts on how to create a breakpoint command that can 'dd' the memory address of the breakpoint?
Thank you!
you can elaborate to make use of other general purpose pseudo-registers: t0..t19
bp your-address "r$t1=your-other-address; ba w4 #$t1 /1 \"dd #$t1;gc\""
If you know there will never be more than one "child" ba breakpoint defined, you can actually use a #$bpN pseudo-register by setting the "controlling" breakpoint's command to:
ba1 w4 /1 #esp+4 "dd #$bp1"
That is, specify the breakpoint number that that this new breakpoint should be assigned, and the pseudo-register for that breakpoint is still defined within the breakpoint's command.
However, if you think the controlling breakpoint will be hit multiple times and want multiple ba breakpoints defined, that obviously won't work because then "breakpoint 1" will just be redefined each time. But you can still do it!
The trick is to make the controlling breakpoint's command actually contain the literal address text rather than try to go through a pseudo-register. And you can do that with text aliases.
Try this for your controlling breakpoint:
bu #WHATEVER "aS /x ${/v:baaddy} #esp+4; .block{ ba w4 /1 baaddy \"dd baaddy\"; ad ${/v:baaddy} }"
When the controlling breakpoint is hit, the following happens:
An alias is setup for the text "baaddy" with the value of evaluating the expression #esp+4.
The .block ensures that alias expansion happens for what follows.
The alias interpreter will then expand all occurrences of "baaddy" within the block, except for in the ad command (because of the /v switch).
So if the value of #esp+4 is 0x1234 the access breakpoint command literally becomes: ba w4 /1 0x1234 \"dd 0x1234\" with the actual address embedded in it.
Then the text alias is deleted.
It's important to delete the text alias at the end or the next time this controlling breakpoint is hit, the alias expansion will happen before the aS command, and "baaddy" will be expanded using the previous value. That also means it's important that this text
alias does not exist the first time you set the controlling breakpoint's command.