Re: Large data sections support

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

On Sun, Jun 12, 2005 at 11:18:28AM -0700, H. J. Lu wrote:
> On Sun, Jun 12, 2005 at 10:46:10AM -0700, H. J. Lu wrote:
> > > > > + {
> > > > > +   if (sym->st_shndx == SHN_COMMON
> > > > > +       && !info->relocatable
> > > > > +       && sym->st_size > elf_gp_size (abfd))
> > > > > +     {
> > > > > +       /* Common symbols greater than -G nn bytes are
> > > > > + 	 automatically put into .lbss.  */
> > > > > + 
> > > > > +       asection *lcomm = bfd_get_section_by_name (abfd, ".lbss");
> > > > 
> > > > I assume different relocatons have to be used against those symbols
> > > > by compiler. Why can't compiler put those symbols into .lbss? You
> > > > don't want to linker put a normal symbol in .lbss since the relocations
> > > > may be wrong.
> > > 
> > > Compiler knows the section, but the variables output via .comm keywords
> > > go automatically into BSS.  If there is way to overwrite the behaviour,
> > > I guess compiler can do that, but this seems to be what other backends
> > > are doing..
> > 
> > You can add a new keyword, like .lcomm, or just put it in .lbss
> > directly.
> > 
> 
> 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
> relocatable fils. I would prefer .lcomm or .large_comm keyword. But it 
> may require much bigger changes.
> 

BTW, I have been working on a new memory model for HPC cluster
application. I wound up adding a new common section to support
putting common symbols in the new memory segment.


H.J.