This is the mail archive of the binutils@sourceware.cygnus.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]

Re: Support for SPARC STT_REGISTER


   Date: Sun, 4 Jul 1999 21:00:39 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

   Sparcv9 ABI requires any object using %g2, %g3 registers and optionally also
   %g6 and %g7 registers to announce this support by an STT_REGISTER symbol.
   In assembler, the syntax looks like this:
	   .register %g2, #scratch
	   .register %g3, somesymbol
   The first one bounds %g2 to symbol "" (st_name 0).
   This information is then used in linking, where it is forbidden to link two
   objects which both declare a particular register to a different symbol.
   A shared object ought to have these symbols in the dynamic symbol section as
   well, and .dynamic sections should contain DT_REGISTER to point into the
   .dynsym to these declarations so that dynamic linker can check them quickly.
   I have started writing support for all this, but am looking for opinions in
   the middle of the implementation.
   Basically it adds complexity not yet present in bfd elf linking code,
   because
   1) there maybe more symbol entries with the same name (one can have
   %g2,%g3,%g6,%g7 all #scratch registers)
   2) a STT_REGISTER is basically indexed by st_value (the register number),
   not its name
   3) for the .dynsym case the names should not be present in the .hash

   I'd like to hear what you think how to support this. The patch below does
   everything but the dynamic sections (but does not honour stripping of the
   .symtab STT_REGISTER entries yet). As the symbols can have identical names,
   I'm not storing them into the symbol hash table, but I wonder whether it
   would be better to force them into the hash table eventhough they have
   identical names as most of elflink.h just traverses those hash tables.

What is the section of such a symbol?

You have added code to handle them specially in the linker hash table.
I don't think this is necessary.  This is a case of linking symbols
with special semantics.  You don't need to remove those symbols
entirely from the linking process; you just need to implement special
semantics for them.  We already have a hook for that:
elf_add_symbol_hook.  It can implement the special semantics for
STT_REGISTER symbols, and then adjust its arguments to invoke some
appropriately harmless set of standard semantics.

   --- ./bfd/bfd-in2.h.jj	Tue Jun 29 10:46:31 1999
   +++ ./bfd/bfd-in2.h	Wed Jun 30 12:37:16 1999
   @@ -2312,6 +2312,9 @@ typedef struct symbol_cache_entry
   +	/* Processor specific symbol type.  */
   +#define BSF_PROC	  0x20000
   +

I don't care for this.  Changes to the generic ABI should ideally have
a generic meaning.  This does not.  I also don't see why it is
necessary to change the generic ABI in this manner, given the
existence of elf_symbol_type.

   @@ -3982,6 +3998,25 @@ swap_out_syms (abfd, sttp, relocatable_p
	     }

	   type_ptr = elf_symbol_from (abfd, syms[idx]);
   +	
   +	if ((flags & BSF_PROC) && type_ptr)
   +	  {
   +	    /* We don't know much about this symbol, so copy it
   +	       as is.  */
   +	    unsigned long name = sym.st_name;
   +	    int bind = STB_LOCAL;
   +
   +	    sym = type_ptr->internal_elf_sym;
   +	    sym.st_name = name;
   +	    if (flags & BSF_GLOBAL)
   +	      bind = STB_GLOBAL;
   +	    else if (flags & BSF_WEAK)
   +	      bind = STB_WEAK;
   +	    sym.st_info = ELF_ST_INFO (bind, ELF_ST_TYPE (sym.st_info));
   +	    bed->s->swap_symbol_out (abfd, &sym, (PTR) outbound_syms);
   +	    outbound_syms += bed->s->sizeof_sym;	    
   +	    continue;
   +	  }

	   if ((flags & BSF_SECTION_SYM) == 0
	       && bfd_is_com_section (syms[idx]->section))

I think we should be able to more or less handle this case via
elf_backend_get_symbol_type.

   --- ./bfd/elfcode.h.jj	Tue Jun 29 10:47:12 1999
   +++ ./bfd/elfcode.h	Wed Jun 30 15:02:48 1999
   @@ -1137,6 +1137,13 @@ elf_slurp_symbol_table (abfd, symptrs, d
	       case STT_OBJECT:
		 sym->symbol.flags |= BSF_OBJECT;
		 break;
   +	    case STT_LOPROC:
   +	    case STT_LOPROC+1:
   +	    case STT_HIPROC:
   +	      sym->symbol.flags |= BSF_PROC;
   +	      if (ELF_ST_BIND (i_sym.st_info) == STB_GLOBAL)
   +		sym->symbol.flags |= BSF_GLOBAL;
   +	      break;
	       }

This is what elf_backend_symbol_processing is for.

   --- ./bfd/elf-bfd.h.jj	Tue Jun 29 10:46:50 1999
   +++ ./bfd/elf-bfd.h	Sat Jul  3 21:41:12 1999
   @@ -517,6 +517,16 @@ struct elf_backend_data
   +  boolean (*elf_backend_output_arch_syms)
   +    PARAMS ((struct bfd_link_info *, PTR,
   +	    boolean (*) PARAMS ((PTR, const char *,
   +             Elf_Internal_Sym *, asection *))));
   +

You are missing a comment here.

   --- ./binutils/readelf.c.jj	Tue Jun 29 10:48:20 1999
   +++ ./binutils/readelf.c	Fri Jul  2 15:44:56 1999

These patches seem to have a bunch of code that don't seem to have
anything to do with STT_REGISTER.  Could you please submit that part
of them separately, so that we can get them in without getting tangled
up with extraneous issues?  Thanks.

Ian

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