Strcpy Assembly

This is a discussion on Strcpy Assembly within the Tech Board forums, part of the Community Boards category; oh you mean both labels are in the data segment but have different addresses in the segment as Anduril's code ...

  1. #31
    The Dragon Reborn
    Join Date
    Nov 2009
    Location
    Dublin, Ireland
    Posts
    629
    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?
    You ended that sentence with a preposition...Bastard!

  2. #32
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,427
    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.

  3. #33
    The Dragon Reborn
    Join Date
    Nov 2009
    Location
    Dublin, Ireland
    Posts
    629
    Quote Originally Posted by anduril462 View Post
    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
    Code:
           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.
    You ended that sentence with a preposition...Bastard!

  4. #34
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,427
    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
    Code:
    movb $0, $inputString+19

  5. #35
    The Dragon Reborn
    Join Date
    Nov 2009
    Location
    Dublin, Ireland
    Posts
    629
    Quote Originally Posted by anduril462 View Post
    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
    Code:
    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.
    You ended that sentence with a preposition...Bastard!

  6. #36
    The Dragon Reborn
    Join Date
    Nov 2009
    Location
    Dublin, Ireland
    Posts
    629
    em, you were almost right
    Code:
              movb $0, $inputString+19
    when it didn't compile i thought it was because you didn't dereference it

    so i did this

    Code:
                    movb $0, ($inputString+19)
    it compiled but it wouldn't link.
    so i tried this haha
    Code:
                     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?
    You ended that sentence with a preposition...Bastard!

  7. #37
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    I suppose the idiomatic thing would probably be something like
    Code:
    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.

  8. #38
    The Dragon Reborn
    Join Date
    Nov 2009
    Location
    Dublin, Ireland
    Posts
    629
    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
    You ended that sentence with a preposition...Bastard!

  9. #39
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by Eman View Post
    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
    Code:
     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.
    Last edited by tabstop; 12-31-2010 at 05:37 PM.

  10. #40
    The Dragon Reborn
    Join Date
    Nov 2009
    Location
    Dublin, Ireland
    Posts
    629
    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
    Last edited by Eman; 01-01-2011 at 10:37 AM.
    You ended that sentence with a preposition...Bastard!

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. loading 2 character arrays in a row
    By rivkyfried1 in forum C Programming
    Replies: 4
    Last Post: 12-09-2010, 09:40 AM
  2. C to assembly interface
    By Roaring_Tiger in forum C Programming
    Replies: 4
    Last Post: 02-04-2005, 02:51 PM
  3. assembly language...the best tool for game programming?
    By silk.odyssey in forum Game Programming
    Replies: 50
    Last Post: 06-22-2004, 01:11 PM
  4. True ASM vs. Fake ASM ????
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 04-02-2003, 03:28 AM
  5. C,C++,Perl,Java
    By brusli in forum C Programming
    Replies: 9
    Last Post: 12-31-2001, 02:35 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21