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


On Sun, Jun 12, 2005 at 06:49:35PM +0200, Jan Hubicka wrote:
> > > 2005-06-12  Jan Hubicka  <jh@suse.cz>
> > > 	* elf.c (bfd_get_section_by_name): Add .ldata support.
> > > 	* elf64-x86-64.c (elf64_x86_64_add_symbol_hook): New.
> > > 	(elf_backend_add_symbol_hook): Define.
> > > 	* elf.sc: Add .ldata, .lbbs and .lrodata support.
> > 
> > Shouldn't you add some special sectons to elf64-x86-64.c to support
> > .ldata, .lbbs and .lrodata as output sections? Otherwise, you may
> > get wrong section attributes/flags.
> 
> I tought the section attributes are controlled from assembly and turns
> out to be right.  But unless I am mistaken last draft of ABI document
> specify special flags and there is patch to implement this floating
> around.  I will dig it out.

Both linker and assembler need to know their section attributes/flags
when generating output sections.

> > > + /* Hook called by the linker routine which adds symbols from an object
> > > +    file.  We use it to put .comm items in .lbss, and not .bss.  */
> > > + 
> > > + static bfd_boolean
> > > + elf64_x86_64_add_symbol_hook (bfd *abfd, struct bfd_link_info *info,
> > > + 			      Elf_Internal_Sym *sym, const char **namep,
> > > + 			      flagword *flagsp, asection **secp, bfd_vma *valp)
> > > + {
> > > +   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.

> > >     ${RELOCATING+${OTHER_BSS_END_SYMBOLS}}
> > >     ${RELOCATING+PROVIDE (end = .);}
> > >     ${RELOCATING+${DATA_SEGMENT_END}}
> > > +   ${LRODATA}
> > > +   ${LDATA}
> > > +   ${LBSS}
> > 
> > So the large data is beyound _end/end?
> 
> Hmm, I am not quite sure what is the desired behaviour here.
> What is OTHER_BSS_END_SYMBOLS used for?

I think only hppa64linux.sh uses OTHER_BSS_SECTIONS to add additional
bss sections. I don't know about about HPPA to comment.

> I assume that correct way is to move this before _end...
> 

I think you should make sure the end of the last bss section is the
same of _end/end. You may need to move

${RELOCATING+. = ALIGN(. != 0 ? ${ALIGNMENT} : 1);}

from .bss to .lbss.


H.J.


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