public inbox for prelink@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Filippo ARCIDIACONO <filippo.arcidiacono@st.com>
Cc: prelink@sourceware.org
Subject: Re: [PATCH] Add TLS support for SH architecture.
Date: Wed, 01 Jul 2009 08:55:00 -0000	[thread overview]
Message-ID: <20090701085510.GG4462@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <1246431789-3106-1-git-send-email-filippo.arcidiacono@st.com>

On Wed, Jul 01, 2009 at 03:03:09AM -0400, Filippo ARCIDIACONO wrote:
> This patch extend the prelink tool also for sh architecture adding the tls
> support, and fixes some architecture specific issue.
> The fix in the sh_undo_prelink_rela function is needed to restore all the GOT
> entries to the original value.
> In the prelink stage GOT[1] has been set to the first plt entry just after the
> plt header (This is the necessary code to jump at PLT[0]).
> To retrieve the other ones we need to add (28 * n) byte to the first one, where
> n is the n-th entry of the PLTn (n = 0,1,2,...).
> The fix in src/dwarf2.c avoid assertion fail at line 808 for layout[12],
> cxx[12] and undosyslibs tests.
> 
> --- a/src/dwarf2.c
> +++ b/src/dwarf2.c
> @@ -789,6 +789,13 @@ adjust_dwarf2_aranges (DSO *dso, GElf_Addr start, GElf_Addr adjust)
>  	}
>  
>        ptr += 6;
> +#ifdef __SH4__
> +/*
> + * This fix skips padding to avoid assertion fail at line 808 for 
> + * layout[12], cxx[12] and undosyslibs tests.
> + */
> +      ptr += 8;
> +#endif
>        while (ptr < endcu)
>  	{
>  	  addr = read_ptr (ptr);

This change is not acceptable.  Sometimes prelink is used as a cross tool,
so host macros shouldn't make a difference on target behavior.  Also,
if you really need to skip another 8 bytes, it doesn't seem SH is using
valid DWARF2/3 .debug_aranges, there really should be just 6 bytes skipped
here (one byte address_size, one byte segment_size, 4 bytes padding to 16
byte boundary (the tuples are supposed to be aligned to twice the pointer
size) and the aranges entries start right after that.  I don't see anything
in GCC that would suggest SH is treated differently.

So, which compiler are you testing with, if it is not GCC, are you sure you
aren't breaking prelink support for GCC on this arch?  And in any case
assembly output from the compiler with -dA for the .debug_aranges section
to show what those 8 bytes are.

Also, I'd like to understand those other non-TLS non-testsuite changes,
are you saying prelink as is never really worked on any SH, or just the SH
variant you are testing on behaves differently from the one it has been used
on before (my memory is weak, it has been many years, so I don't remember
well who tested prelink on which of the embedded arches I didn't have any
access to).

> --- a/testsuite/reloc8.sh
> +++ b/testsuite/reloc8.sh
> @@ -8,6 +8,9 @@ NOCOPYRELOC=-Wl,-z,nocopyreloc
>  case "`uname -m`" in
>    x86_64|s390*) if file reloc1lib1.so | grep -q 64-bit; then NOCOPYRELOC=; fi;;
>  esac
> +case "`uname -m`" in
> +  sh4) NOCOPYRELOC=;
> +esac

This certainly should go into the same case, no need to call uname -m the
second time.

> --- a/testsuite/reloc9.sh
> +++ b/testsuite/reloc9.sh
> @@ -8,6 +8,9 @@ NOCOPYRELOC=-Wl,-z,nocopyreloc
>  case "`uname -m`" in
>    x86_64|s390*) if file reloc1lib1.so | grep -q 64-bit; then NOCOPYRELOC=; fi;;
>  esac
> +case "`uname -m`" in
> +  sh4) NOCOPYRELOC=;
> +esac

Likewise.

	Jakub

  reply	other threads:[~2009-07-01  8:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01  7:04 Filippo ARCIDIACONO
2009-07-01  8:55 ` Jakub Jelinek [this message]
2009-07-01 15:09 Filippo ARCIDIACONO
2009-07-08 15:58 ` Filippo ARCIDIACONO

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=20090701085510.GG4462@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=filippo.arcidiacono@st.com \
    --cc=prelink@sourceware.org \
    /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).