From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: jj@sunsite.ms.mff.cuni.cz Cc: rth@cygnus.com, binutils@sourceware.cygnus.com Subject: Re: Support for SPARC STT_REGISTER Date: Tue, 06 Jul 1999 18:47:00 -0000 Message-id: <19990707013945.28312.qmail@daffy.airs.com> References: <19990704210039.B578@mff.cuni.cz> X-SW-Source: 1999-q3/msg00045.html Date: Sun, 4 Jul 1999 21:00:39 +0200 From: Jakub Jelinek 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