Step-out seems to be broken in Simics 2021.24. I did "enable-debugger" but it still doesn't work. Please see below:
simics>
[board.mb.cpu0.core[0][0]] cs:0x00000000def963ae p:0x0def963ae sbb rax,rax
sbb rax,rax
cs:0x00000000def963ae p:0x0def963ae sbb rax,rax
cs:0x00000000def963b1 p:0x0def963b1 and rax,rcx
cs:0x00000000def963b4 p:0x0def963b4 mov rdi,qword ptr [rsp+0x8]
cs:0x00000000def963b9 p:0x0def963b9 ret
cs:0x00000000def963ba p:0x0def963ba mov rcx,r11
cs:0x00000000def963bd p:0x0def963bd lea rax,[r9-0x1]
cs:0x00000000def963c1 p:0x0def963c1 shr rdx,cl
cs:0x00000000def963c4 p:0x0def963c4 cmp rdx,rax
cs:0x00000000def963c7 p:0x0def963c7 jb 0xdef96363
cs:0x00000000def963c9 p:0x0def963c9 sub rdx,r9
simics> step-out
simics> da %rip 10
cs:0x00000000def963ae p:0x0def963ae sbb rax,rax
cs:0x00000000def963b1 p:0x0def963b1 and rax,rcx
cs:0x00000000def963b4 p:0x0def963b4 mov rdi,qword ptr [rsp+0x8]
cs:0x00000000def963b9 p:0x0def963b9 ret
cs:0x00000000def963ba p:0x0def963ba mov rcx,r11
cs:0x00000000def963bd p:0x0def963bd lea rax,[r9-0x1]
cs:0x00000000def963c1 p:0x0def963c1 shr rdx,cl
cs:0x00000000def963c4 p:0x0def963c4 cmp rdx,rax
cs:0x00000000def963c7 p:0x0def963c7 jb 0xdef96363
cs:0x00000000def963c9 p:0x0def963c9 sub rdx,r9
Likewise "step-over-instruction" doesn't seem to step over calls, it steps into them...
simics> step-over-instruction
call rax
cs:0x00000000dee41d19 p:0x0dee41d19 call rax
cs:0x00000000dee41d1b p:0x0dee41d1b jmp 0xdee41d2d
cs:0x00000000dee41d1d p:0x0dee41d1d mov rax,qword ptr [rip+0x265bc]
cs:0x00000000dee41d24 p:0x0dee41d24 mov rcx,rbp
cs:0x00000000dee41d27 p:0x0dee41d27 call qword ptr [rax+0xf8]
cs:0x00000000dee41d2d p:0x0dee41d2d cmp si,r13w
cs:0x00000000dee41d31 p:0x0dee41d31 jb 0xdee41ced
cs:0x00000000dee41d33 p:0x0dee41d33 mov r13d,0x400
cs:0x00000000dee41d39 p:0x0dee41d39 mov eax,dword ptr [rbx+0x114]
cs:0x00000000dee41d3f p:0x0dee41d3f sub eax,0x10
simics> step-over-instruction
sub rsp,0x28
cs:0x00000000dee39160 p:0x0dee39160 sub rsp,0x28
cs:0x00000000dee39164 p:0x0dee39164 test rdx,rdx
cs:0x00000000dee39167 p:0x0dee39167 je 0xdee39179
cs:0x00000000dee39169 p:0x0dee39169 mov rax,qword ptr [rip+0x1b58]
cs:0x00000000dee39170 p:0x0dee39170 mov rcx,rdx
cs:0x00000000dee39173 p:0x0dee39173 call qword ptr [rax+0xf8]
cs:0x00000000dee39179 p:0x0dee39179 add rsp,0x28
cs:0x00000000dee3917d p:0x0dee3917d ret
cs:0x00000000dee3917e p:0x0dee3917e int3
cs:0x00000000dee3917f p:0x0dee3917f int3
simics> print -x %rax
0xdee39160
So you can see it called to where rax was set, instead of stepping over the call.
both the step-out and step-over-instruction requires debug information. You can add debug information with add-symbol-file.
If you don't have the debug information, you will have to set a breakpoint or run until the instruction after the call. In this case, that would be one of:
bp.memory.run-until -x address = p:0x0dee41d1b
or
bp.memory.break -x address = p:0x0dee41d1b
c
#IAmIntel
Related
The String type is Swift has a property named isEmpty that indicates whether a string has no characters.
I'd like to know if there's any difference between using isEmpty and checking the equality to an empty string literal. In other words, is myString.isEmpty any better than myString == ""?
I did some research and came across the following recommendations:
String struct reference at Apple developer documentation (as well as the Swift Language Guide) recommends using isEmpty instead of checking the string's length:
To check whether a string is empty, use its isEmpty property instead of comparing the length of one of the views to 0. Unlike with isEmpty, calculating a view’s count property requires iterating through the elements of the string.
Answer to a slightly different question from 2015 on StackOverflow by Rob Napier states the following:
The empty string is the only empty string, so there should be no cases where string.isEmpty() does not return the same value as string == "". They may do so in different amounts of time and memory, of course. Whether they use different amounts of time and memory is an implementation detail not described, but isEmpty is the preferred way to check in Swift (as documented).
Some blog posts also recommend using isEmpty especially instead of checking if the string's length is 0.
None of these sources however say anything against comparing with an empty literal.
It seems totally reasonable to avoid constructions like myString.count == 0 because of obvious performance and readability drawbacks. I also get the fact that myString.isEmpty is more readable than myString == "".
Still, I'm curious whether the comparison with an empty string literal is bad. Does it really have any memory or performance implications? Perhaps the Swift compiler is so smart these days that it will produce the same binary code for myString.isEmpty and myString == ""? My gut feeling is that the difference should be negligible or even non-existent but I don't have proofs.
I realize it's not really a practical question though, however I'll be grateful if someone could share some insights how these two alternatives work on a lower level and whether there are any differences. Thank you all in advance.
As a note, isEmpty is the preferred/recommended method to check the emptiness of a collection, as all Collection types guarantee that isEmpty returns in O(1) (or at least this holds for the standard library collections). The equality operator make no such guarantees, thus if you're only interested about the collection having or not having elements (e.g. to launch a processing operation), then isEmpty is definitively the way to go.
Now, to see what's happening under the hood when using isEmpty vs when comparing to an empty string, we can use the generated assembly.
func testEmpty(_ str: String) -> Bool { str.isEmpty }
results in the following assembly code:
_$s3CL29testEmptyySbSSF:
0000000100002c70 push rbp
0000000100002c71 mov rbp, rsp
0000000100002c74 mov rax, rsi
0000000100002c77 shr rax, 0x38
0000000100002c7b and eax, 0xf
0000000100002c7e movabs rcx, 0xffffffffffff
0000000100002c88 and rcx, rdi
0000000100002c8b bt rsi, 0x3d
0000000100002c90 cmovae rax, rcx
0000000100002c94 test rax, rax
0000000100002c97 sete al
0000000100002c9a pop rbp
0000000100002c9b ret
while
func testEqual(_ str: String) -> Bool { str == "" }
generates this:
_$s3CL29testEqualySbSSF:
0000000100002cd0 push rbp
0000000100002cd1 mov rbp, rsp
0000000100002cd4 movabs rcx, 0xe000000000000000
0000000100002cde test rdi, rdi
0000000100002ce1 jne 0x100002cec
0000000100002ce3 cmp rsi, rcx
0000000100002ce6 jne 0x100002cec
0000000100002ce8 mov al, 0x1
0000000100002cea pop rbp
0000000100002ceb ret
0000000100002cec xor edx, edx ; XREF=_$s3CL29testEqualySbSSF+17, _$s3CL29testEqualySbSSF+22
0000000100002cee xor r8d, r8d
0000000100002cf1 pop rbp
0000000100002cf2 jmp imp___stubs__$ss27_stringCompareWithSmolCheck__9expectingSbs11_StringGutsV_ADs01_G16ComparisonResultOtF
; endp
Both assemblies are generated in the Release mode, with all optimizations enabled. Seems that for the isEmpty call the compiler is able to take some shortcuts since it knows about the internal String structure.
But we can take that away by making our functions generic:
func testEmpty<S: StringProtocol>(_ str: S) -> Bool { str.isEmpty }
produces
_$s3CL29testEmptyySbxSyRzlF:
0000000100002bd0 push rbp
0000000100002bd1 mov rbp, rsp
0000000100002bd4 push r13
0000000100002bd6 push rax
0000000100002bd7 mov rax, rsi
0000000100002bda mov rcx, qword [ds:rdx+8]
0000000100002bde mov rsi, qword [ds:rcx+8]
0000000100002be2 mov r13, rdi
0000000100002be5 mov rdi, rax
0000000100002be8 call imp___stubs__$sSl7isEmptySbvgTj
0000000100002bed add rsp, 0x8
0000000100002bf1 pop r13
0000000100002bf3 pop rbp
0000000100002bf4 ret
; endp
, while
func testEqual<S: StringProtocol>(_ str: S) -> Bool { str == "" }
produces
_$s3CL29testEqualySbxSyRzlF:
0000000100002c00 push rbp
0000000100002c01 mov rbp, rsp
0000000100002c04 push r14
0000000100002c06 push r13
0000000100002c08 push rbx
0000000100002c09 sub rsp, 0x18
0000000100002c0d mov r14, rdx
0000000100002c10 mov r13, rsi
0000000100002c13 mov rbx, rdi
0000000100002c16 mov qword [ss:rbp+var_28], 0x0
0000000100002c1e movabs rax, 0xe000000000000000
0000000100002c28 mov qword [ss:rbp+var_20], rax
0000000100002c2c call _$sS2SSysWl
0000000100002c31 mov rcx, qword [ds:imp___got__$sSSN]
0000000100002c38 lea rsi, qword [ss:rbp+var_28]
0000000100002c3c mov rdi, rbx
0000000100002c3f mov rdx, r13
0000000100002c42 mov r8, r14
0000000100002c45 mov r9, rax
0000000100002c48 call imp___stubs__$sSysE2eeoiySbx_qd__tSyRd__lFZ
0000000100002c4d add rsp, 0x18
0000000100002c51 pop rbx
0000000100002c52 pop r13
0000000100002c54 pop r14
0000000100002c56 pop rbp
0000000100002c57 ret
; endp
Similar results, the isEmpty code results is less assembly code, which makes it faster.
I'm inspecting a 64-bit executable using WinDbg(AMD64).
This is the assembly code that I'm assembling using ML64 to create my executable:
_data SEGMENT
b DWORD 0
a DWORD 0
_data ENDS
_text SEGMENT
main PROC
lea rax, a
mov dword ptr [rax], 1
lea rbx, b
mov dword ptr [rbx], 1
mov eax, dword ptr [rax]
add dword ptr [rbx], eax
inc eax
imul eax, dword ptr [rbx]
mov dword ptr [rbx], eax
ret
main ENDP
_text ENDS
END
And this is my ML64 command:
ml64.exe e:\Assembly\WindowsDebugging\PointersProject\PointersProject.asm /link /SUBSYSTEM:CONSOLE /ENTRY:main /DEBUG /OPT:NOREF,NOICF,NOLBR
All is well up to this point. But when I load this executable and disassemble the main function, the identifiers (a and b) are missing and I see <PERF> instead:
0:000> uf main
PointersProject!main:
00007ff7`b6211010 lea rax,[PointersProject!main <PERF> (PointersProject+0x4004) (00007ff7`b6214004)]
00007ff7`b6211017 mov dword ptr [rax],1
00007ff7`b621101d lea rbx,[PointersProject!main <PERF> (PointersProject+0x4000) (00007ff7`b6214000)]
00007ff7`b6211024 mov dword ptr [rbx],1
00007ff7`b621102a mov eax,dword ptr [rax]
00007ff7`b621102c add dword ptr [rbx],eax
00007ff7`b621102e inc eax
00007ff7`b6211030 imul eax,dword ptr [rbx]
00007ff7`b6211033 mov dword ptr [rbx],eax
00007ff7`b6211035 ret
I was expecting to see something like this instead for the LEA lines:
00000001`40001010 488d05ed2f0000 lea rax,[PointersProject!a (00000001`40004004)]
00000001`4000101d 488d1ddc2f0000 lea rbx,[PointersProject!b (00000001`40004000)]
What does <PERF> mean? Why is WinDbg not showing the identifiers ? Is it because of some optimization during the build process ? If so how do I avoid it ? Please help.
i'm trying to write a boot sector that displays a small message on boot, but running the following on QEMU produces malformed text and any string with more than 5 characters doesn't show at all.
here's the code i assembled with NASM to a raw .bin file
[bits 16]
[org 0x7c00]
start:
xor ax,ax
mov ds,ax
mov es,ax
mov bx,0x8000
mov ax,0x13
int 0x10
mov ah,02
int 0x10
mov ah,0x02
mov bh,0x00
mov dh,0x12
mov dl,0x03
int 0x10
mov si , welcome
welcome db "hello",13,0
call RainbowPrint
RainbowPrint:
mov bl,1
mov ah, 0x0E
.repeat_next_char:
lodsb
cmp al, 0
je .done_print
add bl,6
int 0x10
jmp .repeat_next_char
.done_print:
ret
times (510 - ($ - $$)) db 0x00
dw 0xAA55
EDIT : here's an image showing the program running in qemu
You seem to overlapping your char_stream
welcome db "hello", 13, 0
I reviewed your code and came up with the following that has a clear display of your specific char_stream
[bits 16]
[org 0x7c00]
start:
xor ax,ax
mov ds,ax
mov es,ax
mov bx,0x8000
mov ax,0x13
int 0x10
mov ah,02
int 0x10
mov ah,0x02
mov bh,0x00
mov dh,0x12
mov dl,0x03
int 0x10
mov si , welcome
; Your [welcome] stream was here before...
call RainbowPrint
;***********
; Don't mind this area... just a simple key detection and reboot method...
xor ax, ax
int 0x16
xor ax, ax
int 0x19
;***********
; Move your stream away from operatable code areas:
welcome db "Hello, World!", 0x0D, 0x0A, 0x00
RainbowPrint:
mov bl,1
mov ah, 0x0E
.repeat_next_char:
lodsb
cmp al, 0
je .done_print
add bl,6
int 0x10
jmp .repeat_next_char
.done_print:
ret
times (510 - ($ - $$)) db 0x00
dw 0xAA55
The prefered text stream
MY CODE IS
.model small
.data
arr db 83h, 12h, 0F0h, 0Bh, 89h
cnt db 05h
.code
mov ax, #data
mov ds, ax
mov si, offset arr
mov cl, cnt
sub bl, bl
sub dl, dl
back:
mov al, [si]
and al, 80h
jz skip
inc bl
skip:
inc dl
inc si
dec cl
jnz back
mov ah, 4cH
int 21H
end
THE ERRORS ARE AS FOLLOWS
1.asm:1: error: attempt to define a local label before any non-local labels
1.asm:1: error: parser: instruction expected
1.asm:2: error: attempt to define a local label before any non-local labels
1.asm:9: error: comma, colon, decorator or end of line expected after operand
I have a problem with printing system date because of cx register size. How can it be solved without any big changes?
title casadatum
zas segment stack
db 256 dup(?)
zas ends
strsize EQU 64
dat segment
print db 'Current System Date is : $'
date db 'dd:mm:rrrr$'
nl db 10,13,'$'
dat ends
code segment
assume cs:code, ss:zas, ds:dat
get_date proc
mov ah,2ah
int 21h
mov al,dl
call convert
mov [bx],ax
mov al,dh
call convert
mov [bx+3],ax
mov al,cx
call convert
mov [bx+6],ax
ret
endp
convert proc
push dx
mov ah,0
mov dl,10
div dl
or ax, 3030h
pop dx
ret
endp
start:
mov ax, seg dat
mov ds,ax
LEA BX, date
CALL GET_date
lea dx,print
mov ah,09h
int 21h
lea dx,date
mov ah,09h
int 21h
koniec:
mov ah, 4ch
int 21h
code ends
end start
Replace this part of your code
mov al,cx
call convert
mov [bx+6],ax
with these instructions
mov al,100
xchg ax,cx
div cl
mov ch,ah
call convert
mov [bx+6],ax
mov al,ch
call convert
mov [bx+8],ax