Strcpy Assembly

[Eman]

oh you mean both labels are in the data segment
but have different addresses in the segment as Anduril's code pointed out.

Even then we should still be able to declare a variable like I did with the label as Anduril showed, except that way would take longer, but apart from that is it any different, the same concept still applies?

[anduril462]

I don't know what you mean by "take longer", but yes, they refer to different addresses. The section they are in depends on what kind of .section directives you have above/between them. Ideally, data goes in .data or .bss, constant/unmodifiable data goes in .rodata and instructions go in .text.

Whether you declare it as a label with a .ascii, .asciz or .string directive, or whether you use a label and tabstop's .byte 0,0,0,0,0... or whether you use .comm someLabel, your resultant code will work the same (of course, assuming same amount of space reserved in all cases). Your assembly will still always refer to $someLabel, which will get translated to an address in all 3 cases when the final executable file is built. It technically doesn't matter which method you use for the program in question. In general however, it may be easier, more appropriate, or plain old impossible to use certain methods depending on whether you wish to initialize data or make it constant or read only, etc.

[Eman]

I don't know what you mean by "take longer", but yes, they refer to different addresses. The section they are in depends on what kind of .section directives you have above/between them. Ideally, data goes in .data or .bss, constant/unmodifiable data goes in .rodata and instructions go in .text.

Whether you declare it as a label with a .ascii, .asciz or .string directive, or whether you use a label and tabstop's .byte 0,0,0,0,0... or whether you use .comm someLabel, your resultant code will work the same (of course, assuming same amount of space reserved in all cases). Your assembly will still always refer to $someLabel, which will get translated to an address in all 3 cases when the final executable file is built. It technically doesn't matter which method you use for the program in question. In general however, it may be easier, more appropriate, or plain old impossible to use certain methods depending on whether you wish to initialize data or make it constant or read only, etc.

Take longer as in doing this
.string " "
where i have to count the number of spaces
.comm .... seems kind of quick.
Yeah, it does seem a bit clearer than before.
Quick question (haha)

I have a string declared that has 20bytes, but I want the last byte to have the null character when the user inputs a string.

so what i did was

       movl $19, %edx 
       movl $inputString,%ecx
       movl $0, %ebx 
       movl $3, %eax
       int $0x80
       addl $19, %ecx
       movl $0, %ecx #add a null character

I just wonder if that is correct. I haven't tested it yet, because I am having problems with the text editor.

[anduril462]

Ahh, yes, it is definitely quicker to code using comm.

And no, you don't want movl. That moves a long, which is probably 4 bytes on your system, so you will move 4 bytes, all with value zero, to the address stored in %ecx. This means one of the zero bytes will go into the 20th position of inputString, and the other 3 will overflow. Also, because inputString is probably aligned on a byte boundary, the 20th byte might not be properly aligned for putting a long in there and you may get a bus error. You want movb to move a single byte. I think you can address the 20th byte as $inputString+19, so you could just do

movb $0, $inputString+19

[Eman]

Ahh, yes, it is definitely quicker to code using comm.

And no, you don't want movl. That moves a long, which is probably 4 bytes on your system, so you will move 4 bytes, all with value zero, to the address stored in %ecx. This means one of the zero bytes will go into the 20th position of inputString, and the other 3 will overflow. Also, because inputString is probably aligned on a byte boundary, the 20th byte might not be properly aligned for putting a long in there and you may get a bus error. You want movb to move a single byte. I think you can address the 20th byte as $inputString+19, so you could just do

movb $0, $inputString+19

didn't spot that error! And didn't know I could do that! Awesome stuff.
It is annoying that I have to put the length of the string in %edx
I suppose I would have to write a function to do that. I wrote one already, but it isn't a function because I didn't call it and don;t know how use it.
I guess I will have to try that later.

[Eman]

em, you were almost right

          movb $0, $inputString+19

when it didn't compile i thought it was because you didn't dereference it

so i did this

                movb $0, ($inputString+19)

it compiled but it wouldn't link.
so i tried this haha

                 movb $0, inputString+19

which works but makes no sense to me, while attempt 2 does.
move the address by 19 bytes and dereference. That didn;t work because it says undefined reference to $inputString.

The third attempt doesn't make sense. inputString is the memory location, the contents, yeah?
of the first byte.
i am doing 'H'+19.... unless the operand + automatically works with addresses?

[tabstop]

I suppose the idiomatic thing would probably be something like

movb $0, 19(%ecx)

because that really is how AT&T syntax denotes byte offsets from a pointer. (You've already put the address of your string in ecx to do the read.) If inputString+19 works then so much the better.

[Eman]

yeah that would work as well.

But why did inputString+19 work though?


mmn..that now I have done basic C questions in assembly. I guess i should move onto functions...
push and pop sigh

[tabstop]

yeah that would work as well.

But why did inputString+19 work though?

I think the answer to that is that it didn't work (if by work we mean "work" as opposed to "nobody complained". If you do an "objdump -x -d -s" on your .o file you'll see the assembled version and the source it came from. Using inputString + 19 I see

 22:	c6 05 13 00 00 00 00 	movb   $0x0,0x13
			24: R_386_32	copyString

that is, it's going to actual address 0x13 (=19), not to 19 after inputString. (EDIT: Actually I might be lying. Possibly my copyString variable was living at address 0. (If I'm reading my symbol table correctly, it's not, but that's not a guarantee.) But you should check on your own system and compare.)

FURTHER: Okay, you can trash all that, as inputString+<number> appears to be doing exactly what it should. So just think of it as a gift from GNU to you.

[Eman]

lol alright then.
I will have to look at that obj stuff. only if i understood what those numbers mean.
Thanks guys for your help. Really awesome. =P