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: name collision for ELF reloc sections


   Date: Tue, 11 May 1999 06:17:32 -0700
   From: Nick Clifton <nickc@cygnus.com>

   : |>   The patch solves this problem by making elf_fake_section look for
   : |>   ".rel." as the start of a name of a REL section (and similarly
   : |>   ".rela." for the start of a name of a RELA section).  Looking for
   : |>   the extra period guarantees that the section name cannot have been
   : |>   generated from a real C/C++ function name, but I do not know if this
   : |>   is safe.  Is it possible to generate an ELF rel or rela section that
   : |>   starts with .rel{a} but which does not have a second period
   : |>   immediately following it ?
   : 
   : Yes.  Any relocation section that is associated with a section whose name
   : does not start with a period will have such a name.
   : 
   : Andreas.

   Darn.  OK - I know that the normal convention is to have all (ELF)
   section names start with a period.  Does anyone know of any toolchains
   which break this convention ?  (And which might have a reloc section
   associated with such a section) ?

   I have already commited my patch, so I would like to find out if I
   have broken anything ... :-)

Andreas is quite right.  Moreover, I believe that glibc uses section
names which do not start with a period, taking advantage of the fact
that GNU ld will automatically generate C symbols marking the start
and end of such sections.

On the other hand, typical relocation sections will not go through
elf_fake_sections.  More relocation sections are created by
elf_fake_sections.  I think the only relocation sections which will be
seen by elf_fake_sections are those holding dynamic relocations.
Perhaps we can simply mark those specially somehow, and stop checking
section names.

Ian

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