X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10202112142.AA20075@clio.rice.edu>
Subject: Re: Alignment problem
To: djgpp-workers AT delorie DOT com
Date: Mon, 11 Feb 2002 15:42:25 -0600 (CST)
In-Reply-To: <200202112044.g1BKi3h17738@envy.delorie.com> from "DJ Delorie" at Feb 11, 2002 03:44:03 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > We could add a sbrk(0) call before calling sbrk() with the expected 
> > size - and if it's aligned the sbrk() value should be also.  If
> > sbrk(0) not aligned, we sbrk() the small number of bytes to align - 
> > which will always work (unless there's a equality bug right at the
> > boundary in sbrk...)
> 
> That won't work if the remaining space in the current memory region is
> smaller than the malloc() request size.  sbrk(0) will point to the
> tail of the current region, but sbrk(N) will return the beginning of a
> new region.

A new region will always be 8 byte aligned - so no problem in that case.
(Yes, that's a evil assumption which should be documented if we do that).
This can be the reason where some Windows change alignment.  If you get
a new zone and it's not contiguous vs continuing to use the original
zone "extended" with the contiguous block.

Of course, unixy sbrk() always makes things predictable ...

> > By the way, I think the reason we are off by 4 is stubinfo is 0x54 
> > bytes and it's the very first thing we sbrk() :-P
> 
> Well, that's easily fixed!

Not so easy - we base that on the end of our bss section, which it seems
can also be 4 byte ended (?)

Some test programs always come up aligned ;-/