From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: nickc@cygnus.com Cc: binutils@sourceware.cygnus.com Subject: Re: name collision for ELF reloc sections Date: Thu, 01 Jul 1999 00:00:00 -0000 Message-id: <19990511140140.22110.qmail@daffy.airs.com> References: <199905111317.GAA15498@elmo.cygnus.com> <199905111317.GAA15498@elmo.cygnus.com> X-SW-Source: 1999-q2/msg00015.html Date: Tue, 11 May 1999 06:17:32 -0700 From: Nick Clifton : |> 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