public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Jeremie Le Hen <jeremie@le-hen.org>
Cc: gcc-help@gcc.gnu.org
Subject: Re: need an explanation on assembly generated by various GCC releases
Date: Sat, 22 Dec 2007 19:05:00 -0000	[thread overview]
Message-ID: <18285.24541.709390.62899@zebedee.pink> (raw)
In-Reply-To: <20071222164635.GC35586@obiwan.tataz.chchile.org>

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 <string.h>
 > % 
 > % 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

      reply	other threads:[~2007-12-22 19:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-22 16:49 Jeremie Le Hen
2007-12-22 19:05 ` Andrew Haley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18285.24541.709390.62899@zebedee.pink \
    --to=aph@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jeremie@le-hen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).