This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

gas lobotomy, .bss section optimization


	I have written a small BFD program to move variables that
have been initialized with all zeroes from .data to .bss.  This does
not shrink a program's RAM image, but it shrinks the program's object
files and the resultant binary a bit, and it should make the program
load a microsecond faster.  It may even allow people to cram a few
more bytes onto Linux boot floppies, and it may be helpful for low
end embedded applications too.

	Anyhow, in order to make this program work in its present form,
I had to give gas a bit of a lobotomy, and I'd like to ask if there is
any harm in what I have done, and, if not, if perhaps it would be a good
idea to get the change integrated into the binutils sources.

	The problem was that when this program would move a variable
from .data to .bss, it could not find all of the relocations that
pointed to that variable by just interrogating reloc->sym_ptr_ptr.
This was because gas changed the relocations that referred to, say
a local .data variable "foo" (that lived, say at data + 0x50) to
".data+0x50".  While it is true that I could have this program
calculate the address range that was being moved and calculate
which relocations pointed to it, I think it might be possible that
compiler optimizations would generate references to addresses a bit
before or after the variable to fold in some other arithmetic
calculations, and the wrong address would be relocated.  By telling
gas not to try to translate the relocation information to something
like ".data+0x50", the relocation records end up referencing the
actual symbol in question, so the compiler can do whatever arithmetic
that it likes, and my program still knows which symbol the compiler
had in mind.  For reference, I have attached the patch below, although
I don't know if it's the best way to go about this or not.

	Anyhow, my question is this: for BFD_RELOC_32 type relocations
that cross section boundaries (so a relocation record will be generated
either way), is there any advantage to having gas translate those
relocations from being relative to a symbol in, say, .data, to something
like ".data+0x50".  Does it actually help ld run faster?  Does it make
the resulting .o smaler?  I understand that, within the same section,
you can eliminate a relocation record, but, for references across
section, it seems like a waste of CPU cycles to do that translation
and it produces less informative output.

	Anyhow, I have included the change that I made below.  However,
the change that I have in mind, would be to change the code where
tc_fix_adjustible is called to act as if tc_fix_adjustible returned 0
if the reference is across sections.

--- binutils-2.11.90.0.7/gas/config/tc-i386.c	Thu Mar 29 23:25:59 2001
+++ binutils/gas/config/tc-i386.c	Tue May  1 06:40:41 2001
@@ -1186,6 +1186,7 @@
       || fixP->fx_r_type == BFD_RELOC_X86_64_PLT32
       || fixP->fx_r_type == BFD_RELOC_X86_64_GOT32
       || fixP->fx_r_type == BFD_RELOC_X86_64_GOTPCREL
+      || fixP->fx_r_type == BFD_RELOC_32
       || fixP->fx_r_type == BFD_RELOC_VTABLE_INHERIT
       || fixP->fx_r_type == BFD_RELOC_VTABLE_ENTRY)
     return 0;

	Also, for completeness, if anyone wants to look at my .bss
optimizer which I just got tentatively working about an hour ago, you
can grab it from ftp://ftp.yggdrasil.com/private/adam/deflate.c.  (I
will probably rename it to something else to avoid confusion with gzip
before I announce it.)  Ultimately, I would like to configure gcc to
automatically run it when given some option (or perhaps when not
given some option).  After it has been tested for a while, I would
be interested in integrating its functionality into binutils (which
would also help avoid skew issues if it ends up still needing this
change in gas).

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]