Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Dec 2002 14:55:39 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Peter Wemm <peter@wemm.org>
Cc:        "David O'Brien" <obrien@FreeBSD.org>, Poul-Henning Kamp <phk@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/boot/i386/boot2 Makefile boot1.s 
Message-ID:  <20021220135958.C34646-100000@gamplex.bde.org>
In-Reply-To: <20021220000810.139972A7EA@canning.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Dec 2002, Peter Wemm wrote:

> Bruce Evans wrote:
> > On Mon, 16 Dec 2002, David O'Brien wrote:
> >
> > > On Sun, Dec 15, 2002 at 08:31:45PM +1100, Bruce Evans wrote:
> > > > Please remove the alignment hacks (Makefile rev.1.25) while you are there
>     .
> > > > Breakage of -[fm]align-* seems to have been fixed in gcc, so the hacks
> > > > make no difference except to reduce the size of boot2.o's data by 3 bytes
> > > > (I think the 3 bytes is wasted at link time).
> > >
> > > I'd rather leave them in to get the 3 bytes -- believe it or not it has
> > > made a difference in the past.
> >
> > It doesn't any difference because the 3 bytes is wasted at link time.
> > The data section has size 29, but sections are padded to 4-byte boundaries,
> > at least for ELF objects with the default linker scripts, so 29 becomes 32
> > the same as if it had been padded internally for aligment.
>
> In my case, it was a *final* object size difference of 3 bytes in /boot/
> boot2.  I found that turning off the sed caused quite a bit of bloat, so
> obviously we dont have all the necessary -[fm]align-*'s in the Makefile
> that you have.

But I don't have any extra ones.  It's possible that I have some
pollution in the environment (no pentiumpro optimizations ...), but I
don't think it affects boot2.  Here the sed removes just 5 .p2aligns,
which reduces the size of boot2.o by a whole 3 bytes (from 32 to 29).
There are no .p2align's in the text section since -falign-* now works.
There are .p2align's in the .rodata* and .data sections because gcc
doesn't have any flags to reduce alignment outside of the text section
AFAIK (except for my -mno-align-long-strings which is not used, and
the __packed attribute at the source level which is not used either).
Most of the data is aligned anyway so the .p2align's have no effect.
The potentially most wasteful one is:

	.section	.rodata.str1.32,"aMS",@progbits,1
	.p2align 5
.LC13:
	.string	"\nFreeBSD/i386 boot\nDefault: %u:%s(%u,%c)%s\nboot: "

This can be killed using -mno-align-long-strings.

The .p2align 5 string seems to be what is wasteful in practice.  boot2
no longer fits despite the size of boot2.o as reported by size(1) being
essentially no different.  objdump -h show the problem.  The following
dif is of objdump -h output on boot2.o with all alignment stripped
(orig) and with no alignment stripped:

2c2
< orig/boot2.o:     file format elf32-i386-freebsd
---
> boot2.o:     file format elf32-i386-freebsd
8c8
<   1 .data         0000001d  00000000  00000000  0000139c  2**2
---
>   1 .data         00000020  00000000  00000000  0000139c  2**2
12c12
<   3 .rodata       00000027  00000000  00000000  000013c0  2**0
---
>   3 .rodata       00000027  00000000  00000000  000013c0  2**2
16c16
<   5 .rodata.str1.32 00000032  00000000  00000000  00001494  2**0
---
>   5 .rodata.str1.32 00000032  00000000  00000000  000014a0  2**5
18c18
<   6 .comment      0000002f  00000000  00000000  000014c6  2**0
---
>   6 .comment      0000002f  00000000  00000000  000014d2  2**0

size(1) says that the text size is 5228 = sum of sizes of .text and
.rodata* sections in both cases.  But the text size is actually
larger in the non-sed'ed version since some padding is needed to align
the .rodata and .rodata.str1.32 sections (especially the latter).  This
results in the non-sed'ed boot2 being 8 bytes too large here.  With
-mno-align-long-strings, there are 12 bytes to spare.  The sed'ed
version has 15 bytes to spare.  It really is 3 bytes smaller, presumably
because the section order is such that an unaligned section is packed
next to the data section.

Summary:
- you save more space than -falign-* can, by hacking out most of the
  alignment for data sections.
- the saving is quite small except for the .rodata.str1.32 section and
  this can be handled less hackishly using -mno-align-long-strings.
- size(1) is broken.  It apparently doesn't understand alignment of
  .rodata*.

Bruce


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




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