home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 4,656 of 4,675   
   Paul Edwards to All   
   x64 address indexed by 32-bit address   
   19 Jan 24 21:42:14   
   
   From: mutazilah@nospicedham.gmail.com   
      
   Hi.   
      
   I am using a slightly modified GCC 3.2.3   
   to generate x64 code, and using PDPCLIB   
   and running under Linux x64.   
      
   I don't trust either (my) PDPCLIB or my   
   modified GCC 3.2.3   
      
   Assuming PDPCLIB is behaving correctly,   
   it is showing that the stack is above   
   4 GiB. It seems to be a 48-bit address.   
      
   The executable appears to be loaded in   
   low memory - way below 2 GiB.   
      
   kerravon@kerravon-pc:~/scratch/eee/pdos/pdpclib$ ./pdptest ab def   
   welcome to pdptest   
   main function is at 00401334   
   allocating 10 bytes   
   m1 is 004087A8   
   allocating 20 bytes   
   m2 is 00408828   
   stack is around 7FFC36A1053C   
   printing arguments   
   argc = 3   
   arg 0 is <./pdptest>   
   arg 1 is    
   arg 2 is    
   kerravon@kerravon-pc:~/scratch/eee/pdos/pdpclib$   
      
      
   Now I have this code:   
      
   printf("argv[0] is %p %s\n", argv[0], argv[0]);   
   printf("len is %d\n", (int)strlen(argv[0]));   
      p = argv[0] + strlen (argv[0]);   
   printf("p is %p\n", p);   
   printf("p as string is %s\n", p);   
   printf("p current is %x\n", p[0]);   
   printf("as negative is %x\n", p[-1]);   
      
      
   which is generating (for that last line):   
      
   LM1873:   
            movl    $4294967295, %eax   
            addq    -64(%rbp), %rax   
            movsbl  (%rax),%esi   
            movl    $LC445, %edi   
            movb    $0, %al   
            call    _printf   
      
   That first instruction - the movl - has   
   negative 1 as an unsigned value. I tried   
   manually changing the generated assembler   
   to $-1 but the result appears to be the   
   same (I may have stuffed up the test).   
      
   And it crashes:   
      
   kerravon@kerravon-pc:~/scratch/eee/gcc/gcc$ ./gcc-new.exe   
   argv[0] is 7FFC8DC50294 ./gcc-new.exe   
   len is 13   
   p is 7FFC8DC502A1   
   p as string is   
   p current is 0   
   Segmentation fault (core dumped)   
   kerravon@kerravon-pc:~/scratch/eee/gcc/gcc$   
      
      
   I suspect what is happening is that it is   
   adding the entire value of eax as an unsigned   
   32-bit value to the 64-bit address and so the   
   address is being offset by nearly 4 GiB   
   instead of being offset by 1 byte.   
      
   GCC 3.2.3 was used to build systems I believe,   
   so it "must" work in some circumstances.   
      
   Any idea how this was meant to work?   
      
   Thanks. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca