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]
Other format: [Raw text]

Re: Large data sections support


> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > On Mon, Jun 13, 2005 at 01:22:00AM +0200, Jan Hubicka wrote:
> >> > 
> >> > Putting it in .lbss won't work with common symbol. But the default
> >> > gp size is 8, "sym->st_size > elf_gp_size (abfd))" means any common
> >> > symbols bigger than 8 bytes will be put in .lbss automatically by
> >> > default. I am not sure if it will work very well with the existing
> >> 
> >> I see, this patch was hanging around longer than it should so I now
> >> hardly recall details.  The treshold for bss/lbss is specified by ABI
> >> (as different units must match on relocations used to symbols anyway),
> >> so I planned hardwiring in the proper default for elf_gp_size but my
> >> last patch simply added -G parameter in ld execution command from gcc
> >> SPECs.
> >
> > The issue is that the existing relocatable files may have old
> > relocations against common symbols larger than 8 bytes, expecting 
> > those symbols will be in .bss sections. Will it still work with your
> > scheme?
> 
> Shouldn't the threshold for putting stuff in the .l sections be very
> high?  Like, megabytes?

There was concerns about high number of moderate sized objects too, so
the treshold is currently set to 64k.  I did run some statistics that
seems to show that performance and code size wise increasing the limit
to 0.5G matter verry little (ie wast majority of accesses are to the
smaller datastructures in practice)

Honza
> 
> zw


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