Sender: root AT delorie DOT com Message-ID: <37835749.DEDAFC98@inti.gov.ar> Date: Wed, 07 Jul 1999 10:34:01 -0300 From: salvador Organization: INTI X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: es-AR, en, es MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: .align directives in libc.a References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > > 1) The start of the section is aligned by djgpp.djl > > I think djgpp.djl only aligns .data, but .bss and .text aren't > aligned. But I might be wrong, since I'm not too fluent with the ld > script syntax. As the stub and headers have a size power of two .text is correctly aligned. Also crt0 (accidentally) have a size that left the first .o module linked with a 16 bytes aligment. I remmember it because I compiled a version of the benchmarks with this kind of aligment, the results are included in the pages. (I used some tricks to avoid the 8 bytes limitation of ld, nothing automatic). > However, if I *am* wrong, I don't understand how come the code and > the data wind up aligned to 4-byte boundary in a running program. ? Code is aligned 8 bytes between .o files, between functions that's a gcc setting so depends on the command line and compile time options of gcc. Data is aligned 4 bytes because the ints are 4 bytes, but the start of the section is aligned to a 512 bytes boundary or somethink like it. > > 2) The aligment of the functions can be controled by -malign-functions > > I cannot find a way to cause GCC be smart about -malign-functions. > -malign-functions=4 (i.e. 16-byte alignment) is wasteful and might > actually make the program slower, and I don't see any way of telling > GCC to use something like ".balign 16,,7". I understand from > explanations by Andris that this is currently impossible without > hacking the compiler sources. Too bad. Yes is bad. > > 3) binutils controls the aligment between .o files (8 currently). > > There was a thread some time ago about this, which I think ended up > with a conclusion that the sections are misaligned, and since COFF > aligns relative to the section, we end up with code and some data > which can be aligned or misaligned because of random factors. This > caused programs compiled with GCC 2.8.1 be slower than compiled with > 2.7.2.1. > > The user which investigated this told that he reconfigured Binutils to > produce 32-byte alignment for all sections, No sections, that aligment between modules or .o files. > and the problem went > away. 32-byte alignment is an overkill, I think, but the problem is > evidently very real. Yes, the problem is that: -------------- first file functions here last_address -------------- next .o file linked by ld last_address aligned to 8 bytes boundary functions here -------------- So if you try to align to 16, 32, etc bytes boundaries you won't succeed. Also: putting a .align directive at the end of first file doesn't work. This value is hardcoded in binutils. > > I think you are talking about (3) and not (2). Is that correct? > > What I had in mind was this: > > - set up Binutils to align .text on 16-byte boundary, and .data and > .bss on 8-byte boundary; But then you'll waste a lot of memory in libc. > - align entries into library functions written in assembly with > ".balign 16,,7"-- As in libc each .S is a separated file if you do what you say in the first point it won't affect anything. What binutils controls is the aligment of the first byte in a .o file. So this align will be reduced to nothing. > for those functions where speed is important, > like memcpy and __dj_movedata; > - cause GCC to use ".balign 16,,7" in compiled code (which I now > understand isn't simple to do). Ok. SET -- Salvador Eduardo Tropea (SET). (Electronics Engineer) Visit my home page: http://welcome.to/SetSoft or http://www.geocities.com/SiliconValley/Vista/6552/ Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org set AT ieee DOT org set-soft AT bigfoot DOT com Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013