public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Andreas Jaeger <aj@suse.de>
Cc: binutils@sources.redhat.com,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Geoff Keating <geoffk@redhat.com>
Subject: Re: combreloc patches for s390, s390x, ppc
Date: Fri, 24 Aug 2001 12:15:00 -0000	[thread overview]
Message-ID: <20010824211752.R5765@sunsite.ms.mff.cuni.cz> (raw)
In-Reply-To: <u8pu9lqq1a.fsf@gromit.moeb>

On Fri, Aug 24, 2001 at 08:19:29PM +0200, Andreas Jaeger wrote:
> +    case R_PPC_REL24:
> +    case R_PPC_REL14:
> +    case R_PPC_REL14_BRTAKEN:
> +    case R_PPC_REL14_BRNTAKEN:
> +    case R_PPC_REL32:

I think these are wrong.
reloc_class_relative are the ones that count into DT_REL*COUNT.
Looking at powerpc/dl-machine.h:
  if (rinfo == R_PPC_RELATIVE
      || (sym->st_shndx != SHN_UNDEF
          && ELF32_ST_BIND (sym->st_info) == STB_LOCAL))
    {
      /* Has already been relocated.  */
      loadbase = map->l_addr;
      finaladdr = loadbase + reloc->r_addend;
    }
  else
    {
      loadbase = (Elf32_Word) (char *) (RESOLVE (&sym, version,
which shows that IMHO only R_PPC_RELATIVE should be here.

reloc_class_plt are those for which glibc elf_machine_lookup_noplt_p
returns 1, ie. I think R_PPC_REL24 and R_PPC_ADDR24 too.
The thing is that PLT relocs have different lookup rules, likewise with
copy relocs, and thus mixing them together with other relocs means lookup
cache will be less effective.
reloc_class_copy should be obvious (R_*_COPY only, in other words
elf_machine_lookup_noexec_p in glibc).

> +    case R_PPC_RELATIVE:
> +      return reloc_class_relative;
> +    case R_PPC_JMP_SLOT:
> +      return reloc_class_plt;
> +    case R_PPC_COPY:
> +      return reloc_class_copy;
> +    default:
> +      return reloc_class_normal;
...
> +    case R_390_PC16:
> +    case R_390_PC16DBL:
> +    case R_390_PC32:

Again, only R_390_RELATIVE.

> +    case R_390_RELATIVE:
> +      return reloc_class_relative;
> +    case R_390_JMP_SLOT:
> +      return reloc_class_plt;
> +    case R_390_COPY:
> +      return reloc_class_copy;
> +    default:
> +      return reloc_class_normal;
...
> +    case R_390_PC16:
> +    case R_390_PC16DBL:
> +    case R_390_PC32:
> +    case R_390_PC32DBL:
> +    case R_390_PC64:

Likewise.

> +    case R_390_RELATIVE:
> +      return reloc_class_relative;
> +    case R_390_JMP_SLOT:
> +      return reloc_class_plt;
> +    case R_390_COPY:
> +      return reloc_class_copy;
> +    default:
> +      return reloc_class_normal;

	Jakub

  reply	other threads:[~2001-08-24 12:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-24 11:53 Andreas Jaeger
2001-08-24 12:15 ` Jakub Jelinek [this message]
2001-08-24 13:58   ` Andreas Jaeger
2001-08-27  1:34 Nick Clifton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010824211752.R5765@sunsite.ms.mff.cuni.cz \
    --to=jakub@redhat.com \
    --cc=aj@suse.de \
    --cc=binutils@sources.redhat.com \
    --cc=geoffk@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).