This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: Accumulation of similar size data items to reduce ROM space.
- From: <Nitin dot Gupta at infineon dot com>
- To: <NitinY at KPITCummins dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: Thu, 4 Nov 2004 11:28:46 +0530
- Subject: RE: Accumulation of similar size data items to reduce ROM space.
>-----Original Message-----
>From: binutils-owner@sources.redhat.com
>[mailto:binutils-owner@sources.redhat.com] On Behalf Of Alan Modra
>Sent: Wednesday, November 03, 2004 7:05 PM
>To: Nitin Yewale
>Cc: binutils@sources.redhat.com
>Subject: Re: Accumulation of similar size data items to reduce
>ROM space.
>
>
>On Wed, Nov 03, 2004 at 01:57:19PM +0530, Nitin Yewale wrote:
>> Even if compiler does the job of accumulating similar size
>data items
>> but it will be file wise. So it will be better if linker
>reads all the
>> object files and does the accumulation of similar size data items on
>> the data type basis.
>
>No, doing this sort of thing in the compiler is by far the
>easiest way to accomplish what you want. Have the compiler
>emit 1 byte variables to .data.s1, two byte variables to
>.data.s2 and so on. Then the linker can easily combine like
>sized data items.
The compiler can also do clubbing of similar data types in one group and
then do the padding work.
A patch to gcc about stack slot analysis that could accomplish this sort
of work was posted sometime back.
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00019.html
>
>If you really must do this in the linker alone, then you'll need to
>a) determine data item boundaries
>b) rearrange section contents
>c) adjust all relocs pointing into the rearranged sections.
>d) adjust all relocs in the rearranged sections.
>e) adjust all symbols defined in those sections too.
>
>(a) is non-trivial. How will you handle aggregates?
>
>--
>Alan Modra
>IBM OzLabs - Linux Technology Centre
>