Re: Large data sections support

["H. J. Lu" <hjl at lucon dot org>]

On Tue, Jun 14, 2005 at 05:58:43PM +0200, Jan Hubicka wrote:
> > On Mon, Jun 13, 2005 at 09:19:33AM +0200, Jan Hubicka wrote:
> > > > 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?
> > > 
> > > Well when applocation exceeds 4GB, all compiled modules must be medium
> > > model, so all will know that particular symbol has to live in .lbss and
> > > will use far relocations.
> > > On the other hand when it does not exceed, I would like the small model
> > > objects be linkable with medium model objects.  So I would like the
> > > module expecting symbol being in .bss work with other module expecting it in
> > > .lbss as long as all the relocations remain within range.
> > 
> > If you let linker decide where to put a common symbol depending on
> > its size, the existing small model objects may no longer work when
> > the .lbss section is too far while the .bss section is still within
> > reach. Compiler needs a way to mark a common symbol which should be
> > placed in .lbss. SHN_X86_64_LARGE_COMMON should work here.
> 
> For binaries not exceeding 2GB, .lbss will be near enought so we won't
> break in any case. SHN_X86_64_LARGE_COMMON might increase odds that
> small model object linked into binary exceeding 2GB will link sucesfully
> but it would not be allowed to touch any data defined by other medium
> model objects so it is just tiny win.

Without SHN_X86_64_LARGE_COMMON, potentially, linking medium model
objects will require medium model libraries. You are asking all ISVs
to provide the medium model version of their libraries, even though
the small model version will work fine with modium model objects if
SHN_X86_64_LARGE_COMMON is used. If you really want to do it, please
specify it in the ABI and ask comments from ISVs.

> I guess SHN_X86_64_LARGE_COMMON could be useful in some side cases where
> we want to put some symbol exceeding the default limit (but not the 2GB
> limit) in small data area just to get faster access to it and such, so I
> will add the flag (and there is already ABI proposal for this in
> existence, so this don't seem to be big problem to ge it there, so I
> will just try to minics what HPPA does here).
> 


H.J.