I wrote this code in emu8086 and it goes well in the emulator but when I'm trying to compile it with NASM it's throwing me up the error: "operation size not specified", help someone?
add bx,[3565]
sub bx,0xcc
mov [bx],0CCh
NASM can't figure out what you meant by a line like mov [bx],0CCh. Clearly,
this sets something to 0CCh. But do you want to have bx pointing to a single byte
, short, long, ...? This will manifest itself as the fairly self-explanatory
error: operation size not specified in NASM. You could avoid the error specifying the type, as shown below:
SECTION .text
global start
start:
add bx,[3565]
sub bx,0xcc
mov byte [bx],0CCh
That'd assemble it ok... of course, don't try to run it as it is, it'll produce EXCEPTION_ACCESS_VIOLATION. Just open it with a debugger and you'll understand why.
Related
First I tried opening a file with fopen function and print content of the file using fprint function but it was just printing a bunch of symbols to the terminal.
After a while I realized that it does not take pointer to a stream as argument and above mentioned behaviour was expected. It was printing the actual pointer value. putc or puts function also does not seem to take a pointer to the file I/O stream as an argument.
My best guess right now is I have to access the buffer fopen function created somehow! But I have no idea how or if it is possible. To sum it all up I am absolutely stuck right now.
The ultimate goal here is to get input from STDIN and/or a file do some processing on the text(eg: lowercase to uppercase) and output the result to STDOUT and/or a file. I figured If I am able to get the answer to above mentioned problem then It should help with the ultimate goal maybe.
PS: Let me know If the question can be improved in any way. Thank you.
Maybe the following code will help to get a better understanding of what I am trying to say.
.section .data
o_rdonly:
.ascii "r"
content:
.ascii "Content of the file: %d\n" #This is how I figured what those random symbols were.
.section .bss
.lcomm buffer, 10
.section .text
.globl _start
_start:
movl %esp, %ebp
pushl $o_rdonly
pushl 8(%ebp)
call fopen
##Print the content of the file?##
#pushl %eax #
#call printf #It just prints the actual address of the File I/O pointer.
pushl $0
call exit
You need to first read from the file using fread or fgets or some other function and then write what you read to standard output. There is no shortcut to directly print the contents of one file.
In i386 I'm trying to initialize a string in data. This is stupid, but I can't get it to work.
sentence:
.char 'h',0
says .char is an illegal pseudo op. Clearly I'm not doing it right, though
sentence: db 'h',0
gives nothing either.
As lurker said, each assembler has its own syntax. db is used by nasm, for example. gas provides .byte, .string, .asciz and a bunch of other directives. See the manual. Your code could look like:
sentence: .string "h"
Super noob here. I'm doing a "hello world" type program in LC-3 assembly language and I simply don't know how to print more than one string to the console. I need 4 strings on separate lines that are my class, name, project and goodbye. Right now all I can seem to print in the class.
.ORIG x3000
LOOP LEA R0, CLASS
LD R1, NAME
LD R2, PROJECT
LD R3, GOODBYE
PUTS
HALT
CLASS .STRINGZ "CS101\n"
NAME .STRINGZ "JOHN\n"
...
.END
How would I get the other 3 to print? Thanks!
The Z in .STRINGZ means zero terminated. That is you have declared separate strings. If you want to print them all, you need to invoke PUTS multiple times. Alternatively, make it a single string with embedded newlines. Then you can print the whole thing in one go.
What does .string do in assembly?
In an inline asm call in c, I wrote
.string \"Hello World\"
1) Can somebody give me an overview of how .string works?
2) Somehow that value gets saved in %esi. Why?
3) How can I append a return carriage on the end? \n doesn't work
.string is an assembler directive in GAS similar to .long, .int, or .byte. All it does is create and initialize memory for you to use in your program. The .string directive will automatically null-terminate the string with [\0] for you. In this case, the assembler is allocating space for 14 characters in 14 contiguous bytes of memory. If you were to look at the memory, you would see this:
["][H][e][l][l][o][ ][W][o][r][l][d]["][\0]
Except in hexadecimal rather than characters. I'm not sure how or why %esi points to the string (it's either an assembler setting I'm not familiar with or has been set that way on a line of code you're not showing us). What it means is that %esi "points" to the first byte of the string - in this case the first ["]. You can use the %esi register to loop through the bytes using an offset (%esi + 5 would be [o]) or by incrementing the register itself.
To add a newline you might want to try \x0D\x0A instead of \n.
It just emits a sequence of characters into the appropriate code/data section. See this and this (they use .ascii, though).
Show us the code.
Try \\n or \12 or \xa.
Look at this screenshot of a Visual C++ debugger session:
(source: lviv.ua)
The execution point is now inside a virtual function. "mDb" is a reference to an object which is the member of that class. "mDb" has the type CDbBackend&. There is only one thread. The values in the red rectangles should be equal, ... but they're not. How can this be possible?
The code being debugged has been instrumented with BoundsChecker (a memory debugger and profiler). The discrepancy leads to a crash later on. Non-instrumented code doesn't lead to any of these effects. I think it's too early to blame BoundsChecker - it could well be a hidden bug in my program which BoundsChecker has revealed, which is why I'm very inclined to understand the situation.
The assembly generated for the "b = &mDb" statement is as follows, in case it's relevant. Stepping thhrough this assembly, with watch and registers visible, is captured here (500kb avi file).
007AB7B0 push 4
007AB7B2 push 80000643h
007AB7B7 push 4
007AB7B9 push 0C0002643h
007AB7BE lea eax,[ebp-10h]
007AB7C1 push eax
007AB7C2 call dword ptr [_numega_finalcheck_C_110456 (8FA8A8h)]
007AB7C8 mov eax,dword ptr [eax]
007AB7CA add eax,1CCh
007AB7CF push eax
007AB7D0 call dword ptr [_numega_finalcheck_C_110456 (8FA8A8h)]
007AB7D6 mov dword ptr [ebp-70h],eax
007AB7D9 push dword ptr [ebp-70h]
007AB7DC push 4
007AB7DE push 50000643h
007AB7E3 lea eax,[ebp-20h]
007AB7E6 push eax
007AB7E7 call dword ptr [_numega_finalcheck_Y_110456 (8FA8ECh)]
007AB7ED mov ecx,dword ptr [ebp-70h]
007AB7F0 mov ecx,dword ptr [ecx]
007AB7F2 mov dword ptr [eax],ecx
Please rebuild and test it again. (I know it sounds stupid :)
The code is compiled in debug mode w/o any optmizations, right? I guess so. But, in the disassembly, no symbolic information is presented. I can only see [ebp - offset]; this should be represented as some symbolic name such as b. Be sure turn on "Show symbol names" in disassembly view.
I'm not sure the disassembly code you pasted are the code for b = &mDb. It looks like [ebp-10h] or [ebp-70h] would be b, but mDb does not seem to be here. All the code in here just is calling instrumented function. Could you give more disassembly with source code around them?
I have an experience where debugging information is incorrectly generated, so symbolic debugging gave an incorrect value. My workaround was that changing member variable layout and putting some padding in local stack. But, I'm not sure that this was a really compiler's bug. I was working on Visual Studio 2008 with Intel C/C++ compiler, and the project was pretty complex.
The information is somewhat insufficient to resolve this problem. It would be better if you give more disassembly.
Is mDb also of type CDbBackend? If not, then discrepancy is due to casting.
Given:
class A
{
// Stuff
};
class B : public A
{
// More stuff
};
B *b = new B;
A *a = (A *)&b;
then b and a might or might not be equivalent depending on what exactly "Stuff" and "More Stuff" are. The biggest things that will change the pointer castings are virtuals and multiple inheritance. If this is the case in your example then your debugger's output is correct and normal behavior. If you expand the class view for mDb, I wouldn't be surprised if you find a CDbBackend pointer contained within it that matches your second output below.