Re: [PATCH] m68k: restore handling of R_68K_NONE in elf_machine_lazy_rel()

[Sergei Trofimovich <slyich at gmail dot com>]

On Sat, 29 Oct 2016 19:11:13 +0200
Andreas Schwab <schwab@linux-m68k.org> wrote:

> On Okt 29 2016, Sergei Trofimovich <slyich@gmail.com> wrote:
> 
> > Commit https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=96e1bff2513873062233a13c7fd1eea57bb8db24
> > among other thing shows disappearance of 'case R_68K_NONE':  
> 
> The old history is mostly broken, you need to look at
> <http://repo.or.cz/w/glibc/history.git>.

Same removal:
    http://repo.or.cz/glibc/history.git/commitdiff/60f0b5f25d09c1ee464141ee41995d9a31a604b7

binutils accidentally generates R_68K_NONE relocations around here
    https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-m68k.c;h=7c2e0fcca3bfb35d71dc1431c69958c84f04de7b;hb=690035b1471a58db62ec27d739f124f0f58f6af2#l3356
[bfd fails to properly estimate final relocation section size and pads with zeros]

    3356       /* Allocate memory for the section contents.  */
    3357       /* FIXME: This should be a call to bfd_alloc not bfd_zalloc.
    3358          Unused entries should be reclaimed before the section's contents
    3359          are written out, but at the moment this does not happen.  Thus in
    3360          order to prevent writing out garbage, we initialise the section's
    3361          contents to zero.  */
    3362       s->contents = (bfd_byte *) bfd_zalloc (dynobj, s->size);

Curious can add "memset(s->contents, '\xFF', s->size);" to make sure
it still happens.

And indeed m68k-linux-gcc generates R_68K_NONE relocations even for
minimal programs:

    $ echo 'int main(){}' > a.c
    $ m68k-unknown-linux-gnu-gcc a.c -o a
    $ readelf -a a | grep -C4 NONE
     0x00000000 (NULL)                       0x0

    Relocation section '.rela.dyn' at offset 0x238 contains 3 entries:
     Offset     Info    Type            Sym.Value  Sym. Name + Addend
    00000000  00000000 R_68K_NONE                   0
    00000000  00000000 R_68K_NONE                   0
    80004014  00000114 R_68K_GLOB_DAT    00000000   __gmon_start__ + 0

In general relocations happen to be non-lazy.

I guess to trigger lazy case we need to build shared library with complex library
structure. At least GHC does that.

Is there a reason to allow R_68K_NONE for non-lazy relocations
in elf_machine_rela()

+    case R_68K_NONE:           /* Alright, Wilbur.  */
+      break;

but forbid R_68K_NONE for lazy relocations
in elf_machine_lazy_rel()

assuming mechanism to leak R_68K_NONE to both relocation types is the same?

Thanks!

-- 

  Sergei

Attachment: pgp4ShBrfrgl6.pgp
Description: Цифровая подпись OpenPGP