From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31789 invoked by alias); 22 Dec 2007 19:05:28 -0000 Received: (qmail 31780 invoked by uid 22791); 22 Dec 2007 19:05:28 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Dec 2007 19:05:24 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id lBMJ5Mcq022712 for ; Sat, 22 Dec 2007 14:05:22 -0500 Received: from zebedee.littlepinkcloud.COM (vpn-14-43.rdu.redhat.com [10.11.14.43]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBMJ5Ju3012641; Sat, 22 Dec 2007 14:05:21 -0500 Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.8/8.13.5) with ESMTP id lBMJ55eM001119; Sat, 22 Dec 2007 19:05:12 GMT Received: (from aph@localhost) by littlepinkcloud.COM (8.13.8/8.13.5/Submit) id lBMJ51iP001115; Sat, 22 Dec 2007 19:05:01 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18285.24541.709390.62899@zebedee.pink> Date: Sat, 22 Dec 2007 19:05:00 -0000 From: Andrew Haley To: Jeremie Le Hen Cc: gcc-help@gcc.gnu.org Subject: Re: need an explanation on assembly generated by various GCC releases In-Reply-To: <20071222164635.GC35586@obiwan.tataz.chchile.org> References: <20071222164635.GC35586@obiwan.tataz.chchile.org> X-Mailer: VM 7.19 under Emacs 22.0.93.1 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00401.txt.bz2 Jeremie Le Hen writes: > Hi list, > > (Please Cc: me when replying, I am not subscribed to this list. Thank.) > > For the last couple of day, I've looked at the assembly generated by > various GCC releases. FYI, I'm working on FreeBSD but according to my > verifications, there doesn't seem to have much difference with Linux. > > All compilations have been performed with the -O flag. > > > I've written the following useless (and vulnerable) program: > % #include > % > % int > % main(int ac, char *av[]) > % { > % char buf[16]; > % > % if (ac < 2) > % return 0; > % strcpy(buf, av[1]); > % return 1; > % } > > > Theorically, the most basic The corresponding stack right before > main() function should be calling strcpy(): > something like this: > > % push %ebp % | av | > % mov %esp, %ebp % | ac | > % sub $16, %esp % | ret | > % cmp $1, 8(%ebp) % ebp-> | sebp | (saved ebp) > % jle .byebye0 % |/ / / / | ^ > % mov 12(%ebp), %eax % | / / / /| | > % push 4(%eax) % |/ / / / | | (buf, 16 bytes) > % push -16(%ebp) % | / / / /| v > % call strcpy % | av[1] | > % mov $1, %eax % esp-> | &buf | > % jmp .byebye % > % byebye0: % > % mov $0, %eax % > % byebye: % > % leave % > % ret % > > > [ ... gcc 2.x and 3.x examples deleted ... ] > With GCC 4.2.1. things are weird too but differently. Functionnaly > it is correct but it is very far from what I've expected initially. > > In the prolog, before creating a new stack frame, the stack is > aligned on a 16 bytes boundary. Then `ret' is pushed once more and > the new stack frame is then created. Afterward the address of `ac' > is pushed and a 36-bytes buffer (9 words) is allocated. This > buffer will actually contain the 4 words buf in the top of it and > the 2 arguments for strcpy() in the bottom. But there are still 3 > unused words. Why so? This just looks to me like 16-aligning the stack; we do this for performance. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903