Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Aug 2002 22:30:04 -0700 (PDT)
From:      NIIMI Satoshi <sa2c@sa2c.net>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: i386/41528: better stack alignment patch for lib/csu/i386-elf/
Message-ID:  <200208130530.g7D5U4cY093626@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/41528; it has been noted by GNATS.

From: NIIMI Satoshi <sa2c@sa2c.net>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/41528: better stack alignment patch for lib/csu/i386-elf/
Date: 13 Aug 2002 14:26:33 +0900

 Thanks for your long descriptions which I should write.
 
 Bruce Evans <bde@zeta.org.au> writes:
 
 > I think stack alignment belongs only in functions that actually store
 > floating point or other data that actually needs large alignment, and
 > it should be done by the compiler since only the compiler knows the
 > alignment requirements.  gcc on i386's requires the stack to be aligned
 > 4 bytes below a 2^<preferred-stack-boundary> boundary on entry to each
 > function, but this is compiler-dependent and pessimal IMO.
 
 Yes.  But it's too hard for me to hack gcc.  ;-)
 
 > This is a wrong place to do alignment (see above).  Alignment to a
 > nice power of 2 here would be reasonable, but subtracting 4 isn't.  4
 > is magic, and the correct number depends on the language and the
 > compiler that the application being exec'ed was compiled with, so it
 > shoulnd't be given by a kernel arch-dependent #define.
 
 I have similar hack to align stack by kernel for pre-compiled
 executables.  But I did not send-pr it because:
 
 1. As you say, this is not correct place.  This depends on both CPU
    architecture and executable image ABI.
 
 2. Because ELF ABI does not define stack alignment, other compilers
    may want stack to be aligned differently.  This hack makes happy
    only executables that are compiled with gcc.
 
 > I would only use this fix or one like it in RELENG_4.  Maybe my kernel
 > hack is better since it "fixes" most applications without a recompile.
 > It is simpler because it doesn't use any assembly code or have to recover
 > from the kernel pushing the args in a misaligned place.
 
 Thanks.  But is it possible?  I attached a patch for -current so that
 it can be commited into -current then MFC'ed to -stable.
 
 > Minor improvements:
 > - remove the comment about %ebp since the caller doesn't handle %ebp
 > - remove the hlt since it wouldn't really help if it were reached (it is
 >   privileged so it just generates SIGBUS, and execution continues at the
 >   instruction after the hlt if there is a SIGBUS handler and it returns...).
 
 I agree.  Please remove them.
 
 -- 
 NIIMI Satoshi
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208130530.g7D5U4cY093626>