Re: name collision for ELF reloc sections

Re: name collision for ELF reloc sections

[Nick Clifton]

Hi Andreas,

: From: Andreas Schwab <schwab@issan.cs.uni-dortmund.de>
: 
: Nick Clifton <nickc@cygnus.com> writes:
: 
: |>   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 ... :-)

Cheers
	Nick

Re: name collision for ELF reloc sections

[Andreas Schwab]

Nick Clifton <nickc@cygnus.com> writes:

|> Hi Andreas,
|> 
|> : From: Andreas Schwab <schwab@issan.cs.uni-dortmund.de>
|> : 
|> : Nick Clifton <nickc@cygnus.com> writes:
|> : 
|> : |>   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 think the convention only holds for predefined sections, but not for
user defined sections.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: name collision for ELF reloc sections

[Ian Lance Taylor]

   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

name collision for ELF reloc sections

[Nick Clifton]

Hi Guys,

  What do you think of the following patch?  It is an attempt to fix a
  problem encountered with the ARM ecos toolchain assembling a file
  that contains a .section directive that looks like this:

	.section .release__10Cyg_Thread,"ax",@progbits

  This section has been derived from a C++ function declared like
  this: 

	void Cyg_Thread::release()

  with -ffunction-sections enabled.  The problem is that
  elf_fake_sections() thinks that the section is a REL section, since
  it starts with .rel, and so it does not assign a file position to
  it.  Later on, when a fixup inside the section is being processed an
  error occurs because BFD cannot seek to its location.

  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 ?

Cheers
	Nick


1999-05-10  Nick Clifton  <nickc@cygnus.com>

	* elf.c (elf_fake_sections): Check for .rel. as start of rel
	section, not just .rel.  Same for .rela.

Index: elf.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf.c,v
retrieving revision 1.228
diff -p -r1.228 elf.c
*** elf.c	1999/04/08 15:37:28	1.228
- --- elf.c	1999/05/10 14:37:12
*************** elf_fake_sections (abfd, asect, failedpt
*** 1490,1502 ****
        this_hdr->sh_type = SHT_DYNAMIC;
        this_hdr->sh_entsize = bed->s->sizeof_dyn;
      }
!   else if (strncmp (asect->name, ".rela", 5) == 0
  	   && get_elf_backend_data (abfd)->use_rela_p)
      {
        this_hdr->sh_type = SHT_RELA;
        this_hdr->sh_entsize = bed->s->sizeof_rela;
      }
!   else if (strncmp (asect->name, ".rel", 4) == 0
  	   && ! get_elf_backend_data (abfd)->use_rela_p)
      {
        this_hdr->sh_type = SHT_REL;
- --- 1490,1502 ----
        this_hdr->sh_type = SHT_DYNAMIC;
        this_hdr->sh_entsize = bed->s->sizeof_dyn;
      }
!   else if (strncmp (asect->name, ".rela.", 6) == 0
  	   && get_elf_backend_data (abfd)->use_rela_p)
      {
        this_hdr->sh_type = SHT_RELA;
        this_hdr->sh_entsize = bed->s->sizeof_rela;
      }
!   else if (strncmp (asect->name, ".rel.", 5) == 0
  	   && ! get_elf_backend_data (abfd)->use_rela_p)
      {
        this_hdr->sh_type = SHT_REL;

Re: name collision for ELF reloc sections

[Ian Lance Taylor]

   Date: Mon, 10 May 1999 08:04:12 -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 ?

I think your patch is correct.

In the longer term, making decisions of this sort based on the ELF
section name is wrong.  Unfortunately it's pretty ingrained in the
current ELF code.

Ian

Re: name collision for ELF reloc sections

[Andreas Schwab]

Nick Clifton <nickc@cygnus.com> writes:

|>   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.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: name collision for ELF reloc sections

[Nick Clifton]

Hi Ian,

: From: Ian Lance Taylor <ian@airs.com>
: 
:    Date: Mon, 10 May 1999 08:04:12 -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 ?
: 
: I think your patch is correct.

OK - I'll check it in.

: In the longer term, making decisions of this sort based on the ELF
: section name is wrong.  Unfortunately it's pretty ingrained in the
: current ELF code.

Yeah - it did seem to be a rather hacky approach. :-)

Cheers
	Nick